One-Roof Release Mgmt Finalization — 08 Option 3 Inert Shadow Evaluation (REJECTED) (2026-06-03)
08 — Option 3 Inert Shadow Structure: Evaluation and Verdict
Date: 2026-06-03. Objective F. The release package flagged Option 3 as a "viable interim." This macro evaluates it at execution grade and rejects execution, on a concrete finding the prior analysis did not surface.
Definition
Deploy to production Tier 1 (base structure) + Tier 2 (responsibility axis) only — both effect-inert (gap stays 210, views read 0, emit fail-closed) — skipping Tiers 3–6. To run independent of ratification, Tier 2's ospa≥1 gate would have to be removed ("split the gate"). Stated benefit: "visible progress while ratification pending."
Seven questions
- What is created? Tier 1: 11 tables + 31 views + 1 function (all empty/zero-reading). Tier 2: +1 axis_registry (active), +6 axis_value, +1 active coverage_rule. Tier 2 is gated on ospa≥1 → Option 3 also needs a modified gate-stripped Tier 2.
- Mutates governance truth? Tier 1: no (empty, gap stays 210, existing views untouched). Tier 2: borderline-yes — commits an active coverage rule asserting the responsibility axis requires accountable coverage; no accountability asserted (that's Tier 3) but it's a governance statement deliberately placed behind ospa≥1.
- Changes scanner behavior? Tier 1 creates
fn_governance_scanbut never runs it. With Tier 2's active rule present, if the scanner ran it would materialize a 210-cell gap as drift — latent behavior change. - User-visible/operational side effects? None user-visible:
v_ui_*views read 0 rows until seeds run. So the advertised "visible progress" does not materialize. Adds 43 empty objects an engineer must later explain. - Reversible? Yes —
99_rollback_full.sqlDROPs all (proven idempotent, doc 03). - Helps meaningfully? No — when the gate opens, full
99_run_allcreates Tier 1 + everything in ~1 min anyway; pre-deploying saves nothing and yields no interim user value. - Safer than waiting? No — strictly worse (see decisive finding).
Decisive finding — Option 3 sabotages the canonical executor
00_preflight.sql hard-aborts if axis substrate tables already exist: PREFLIGHT ABORT: axis substrate already present (% tables) — rollout already (partially) applied; use rollback first. Proven live this run (exit 3 on re-apply, doc 03 §3.5). Therefore if Option 3 deploys Tier 1 to production, the day ratification arrives the canonical one-shot rollout refuses to run — its own preflight sees the shadow tables and aborts. The operator must then either rollback the shadow first (erasing the "progress") or hand-modify the validated executor (discarding the preflight/idempotency guarantee). Zero interim benefit traded for a real latent break. "Safer than waiting" fails.
Compliance
Option 3 also collides with the mission Forbidden list ("no axis/topic substrate commit"; "no production truth mutation under the name of 'shadow'") and risks the FAILED criterion.
Verdict — REJECT (no script prepared, none executed)
Rejected: not useful (no visible progress, saves nothing at ratification) and not safer than waiting (breaks the canonical preflight). No shadow script prepared, no production mutation. Correct interim posture: Option 4 (status quo, clone-only) until Option 1 (human ratification) opens the gate, then doc 07's prompt runs the full clean rollout in one shot. Recommend updating the release package's doc 08 Option 3 line from "viable interim" to "rejected — collides with canonical preflight."