93 — Phase 1 Build Authorization: Scope & Risk

Mission §4 (Branch A). Tier: build-authorization scoping. Mutation footprint: ZERO — KB doc only; live PG read-only re-verified 2026-06-01. This doc does NOT authorize a build. It defines what Phase 1 is, classifies each component's risk, and fixes the transaction strategy and order, so a sovereign/council authorization can be made step-by-step against a precise scope. Master gate stands: os_proposal_approvals=0 (live 2026-06-01) ⇒ COMMIT_FORBIDDEN for every component below. Read with: doc 89 (build handoff/order), doc 86 (mandatory fold-ins), doc 88 (blocker ledger), doc 87 (readiness matrix).

93.1 Phase 1 scope — exact in / exact out

Phase 1 = the foundational governance substrate spine only — the additive tables/vocabulary that hold no apply capability, emit nothing, and register no executable behaviour. Six components, all already REHEARSED_GREEN:

In Phase 1	Component	One-line
✅	SB-12	`governance_ruleset` (status `draft`) + reuse `evolution_snapshots` — ruleset-version substrate
✅	SB-13	`gov_worker_cursor` (text watermark) + reuse `queue_heartbeat` — worker cursor family
✅	SB-10	`governance_candidate_state` (+ optional object table) + `candidate_scan_run` — decaying-verdict candidate store
✅	SB-11	register 5 governance event types in `event_type_registry`, `active=false` — event domain (register-before-emit, NO emit)
✅	SB-2	`governance_responsibility_scope` (+6 seed) + `governance_object_ownership` (+2 resolution views) — ownership substrate
✅	SB-1	4 `apr_action_types` rows (`high`/`unimplemented`) with the F-83-1 trigger fix — APR action-type vocabulary, Phase A only

Explicitly OUT of Phase 1 (remain BUILD_NO_GO / FUTURE — see doc 87/88/100):

Out	Why
❌ T6 coverage scanner DOTs	gated on SB-10..13 built + C-7; tier-A read/propose only even later
❌ T7 issue/event/notification wiring	gated on SB-11 built; F-57-2/3/4 fold-ins
❌ GCOS backfill seed	C-7.3; dry-run only even when authorized
❌ GCOS handoff / input gate activation	C-7.5 / C-7.1
❌ Event activation (`active=true`) / any emit	register-before-emit; activation needs C-7.x
❌ DOT registration (`dot_tools`/`dot_coverage_required`/`dot_domains` GCOS rows)	T6/T7 step (post-substrate)
❌ Production gate (G-PROD) enforcement	needs SB-10 built first
❌ SB-1 Phase-B handler / mutating apply DOT (G-APPLY)	A-9 sovereign sign-off — never build now
❌ UI / Directus / Nuxt / Qdrant exposure	no surface work in Phase 1
❌ OP-B / SB-3 / L-1 / L-2	FUTURE_LAW_OR_DESIGN

Boundary rule: Phase 1 builds substrate that can hold governance state. It does not build anything that acts on governance state. Nothing in Phase 1 can write an owner row, approve an APR, emit an event, run a scan, or modify Birth.

93.2 Per-component classification

SB-12 — ruleset / snapshot

Purpose: canonical ruleset-version registry so candidate verdicts are keyed to a ruleset hash; reuse evolution_snapshots for the per-group fingerprint.
Dependency: none upstream. Downstream: SB-10 FK → governance_ruleset.
Rehearsal evidence: docs 38 (design), 58 + 62 (REHEARSED_GREEN).
Build risk: LOW. Greenfield additive table; ruleset created status='draft' (activation deferred to C-7.2). No trigger, no emit.
Allowed build objects: CREATE TABLE governance_ruleset (+ supporting index/constraint); 1 reuse row in evolution_snapshots (metrics jsonb fingerprint).
Forbidden side effects: activating a ruleset; any law version-bump; writing to normative_registry/law_catalog.
Rollback path: DROP TABLE governance_ruleset; DELETE the evolution_snapshots reuse row by its origin key. Greenfield ⇒ clean drop.
Same-txn?: standalone step; must precede SB-10 (FK parent).
Recommended order position: 1st (cleanest foundation; GPT-recommended first build).

