KB-151C

One-Roof Release Mgmt Finalization — 08 Option 3 Inert Shadow Evaluation (REJECTED) (2026-06-03)

4 min read Revision 1
one-roof-governancerelease-managementoption3inert-shadowrejectedpreflight-collision2026-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

  1. 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.
  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.
  3. Changes scanner behavior? Tier 1 creates fn_governance_scan but 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.
  4. 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.
  5. Reversible? Yes — 99_rollback_full.sql DROPs all (proven idempotent, doc 03).
  6. Helps meaningfully? No — when the gate opens, full 99_run_all creates Tier 1 + everything in ~1 min anyway; pre-deploying saves nothing and yields no interim user value.
  7. 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."

Back to Knowledge Hub knowledge/dev/reports/architecture/one-roof-release-management-finalization-gate-monitoring-2026-06-03/08-option3-inert-shadow-evaluation.md