72 — GCOS Build Authorization Template

Path: knowledge/dev/reports/architecture/one-roof-governance-technical-addendum-and-implementation-index-2026-06-01/ Doc: 72. Role: Branch F of the gated build-intake packet. The exact text that GPT and/or the human sovereign must provide later to authorize a build step — explicit and narrow — plus a "rehearsal only, no COMMIT" template. Status: BUILD-INTAKE / TEMPLATE DOCUMENT ONLY. These are blank templates to be filled and issued by the appropriate authority. Issuing them is NOT done here; this doc neither authorizes nor builds anything. Date: 2026-06-01. Extends: doc 14 (GPT delegated ruling, the precedent format), doc 49 (gate checklist), doc 68 (authorization model), doc 70 (build order), doc 71 (rollback).

---

72.0 Why a template, and what it must satisfy

Per doc 13 (GPT review): "If build is to proceed, it must be phrased as an explicit GPT/user delegated build authorization with strict rollback and stop conditions." Per doc 14, the existing delegated ruling is not a COMMIT authorization. An authorization is valid only if it is (a) explicit, (b) narrow (one named step), (c) carries the rollback plan and stop conditions, and (d) for COMMIT, is backed by a recorded sovereign M-1 approval (os_proposal_approvals>0, proposer≠approver, Điều-32 quorum). A blanket "build GCOS" authorization is invalid by design.

72.1 Authority routing (which template, who issues)

Action being authorized	Required issuer	Template
Rehearsal only (BEGIN..ROLLBACK, no COMMIT)	GPT delegated ruling (doc 14 already covers the GCOS substrate; SB-2 line needs the same)	§72.2
COMMIT of an additive Phase-1 step (SB-12/13/10/11, T6/T7 addenda)	Human sovereign M-1 record + GPT delegated build-intake authorization	§72.3
COMMIT of activation (event active=true, DOT activation, backfill seed)	Human sovereign M-1 + C-7 formal intake (A-3/A-4/A-5)	§72.3 + §72.4 rider
COMMIT of the mutating apply DOT	Human sovereign M-1 + A-9 (H-1/H-2/SB-6)	forbidden until A-9; do not template-fill without it

72.2 Template — REHEARSAL ONLY, NO COMMIT

DELEGATED REHEARSAL AUTHORIZATION (no COMMIT)
Issuer: <GPT Council, delegated by user> / <name>
Date: <YYYY-MM-DD>
Scope of this authorization: AUTHOR-MODE BEGIN..ROLLBACK REHEARSAL ONLY.

Authorized step(s): <e.g. SB-2 owner-line rehearsal: governance_object_ownership
  + governance_responsibility_scope + v_object_effective_owner + 4 APR action-type
  rows Phase-A handler_ref='unimplemented'>.
Channel: ssh contabo -> docker exec -i postgres psql -U workflow_admin -d directus
  (PG 16.13), SET LOCAL statement_timeout='5s' lock_timeout='3s'
  idle_in_transaction_session_timeout='15s', ending in ROLLBACK.

This authorization IS NOT: sovereign build approval; persistent implementation
  approval; an approval_requests/apr_approvals/os_proposal_approvals record;
  permission to COMMIT.

Forbidden (must remain impossible): COMMIT; persistent PG mutation; event emit;
  DOT live registration; approval-row creation; self-approval; law
  enactment/version/status change; Directus/Qdrant/Nuxt mutation; Phase-B handler
  activation; widening governance_relations CHECK.

Required per run: read-only pre-flight (doc 45 §45.3); BEGIN..ROLLBACK transcript;
  entry==exit numeric proof (separate-session re-read); zero-residue proof;
  idle_in_transaction=0.

Stop condition: if any rehearsal fails or leaves residue, STOP and report
  BLOCKED/FAILED with rollback evidence. Do not retry blindly.
Required next macro: rehearsal macro only; treat this as delegated technical input.

72.3 Template — SINGLE-STEP COMMIT BUILD AUTHORIZATION

Must be accompanied by a recorded os_proposal_approvals row (M-1) for THIS exact step before COMMIT. One template per step; no blanket multi-step fills.

EXPLICIT BUILD AUTHORIZATION (COMMIT permitted for ONE step)
Issuer (build-intake): <GPT Council, delegated by user>
Sovereign approver (M-1): <named human President> — os_proposal_approvals row id: <id>
APR / quorum: approval_requests id <id>, fn_apr_quorum_check PASS, proposer<>approver
Date: <YYYY-MM-DD>