SB-13 — worker cursor family

Purpose: durable governance worker cursors (gov_worker_cursor) + reuse queue_heartbeat for lease/heartbeat.
Dependency: none hard upstream. Downstream: GCOS workers (post-Phase-1) read cursors.
Rehearsal evidence: docs 39 (design), 59 + 62 (REHEARSED_GREEN).
Build risk: LOW. Greenfield table + additive reuse rows. Fold-in F-57-1 (queue_heartbeat real cols: executor_name PK, executor_kind='PG_worker', metadata='{}' safe-keys) and L-WATERMARK (last_watermark_id = text, never reuse a uuid/int col 1:1).
Allowed build objects: CREATE TABLE gov_worker_cursor; optional additive queue_heartbeat rows (executor_name LIKE 'gov_%').
Forbidden side effects: Đ45 violation (writing data-not-signal into queue_heartbeat.metadata); reusing a typed id column for the watermark.
Rollback path: DROP TABLE gov_worker_cursor; DELETE FROM queue_heartbeat WHERE executor_name LIKE 'gov\_%'.
Same-txn?: standalone; independent of SB-12 but conventionally built right after it.
Recommended order position: 2nd.

SB-10 — candidate-state store (keystone)

Purpose: decaying-verdict candidate store keyed (candidate_key, snapshot, ruleset_version, scan_time) — no "checked-forever" boolean. Modeled on derived_objects_registry dirty/stale.
Dependency: SB-12 first (FK → governance_ruleset). Conventionally SB-13 also present.
Rehearsal evidence: docs 40 (design), 60 + 62 (REHEARSED_GREEN).
Build risk: MEDIUM. Most structurally significant table; carries the L-CANON-NULL correction (candidate_key = COALESCE(canonical_address, collection_name||':'||entity_code) — canonical_address is NULL in all 1,048,181 birth rows). FK to SB-12 means ordering is load-bearing.
Allowed build objects: CREATE TABLE governance_candidate_state (+ optional object table materialized only for indep-authoritative/open-finding/exception/high-risk-write) + CREATE TABLE candidate_scan_run; FK → governance_ruleset.
Forbidden side effects: a checked_forever/boolean verdict column; keying on canonical_address alone; seeding candidate rows (that is backfill, OUT of Phase 1).
Rollback path: DROP TABLE candidate_scan_run; DROP TABLE governance_candidate_state; (drop FK child first if object table exists).
Same-txn?: standalone step; strictly after SB-12.
Recommended order position: 3rd.

SB-11 — governance event domain

Purpose: register 5 governance event types in event_type_registry so register-before-emit (Đ45) is satisfied; active=false, zero emit.
Dependency: none hard (reuse table exists). Trust/activation needs C-7.1 (NOT Phase 1).
Rehearsal evidence: docs 41 (design), 61 + 62 (REHEARSED_GREEN).
Build risk: LOW-MEDIUM. No new table; fold-in F-57-2/3/4 — live CHECK enums: delivery_lane∈{immediate,delayed} (use delayed), event_stream∈{…,alert,health} (use alert for findings / health for heartbeats; not governance), default_severity∈{info,warning,critical} (use warning/info; not medium), event_domain='governance' free-text, PK (event_domain,event_type).
Allowed build objects: 5 INSERTs into event_type_registry, active=false.
Forbidden side effects: active=true; any event_outbox row (event_outbox governance must stay 0).
Rollback path: DELETE FROM event_type_registry WHERE event_domain='governance'. Rows inactive ⇒ nothing emitted to unwind.
Same-txn?: standalone reuse-table step; independent of SB-10/12/13. (Doc 89 sequences it after SB-10; either order is safe since it shares no FK.)
Recommended order position: 4th.

SB-2 — ownership substrate

