114 — Phase 1 Approval/Intake Schema & Gate Analysis

Mission: ONE_ROOF_GOVERNANCE_PHASE1_APPROVAL_INTAKE_AND_BUILD (Phase A = approval/intake; Phase B = gated build). Tier: schema + gate analysis. Mutation footprint: ZERO (read-only, query_pg AST-validated READ ONLY role). Verdict of this doc: Hard Gate A CANNOT be passed safely. Phase A approval/intake record MUST NOT be created by this agent. Therefore Phase B build does not start. Mission status = BLOCKED.

---

114.1 Why the previous mission blocked (restated, and re-confirmed live)

The prior Phase-1 gated-build run (docs 104–113) correctly stopped at Hard Gate 0 because the master gate M-1 was red:

M-1  :  SELECT count(*) FROM os_proposal_approvals  =  0   ⇒  COMMIT_FORBIDDEN

Re-verified live 2026-06-01 (read-only): os_proposal_approvals = 0. M-1 is still red. Per doc 89 §89.6–§89.7 and doc 88, nothing in the build order is executable while M-1 = 0.

114.2 What record is required to satisfy M-1

M-1 is defined solely as: at least one row in os_proposal_approvals whose scope covers the step being committed. There is no alternative table that satisfies M-1 — I searched the live schema for %intake%/%proposal% tables and found only the Directus proposal-signing family:

os_proposals            (Directus collection)
os_proposal_blocks
os_proposal_contacts
os_proposal_approvals   (Directus collection)   ← the M-1 surface
table_proposals

So the only way to satisfy M-1 is to create a valid os_proposal_approvals row.

114.3 Live schema of os_proposal_approvals (the decisive finding)

os_proposal_approvals is not an abstract governance flag. It is a Directus-managed human e-signature collection (confirmed: directus_collections.collection = 'os_proposal_approvals' → true). Its 19 columns:

column	type	meaning
id	character	Directus app-managed id
status	varchar NOT NULL	signing/approval status
user_created, date_created, user_updated, date_updated	—	Directus audit
signature_text	varchar	the signatory's typed signature
signature_image	character	the signatory's drawn signature image
signature_type	varchar	how it was signed
first_name, last_name	varchar	the human signatory's name
organization	varchar	signatory org
proposal	character	FK-style link to os_proposals row being signed
email	varchar	signatory email
ip_address	varchar	IP the signature was captured from
esignature_agreement	boolean	the signatory affirming the e-signature legal agreement
metadata	jsonb	—
contact	character	link to os_proposal_contacts

This table exists to capture a real person physically e-signing a proposal (typed/drawn signature, legal name, email, e-signature consent flag, originating IP). The governance design deliberately chose a human e-signature surface as the sovereign COMMIT key — precisely so that an automated agent cannot satisfy it by writing a flag.

Triggers on the table: birth_trigger_os_proposal_approvals → fn_birth_registry_auto (enabled). No FK/PK constraints surface via information_schema (Directus manages id/relations at the app layer).

114.4 The authority model (doc 89 §89.6, doc 88, doc 95) — binding

Authority	Can it write os_proposal_approvals / move M-1?
Sovereign (President)	YES — the ONLY writer of os_proposal_approvals; the load-bearing COMMIT key. Acts by personally e-signing the proposal.
Council (C-1/C-2/C-7.x)	Records governed decisions (build intake). Necessary for specific steps, but does not write the M-1 row.
GPT delegated operator	NO. May sequence/authorize REHEARSAL only. A GPT or agent statement is NEVER sufficient for a COMMIT (doc 89 §89.6, verbatim).
This build agent	NO. Never decides; never self-approves.

114.5 Can GPT-delegated authorization be recorded as a valid approval/intake record?

No. There is a real document on file — gpt-review-phase1-safety-pack-pass-and-delegated-build-authorization-2026-06-01.md — in which the GPT council, "acting under the user's explicit delegation for technical governance decisions," states it "authorizes ONE controlled Phase 1 build mission." This is advisory and does not satisfy M-1, for four independent reasons:

1. The governance model is explicit and controlling. Doc 89 §89.6: "A GPT or agent statement is never sufficient for a COMMIT. The sovereign os_proposal_approvals row is." §89.6 also classifies "GPT direction" as "rehearsal only — it cannot authorize a COMMIT — advisory." Doc 89 sits above the GPT review in the controlling-sources order (doc 00 §0.1); the GPT review cannot overturn it.
2. The M-1 surface is a human e-signature, not a delegable token. Recording a row means producing a named human's typed/drawn signature, email, e-signature-consent boolean, and capture IP. GPT's "technical-governance delegation" is not the President's personal e-signature and cannot be transcribed into one.
3. Doing so would be fabrication / impersonation / self-approval — every one of which the mission forbids (§8: "Fabricating approval outside live schema", "Self-approval if schema/rules prohibit it", "Hidden approval fabrication outside approved substrate", "Auto-approve bypass"). An agent inserting a signature row on behalf of the sovereign forges the sovereign's e-signature.
4. The available write channel cannot do it legitimately anyway. The read channel (query_pg) is AST-validated READ ONLY. The only write channel is author-mode psql via ssh contabo → docker exec postgres psql. Writing a fabricated e-signature row there is forbidden regardless of channel — the constraint is governance, not transport.

114.6 Exact allowed mutation

• Phase A (approval/intake): NONE. This agent may not create, update, or delete any row in os_proposal_approvals or any os_* proposal table. The legitimate actor is the sovereign President, acting through the Directus e-signature flow (out of band from this agent), optionally after the Council C-1/C-2/C-7 build-intake decisions are recorded by their proper holders.
• Phase B (build): NONE. Phase B is gated on Phase A. Phase A did not pass ⇒ no SB-12/SB-13/SB-10/SB-11/SB-2/SB-1 DDL/DML is executed.
• KB report docs (114–125): ALLOWED — these are the mission deliverable, not a substrate mutation.

114.7 Stop conditions (doc 89 §89.7) — which fired

• ✅ FIRED: os_proposal_approvals = 0 (no row for the current step) → STOP.
• ✅ FIRED (would have): "any attempt … to fabricate approval / self-approve" → STOP.
• All other stop conditions are moot because no build was attempted.

114.8 Live baseline captured this run (read-only, 2026-06-01)

surface	value	expected
os_proposal_approvals (M-1)	0	0 → COMMIT_FORBIDDEN
SB-2 governance_object_ownership / governance_responsibility_scope	ABSENT / ABSENT	absent until built
SB-12 governance_ruleset	ABSENT	absent until built
SB-13 gov_worker_cursor	ABSENT	absent until built
SB-10 governance_candidate_state / candidate_scan_run	ABSENT / ABSENT	absent until built
apr_action_types total / SB-1 new / birth-apr rows	6 / 0 / 0	6 / 0 / 0 until SB-1
approval_requests / apr_approvals	211 / 42	unchanged
event_type_registry (governance) / event_outbox (governance)	0 / 0	0 / 0
dot_domains / dot_tools / dot_coverage_required	46 / 309 / 11	unchanged
normative_registry / law_catalog	47 / 5	unchanged (no law change)
idle in transaction sessions	0	0

Baseline is identical to the doc-96 / doc-113 baseline. No drift, no foreign mutation.

Gate A verdict: BLOCKED. Proceed to doc 115 (no record created), then docs 116–123 (NOT_RUN), 124 (final status), 125 (self-review).