AUTHORIZED STEP (exactly one): <e.g. Step 1 — SB-12: CREATE TABLE
  governance_ruleset + 1 draft row (status='draft', NOT activated) + 1
  evolution_snapshots governance row>.
COMMIT ALLOWED: YES, for this step only, after the per-step pre-flight and a
  BEGIN..ROLLBACK rehearsal of THIS step both pass.

OBJECTS THAT MAY BE CREATED/WRITTEN (exhaustive — nothing else):
  <e.g. table governance_ruleset; one draft ruleset row; one evolution_snapshots
   row scope='governance.backfill'>.
OBJECTS THAT MAY NOT BE TOUCHED: birth_registry (read-only); normative_registry,
  law_catalog, governance_docs (no law change); event_outbox (no emit);
  os_proposal_approvals (no self-approval); event_type_registry active flag (no
  activation this step); governance_relations CHECK (no widening); the mutating DOT
  dot_governance_assignment_apply (NOT created); Directus/Qdrant/Nuxt (no mutation).

MANDATORY DRIFT FOLD-INS for this step (doc 69): <list those that apply, e.g.
  SB-13 -> F-57-1; SB-11 -> F-57-2/3/4; T6/T7 addenda -> F-R7-1 ordering + F-R7-2
  naming decision>.

REQUIRED ROLLBACK PLAN (doc 71): preflight pg_dump of affected reuse tables +
  schema; DDL rollback = <DROP/DELETE statements for this step>; verification query
  set §71.6 in a separate session; idle_in_transaction=0 check; disaster restore
  from backup if any rollback errors.

REQUIRED FINAL EVIDENCE: post-COMMIT §71.6 verification showing exactly the
  intended footprint and all invariants (norm=47, law=5, outbox_gov=0 pre-step-8,
  os_proposal_approvals matches recorded) unchanged; entry==exit-style diff vs the
  pre-step baseline; idle_in_transaction=0.

STOP CONDITIONS (any one halts immediately, doc 70 §70.2): os_proposal_approvals
  reads 0 at COMMIT; any forbidden action reachable; this step's rehearsal didn't
  pass entry==exit; a required drift fold-in missing; the apply DOT about to be
  created without A-9; a leaked idle transaction; footprint exceeds the listed
  objects / a new bus appears; a C-7/C-1/C-2 decision treated as ratified by
  silence.

SCOPE LIMIT: authorization expires on completion of this step. The next step
  requires a new authorization + a new M-1 record.

72.4 Activation rider (append to §72.3 for steps 8–9)

ACTIVATION RIDER (events active=true / DOT activation / backfill seed)
Additional required intake (recorded, silence != approval, proposer != approver):
  - A-3 C-7.1 input-trust  (for dot_governance_input_gate / input.* activation)
  - A-4 C-7.2 ruleset-owner (for activating any governance_ruleset)
  - A-5 C-7.3 backfill-ruleset (for backfill seed; high-risk verdicts stay
       'unknown'/fail-closed until ruleset activation)
  - A-6 C-7.4 60-day cut-over (legacy escalation -> findings only, NO
       auto-remediation)
Register-before-emit invariant: event rows must already exist active=false (SB-11
  committed) BEFORE any flip to active=true. First emit may appear in event_outbox
  ONLY after the row is active. No emit before register (Dieu 45).
Activation rollback: set active=false (disable); do NOT delete event_outbox history.

72.5 What a VALID authorization must always say (checklist)

A future authorization is accepted by the build agent only if it contains ALL of:

1. Which step is authorized (exactly one, named).
2. Whether COMMIT is allowed (explicit YES/NO) and, if YES, the os_proposal_approvals row id (M-1).
3. Which objects may be created/written (exhaustive list).
4. Which objects may NOT be touched (the forbidden set).
5. The required rollback plan (doc 71, per step).
6. The required final evidence (post-COMMIT §71.6 verification + entry==exit diff).
7. The stop conditions (doc 70 §70.2).
8. For activation steps: the C-7 intake records (rider §72.4).

If any of 1–8 is missing, the authorization is invalid and the agent stays NO-GO and reports the gap. No authorization may be self-issued by the building agent; silence is never authorization.

72.6 Authorization-template verdict

Both templates are complete: a "rehearsal only, no COMMIT" delegated form (§72.2) and a narrow single-step COMMIT form (§72.3) with an activation rider (§72.4) and an acceptance checklist (§72.5). The COMMIT form structurally cannot be satisfied without a recorded sovereign M-1 row, which does not exist (live os_proposal_approvals=0). Issuing either template is the authority's act, not this packet's. Build remains NO-GO.