Purpose: governance_responsibility_scope (6 law-scopes as data, not hardcode) + governance_object_ownership (20-col keystone, partial-UNIQUE one-accountable-per-scope) + 2 resolution views (v_object_effective_owner, v_object_owner_gap).
Dependency: none hard upstream (owners FK → existing governance_registry; scopes FK → the new scope table). Independent of GCOS.
Rehearsal evidence: docs 17 (design), 75–81 (REHEARSED_GREEN; W6 closed; 5 negative tests passed).
Build risk: LOW-MEDIUM. Additive tables only; must never ALTER governance_relations (CHECK-widen). Tables are trigger-less ⇒ no F-83-1-class birth/emit problem. Partial UNIQUE + delegated-requires-effective_to CHECK are the load-bearing constraints.
Allowed build objects: CREATE TABLE governance_responsibility_scope (+6 seed rows) + CREATE TABLE governance_object_ownership (20-col, partial UNIQUE) + 2 resolution views.
Forbidden side effects: widening governance_relations CHECK; adding any trigger to the new tables; writing owner rows for real objects (that is operation, not substrate).
Rollback path: DROP VIEW v_object_owner_gap, v_object_effective_owner; DROP TABLE governance_object_ownership; DROP TABLE governance_responsibility_scope; (views/child first).
Same-txn?: the two tables + two views + 6 seed rows are one cohesive additive unit ⇒ build as a single transaction (one COMMIT). Independent of SB-1 and GCOS.
Recommended order position: 5th (independent; can also be done first — but grouping after GCOS keeps the trigger-touching SB-1 last).

SB-1 — APR action-types (Phase A) — special risk

Purpose: register 4 governance action-types as apr_action_types rows (assign_governance_owner, grant_governance_exception, delegate_authority, assign_axis_owner), all handler_ref='unimplemented', risk_level='high', status='active' — vocabulary only, no apply.
Dependency: C-2 council build record + M-1. SB-2 should exist as the eventual owner-write target (Phase B), but Phase-A vocabulary does not require it.
Rehearsal evidence: docs 16 (design), 83 (rehearsal — F-83-1 discovered + fixed in-txn), 84 (fail-closed/quorum analysis).
Build risk: HIGH (relative to the others). This is the only Phase-1 step that must perform DDL on an existing directus-owned table — re-wiring the birth trigger (F-83-1). Without it the 4 INSERTs fail on a birth_registry.entity_code NOT-NULL violation. Secondary risk: the action='add' auto-approve bypass (doc 84) — mitigated by not creating any approval_requests row in Phase A and by the action='review' convention for any future APR.
Allowed build objects: DROP TRIGGER trg_birth_apr_action_types + CREATE TRIGGER … EXECUTE FUNCTION fn_birth_registry_auto('action_code') (the F-83-1 fix), then 4 INSERTs into apr_action_types.
Forbidden side effects: flipping any handler_ref to a real handler (Phase B = NO-GO); creating an approval_requests row (esp. action='add'); any emit; touching governance_relations.
Rollback path: action-types are retire-not-delete (status='retired', retired_at=now()) because of FK RESTRICT from approval_requests.proposed_action_code; the F-83-1 trigger re-wire is permanent corrective DDL at build (reverting it would re-break inserts) — see doc 98 for the precise restore stance.
Same-txn?: the trigger re-wire + 4 INSERTs are one cohesive unit ⇒ single transaction. Must be separate from every other step (its own COMMIT, its own C-2 record, its own M-1 row) because it is the only step doing trigger DDL.
Recommended order position: 6th / last — highest risk, isolate it; everything else is proven clean first.

93.3 Transaction strategy — decision

Decision: MULTIPLE SMALL TRANSACTIONS — one COMMIT per step, each under its own sovereign os_proposal_approvals row and (where applicable) its own council record. Not one mega-transaction; not over-fragmented within a step.

Why not one transaction:

