03 — A3 · authorize_build_step Quorum / Approval Packet

Result: the quorum path is FULLY DISCOVERABLE and the mechanism is LIVE → A3 is NOT ..._HOLD_QUORUM_PATH_UNCLEAR. But the required approvals do not exist and the agent cannot create them → A3 cannot pass without owner action. Capability ≠ authority.

All facts below are from governed read-only query_pg (db=directus) — no writes, no APR proposed/approved/executed.

The action

field	value
action_code	authorize_build_step
description	"Issue an L3 governance_build_authorization grant for exactly one build step"
risk_level	high
status	active
handler_ref	unimplemented
_dot_origin	PG:sb1-gov-vocab

Required quorum (EXACT — from fn_apr_quorum_check, not a runbook paraphrase)

The trigger trg_apr_quorum_check fires on approval_requests transition pending → approved and, for risk_level='high', RAISES unless all hold:

• v_approves_president >= 1 — an approve vote with approver_type='human' AND approver ILIKE '%president%'.
• v_approves_council >= 2 — ≥2 approve votes with approver_type='ai_council'.
• v_rejects = 0 — any reject vote blocks approval.
• no self-approve — the proposer (source_context->>'proposer' / 'created_by') may not be among the approvers.

Apply-time re-proof (fn_apr_block_unimplemented_handler, trigger trg_apr_block_unimplemented, on approved→applied) re-checks quorum_passed() AND blocks if the action's handler is unimplemented. Confirmed by views v_apply_time_quorum_reproof_status (reproof = IMPLEMENTED, runs before the null-action early return) and v_authority_quorum_regression_guard (all P0 assertions: ai-cannot-approve-high-alone, president-required, reject-blocks, self-approve-prohibited, no-autoapprove-at-INSERT).

Consequence: even WITH full quorum, an authorize_build_step APR can never reach applied while handler_ref='unimplemented'. Implementing the handler is the W7 prerequisite; the quorum is consumed at runtime when grants are actually issued.

Current vs required

item	current	required	missing
approval_requests WHERE proposed_action_code=authorize_build_step	0	≥1 (pending)	1 proposal
president approve votes for that APR	0	≥1	1 president vote
ai_council approve votes for that APR	0	≥2	2 council votes
reject votes	0	0	(ok)
governance_build_authorization grants	0 total / 0 active	n/a (output)	—

The mechanism is real and exercised (proof it is not theoretical)

• apr_approvals: 42 approvals across 14 distinct requests, 7 distinct approvers.
• By type: 14 human (all approver='president', decision=approve) + 28 ai_council (gemini 11, gpt 11, gpt-ai-council 2, gemini-ai-council 2, ai_council_1 1, ai_council_2 1).
• approval_requests total = 230. So there is a real human "president" approver identity and real ai_council members who have voted on prior governed actions — the same path applies to authorize_build_step.

How to propose / record (the governed path — operator/owner, later)

1. Propose: create an approval_requests row via the governed APR proposer (dot/bin/dot-apr-propose, present + clean on VPS) with proposed_action_code='authorize_build_step', status='pending', source_context carrying the proposer identity. (Do NOT hand-INSERT — use the DOT/APR path.)
2. President approval: the human president casts an approve vote → recorded as an apr_approvals row (apr_id=APR.id, approver_type='human', approver matching %president%, decision='approve').
3. ai_council approvals: ≥2 distinct ai_council members cast approve votes → 2 apr_approvals rows (approver_type='ai_council').
4. When the votes satisfy the rule, the APR is moved pending→approved and the quorum trigger validates it. For the W7 apply specifically, the same quorum is also needed on the deploy action (see below).

What command/operator step is needed later (W7 apply chain)

The W7 apply is not a single authorize_build_step APR — it deploys the handler so the action becomes usable:

• STEP1 — deploy handler: governed patch_ops_code APR (the only implemented high-risk action; handler_ref=dot-apr-execute:patch_ops) to add execute_authorize_build_step into dot-apr-execute. patch_ops_code is itself high-risk → same 1 president + 2 ai_council quorum.
• STEP4 — bind handler_ref: operator migration (origin MIGRATION) to set apr_action_types.handler_ref for authorize_build_step to the deployed verb.
• STEP5 — register dot-c1-grant-issue: via dot-dot-register (clean on VPS).
• SYNC_SECRET supplied at dot-apr-execute invocation (present at /opt/incomex/docker/.env line 41 — value never read here).
• Only after the handler is implemented can an authorize_build_step APR reach applied to mint a governance_build_authorization grant.

Why the agent cannot satisfy A3 (capability ≠ authority)

• Capability (proven, irrelevant to authority): root SSH to vmi3080463, readable /opt/incomex/dot/bin, SYNC_SECRET present, GCP project ownership. These let one press the button.
• Authority (the gate): the DB trigger enforces a multi-party human+council quorum. A single agent:
  1. cannot manufacture a human-president approve vote (it is not a human president; inserting a human/%president% row = governance bypass);
  2. cannot self-certify as a 2-member ai_council (one AI ≠ a 2-member council; self-quorum = bypass);
  3. has no APR to attach votes to (0 proposals for the action).
• A macro instruction to "run" is not a governed president vote inside the system. No SYNC_SECRET value was printed/used. No reject/self-approve shortcuts were attempted.

A3 gate: cannot pass in-agent. Owner must marshal 1 president + 2 ai_council through the governed APR path (and the same for the patch_ops_code deploy APR).