03 — Legitimate Recording-Path Decision

Package: one-roof-auth-model-ratification-intake-2026-06-02 Answers mission §2.3: Can Agent create a legitimate decision/intake record without self-approval or e-sign forgery?

---

3.1 The question, made precise

Two different things could be called "recording the ratification":

1. Recording the ENACTMENT — writing the L2 council approval votes (apr_approvals) and/or the L4 sovereign e-sign (os_proposal_approvals). This moves the gate.
2. Recording the INTAKE — filing the request (approval_requests row) that asks the council to ratify, and/or capturing the decision packet as a document.

We evaluate both against the rule: no self-approval, no e-sign forgery, no forbidden mutation.

3.2 Can the Agent record the ENACTMENT? — NO

Required for enactment	Agent-doable legitimately?	Reason
L2 council quorum votes in apr_approvals	NO	fn_apr_quorum_check requires ≥1 president-human + ≥2 ai_council for a high-risk act, with proposer ≠ approver. The Agent casting these = fabricating council approval / self-approval. (F-AUTH-LIVE-1: president = a human matched by ILIKE '%president%', not a role the Agent can assume.)
L4 sovereign e-sign in os_proposal_approvals	NO	Human e-signature (signature_text/image/name/email/esignature_agreement). The Agent cannot impersonate it — e-sign forgery (explicitly forbidden).

→ Enactment is categorically not Agent-recordable. Confirmed live: os_proposal_approvals = 0, and the only governance-adjacent action-types (amend_law, enact_nrm) are unimplemented.

3.3 Can the Agent record the INTAKE (a mere request)? — NO (in this mission)

A request row is, in general, a benign proposal — agents file approval_requests routinely. But for this act, three independent blocks apply:

1. No action-type to reference. approval_requests.proposed_action_code would need to name a governance build-authorization action-type. None exists (apr_action_types = 6 sales/migration rows; the 8 governance types = SB-1, unbuilt). The only constitution-adjacent types (amend_law/enact_nrm) are unimplemented and are not the build-authorization semantics this decision needs. Filing under a wrong/placeholder type = mislabeled governance act + drift. Filing under a new type = building SB-1, which itself needs ratification → circular.

2. Constitutional origination. A one-time constitutional adoption of the authorization model is, by construction, an act the model forbids the Agent from initiating as a governed record — the President's adoption e-sign cannot be removed (hardening doc 02 §2.7). The request should originate from the proper human authority so the audit trail shows the sovereign chose to adopt, not that an Agent staged its own empowerment.

3. Mission scope. This mission's forbidden list includes "No Directus/Qdrant/Nuxt mutation." approval_requests is a Directus/PG collection. Writing any row — even a pure request — is out of scope here regardless of (1) and (2).

→ Even the lightweight intake-request is not something the Agent should/​may write in this mission.

3.4 What the Agent CAN legitimately produce

The one legitimate, non-forbidden artifact the Agent can author is a document: the human/sovereign ratification-ready packet — the exact request text, the council decision template, and the sovereign e-sign wording, with step-by-step UI/manual instructions for the humans who hold L2 and L4 authority. This is a report deliverable, not a governance mutation: it writes no approval, no e-sign, no PG/Directus row.

This packet is the "minimal legitimate decision/intake artifact" — but it lives in the report/KB layer, not the governance substrate. It records that the decision is ready and exactly how to enact it, without being the enactment.

Note on KB publication (Qdrant)

To honor the mission's "No Qdrant mutation," the packet is written to the filesystem only (the architecture working dir). KB ingestion is deferred to a follow-on publish/GPT-review step (doc 06 P-PUB), consistent with how the bootstrap package treated publication as a separate, explicitly-verified step. (Follow-on note: the publish step was authorized and executed by the subsequent PUBLISH_VERIFY_AND_CLOSE mission, 2026-06-02 — see the closing publication-verification doc.)

3.5 Decision

D-PATH: The D-BOOT-1/2 ratification is NOT Agent-recordable through any legitimate live mechanism — neither its enactment (forgery) nor, in this mission, its intake-request (no action-type / constitutional origination / forbidden mutation). The Agent's legitimate output is a human/sovereign ratification-ready packet (doc 04). The enactment must be performed out-of-band, in Directus, by the council (L2) and the President (L4).

This is the honest answer and it is the safe answer: the substrate is supposed to make this exact act un-self-recordable. We do not route around that.

3.6 Cross-links

• rests on live evidence [[02-live-governance-substrate-analysis]] §2.2–2.3.
• output specified in [[04-ratification-artifact-or-human-packet]].
• build consequence in [[05-build-go-nogo-after-ratification-intake]].
• consistent with prior refusals: [[project-one-roof-governance-phase1-approval-intake-blocked-m1-is-human-esignature-2026-06-01]].