The authorization model is per-step (doc 89 §89.6): M-1 requires a sovereign row for THIS step. A single mega-transaction cannot be authorized step-by-step.
Blast radius: a single failure would roll back all six components; per-step COMMIT bounds the damage and the rollback.
F-83-1 trigger DDL (SB-1) must be isolated from the greenfield-only steps so a guard/owner-permission issue on the trigger never blocks the clean substrate.
FK ordering (SB-12 → SB-10) is naturally expressed as ordered separate steps with re-verify between.

Why not over-fragment:

Within a step, the cohesive additive unit commits together: SB-2 = 2 tables + 2 views + 6 seed rows in one txn; SB-1 = trigger re-wire + 4 INSERTs in one txn; SB-10 = candidate-state + scan-run (+ optional object) in one txn. Splitting these would strand FKs or leave a half-built substrate.

Staged commits, not a saga: there is no compensating-action chain. Each step is independently reversible (DROP for greenfield, DELETE-by-origin for reuse rows, retire for action-types). Stop and re-verify (doc 96) between every step.

93.4 Recommended Phase 1 order (dependency-correct)

STEP 0   Preflight + pg_dump backup (doc 96)                      [no COMMIT]
STEP 1   SB-12  governance_ruleset (draft) + evolution_snapshots  [M-1]            ← clean foundation (GPT-recommended first)
STEP 2   SB-13  gov_worker_cursor + queue_heartbeat (F-57-1)      [M-1]
STEP 3   SB-10  governance_candidate_state + candidate_scan_run   [M-1]  (FK→SB-12, so after STEP 1)
STEP 4   SB-11  register 5 event types active=false (F-57-2/3/4)  [M-1]
STEP 5   SB-2   scope + ownership + 2 views (one txn)             [M-1 + C-1]
STEP 6   SB-1   F-83-1 trigger fix + 4 apr_action_types rows      [M-1 + C-2]      ← highest risk, isolated, last
STEP 7   HOLD   no T6/T7/backfill/DOT/event-activation            [no build]

Two defensible orderings of the spine exist and both are safe:

Doc-89 order (SB-1 → SB-2 → SB-12 → SB-13 → SB-10 → SB-11): builds owner/APR first.
This doc's order (SB-12 → SB-13 → SB-10 → SB-11 → SB-2 → SB-1): builds the cleanest greenfield substrate first and isolates the only trigger-touching step (SB-1) to last, matching the GPT recommendation ("Recommended first build if authorized: SB-12 + SB-13 only … cleanest foundation; SB-1 last, only with F-83-1").

Recommendation: adopt this doc's order (GCOS substrate → SB-2 → SB-1). The only hard constraint is SB-12 before SB-10 (FK). SB-2 and SB-11 are order-independent. SB-1 last by risk. Whichever order the sovereign authorizes, each step is its own COMMIT under its own auth row.

93.5 Risk roll-up

Component	Build risk	Dominant risk	Mitigation
SB-12	LOW	premature ruleset activation	create `status='draft'`; activation = C-7.2 (out of Phase 1)
SB-13	LOW	wrong reuse cols / typed watermark	F-57-1 cols; L-WATERMARK text
SB-10	MEDIUM	FK ordering; canonical_address NULL	SB-12 first; L-CANON-NULL coalesce key
SB-11	LOW-MED	CHECK enum failure; accidental emit	F-57-2/3/4 enums; `active=false`; outbox=0 assert
SB-2	LOW-MED	CHECK-widen of `governance_relations`	additive tables only; trigger-less
SB-1	HIGH	F-83-1 birth-trigger block; action='add' bypass	trigger re-wire to `'action_code'` first (doc 98); no APR row; action='review' convention

Branch A verdict: Phase 1 scope is fixed at the six-component substrate spine; transaction strategy is per-step small transactions; recommended order is SB-12 → SB-13 → SB-10 → SB-11 → SB-2 → SB-1, each its own COMMIT under its own M-1 (+ C-1/C-2) record. The only special-risk step is SB-1 (F-83-1), isolated to last. No build authorized by this doc; M-1=0 ⇒ COMMIT_FORBIDDEN.