08 — Objective G: Production Rollout Packet

Verdict: PRODUCED — gated, NOT executed. Four SQL files mirror the clone-proven build for production, each self-guarding. Nothing in this packet has run against production.

Files

file	role	mutating?	gate
sql/G_prod_00_preflight.sql	read-only preflight + ratification check	no	—
sql/G_prod_01_axis_ddl_and_seed.sql	DDL + responsibility-axis seed (active)	yes	refuses unless directus AND ospa≥1 AND axis tables absent; asserts zero-drift before COMMIT
sql/G_prod_02_verify.sql	read-only post-verify	no	—
sql/G_prod_03_rollback.sql	full reversal	yes	refuses unless directus; drops all 6 tables + 3 views

Preflight (G_prod_00) — expected output before any change

is_production=true · ownership_rows=0 · canonical_gap=210 · inventory_born_requires_owner=35 · active_scopes=6 · axis_tables_present=0 · RATIFICATION_ospa=? · GATE_ratified=? · idle=0. Proceed only if is_production=true, axis_tables_present=0, and GATE_ratified=true.

DDL + seed (G_prod_01) — what it does and why it's safe

• Creates the same 6 tables + 3 core views proven on the clone, using the parallel axis_object_ownership pattern → governance_object_ownership is never ALTERed.
• Seeds only the responsibility axis active (the 6 live scopes). Topic/containment are not seeded — they enter later as candidates through a governed step, so the rollout itself introduces no new active classification axis.
• Zero-drift assertion before COMMIT: required cells = 210 and generalized gap == canonical v_object_owner_gap. On production (0 owners) both are 210 → effective coverage is unchanged by the rollout (it formalizes the existing model as axis-0, nothing more). If the assertion fails, the single transaction aborts and nothing persists.

Self-guards (triple gate)

current_database() = 'directus'          -- else REFUSE
os_proposal_approvals >= 1               -- ratification gate; else REFUSE
axis substrate tables = 0                -- idempotency; else REFUSE

Expected deltas (production)

metric	before	after rollout	after (eventual) ownership seed
axis tables	0	6	6
responsibility active values	—	6	6
v_axis_required_cell	—	210	210
v_axis_coverage_gap	—	210 (= canonical)	0
v_object_owner_gap (canonical)	210	210 (unchanged)	0
governance_object_ownership	0	0 (unchanged)	30
os_proposal_approvals	0	0	≥1

The axis rollout does not change the canonical gap or ownership. Coverage closure remains the job of the separate, already-gated ownership-seed packet (F_prod_* in the extended pkg).

Stop gates

1. os_proposal_approvals = 0 → STOP. No production axis DDL until ratification. This is the same single blocker that has held every prior activation.
2. axis tables already present → STOP (idempotency).
3. zero-drift assertion fails → automatic abort (transaction rolls back).

Relation to human ratification

The axis substrate implies the ownership-model generalization (even via the parallel table, it asserts that the project will govern coverage across multiple axes). That is a sovereignty-level architectural commitment, so the DDL is gated on ospa≥1 exactly like the ownership seed — it is not a low-risk infra change to be slipped in ahead of the gate.

Can axis rollout follow ownership rollout, or must it be separate? (explicit answer)

Separate, and ownership-first is recommended but not required. They are independent because the axis rollout adds only the responsibility axis (active) which is byte-equivalent to today's model, while ownership-seed closes 210→0 in the existing table. Recommended order: (1) human ratification (ospa≥1); (2) ownership-seed (F_prod_*) → gap 210→0; (3) axis rollout (G_prod_*) → formalizes axis-0, gap stays 0; (4) later, governed topic-axis activation with topic owners. Doing axis rollout before ownership-seed is also safe (gap stays 210, just now expressed as axis-0), but ownership-first means the axis layer goes live already covered. Either way, topic activation is always a later, separate governed step — never part of this rollout.