04 — Control-Plane Immutability Review (SUPERTRACK D)

Live read-only evidence (2026-06-08, directus DB, no mutation):

• qt001_cp_owner role: does not exist (only directus matched the owner-role probe).
• Owner of qt001_plan_registry, qt001_tier_rule_registry_v2, qt001_independent_review_signoff, qt001_capability_operational_evidence: directus (the app login role) for all four.
• has_table_privilege('directus', 'qt001_independent_review_signoff', INSERT) = true; DELETE = true; INSERT on qt001_capability_operational_evidence = true.
• Row counts: qt001_signoff_plan_binding=0, qt001_capability_operational_evidence=0, qt001_independent_review_signoff=2.

D.1 Who owns authoritative objects?

Design target: NOLOGIN qt001_cp_owner. Live: directus. The cutover has not occurred.

D.2 Can Directus DML/DDL control-plane rows?

Design target: no. Live: yes — Directus owns the tables, so it can INSERT/UPDATE/DELETE rows and ALTER/DROP the tables. Confirmed by ownership + explicit privilege probe.

D.3 Can Directus delete failing readiness gates?

Design target: no (append-only, owner-only). Live: yes — as table owner Directus can DELETE gate/signoff rows (DELETE privilege confirmed true). This is the classic mutable-denominator bypass and is open today.

D.4 Can Directus insert verified capability evidence?

Design target: no (controlled evidence, verifier-bound). Live: yes — INSERT on qt001_capability_operational_evidence confirmed true. Directus could self-attest capability.

D.5 Can Directus insert signoff / principal rows?

Design target: no (FK principal contract, no self-sign). Live: yes — INSERT on qt001_independent_review_signoff confirmed true. Directus could self-sign.

D.6 What blocks readiness until owner/ACL cutover?

Design: authority_cutover_complete=false holds readiness red; readiness manifest is sealed and runtime role has zero DML; FIX7b cutover (owner + REVOKE) is required and operator-gated. Live corroboration: signoff_plan_binding=0 and capability evidence=0 → readiness is BLOCKED and scale NOT_SAFE today regardless of ownership, so there is no present false-green. But the design must guarantee that readiness cannot go green while Directus still owns the tables — i.e. readiness must include an explicit "control-plane owned by qt001_cp_owner AND Directus has no write privilege" gate. The FIX6 line of work already has v_qt001_directus_mutation_blocks_readiness_guard; FIX7 must keep an equivalent gate as a sealed manifest gate, and that is not concretely specified in the FIX7 docs.

D.7 What exact operator step changes owner/ACL?

Not specified. The design says "Level-B DOT/migration pipeline, never manual SQL," but provides no operator step list (REASSIGN OWNED / ALTER TABLE OWNER TO qt001_cp_owner / REVOKE … FROM directus,PUBLIC / GRANT SELECT) and no ordering. Required correction.

D.8 What rollback exists?

Not specified. No rollback snapshot/script for the ownership/ACL cutover is published. FIX7b says "rollback snapshots" are required but does not provide them. Required correction.

Control-plane immutability verdict

INTENT-PASS / LIVE-FAIL / SPEC-INCOMPLETE. The design's containment model (NOLOGIN owner, Directus read-only, append-only sealed manifests, quorum activation, control-epoch) is the correct answer to the FIX4/FIX5/FIX6 "Directus owns 262 control objects" finding. But Directus can still mutate authority today (ownership + INSERT/DELETE proven live), and the operator cutover steps + rollback are unspecified. Per the macro's completion rule: because Directus can still mutate authority before cutover, readiness must remain BLOCKED — which it currently is. This is a primary contributor to DESIGN_BLOCKED_REQUIRES_CODEX_UPDATE (spec) and to the operator-gated nature of FIX7b.