13 - SUPERTRACK M — Residual Correction Proposal Package

8 residual proposals (RP-01..RP-08): 4 BLOCKING, 4 ADVISORY. These are NEW issues surfaced by cross-impact of Codex's own corrections; the prior CP-01..CP-09 are individually resolved. T1 does NOT edit Codex docs; Codex remains design owner. Numbered RP-* to distinguish from the prior CP-* set.

RP-01 — Define (or explicitly downscope) the runtime instance/result/evidence tables consumed by H04/H05/H06 and partitioned by doc 09

• Severity: HIGH (BLOCKING — artifact completeness / no-guess).
• Affected docs: 07 (H04/H05/H06 key maps), 09 (named partition targets), 10 (signoff/binding).
• Affected layer: runtime evidence / hash determinism.
• Current issue: the published hash key-maps reference instance sub-payloads — H04 reviewer_*/binder_* (per-activation signoff/binding rows), H05 run/measurements/artifacts/environment (capability run/measurement/artifact rows), H06 roots/edges/source_hashes/analyzer_run/dynamic_targets — and doc 09 names "high-volume capability/gate/analyzer result events, denied-attempt evidence, dashboard exports, Level-B packet executions" for partitioning. None of these instance/result tables has a published byte-level CREATE TABLE. The package thus hashes and partitions tables it never defines.
• Proposed correction: EITHER (A) publish byte-level DDL for each instance/result table (owner qt001_cp_owner, append-only/immutable, FK to manifest_set/activation/principal_registry/evidence_registry, partition key) so each H04/H05/H06 sub-payload key maps to a named table+column set; OR (B) explicitly downscope (CP-01 path-B pattern): declare them FIX7-author-mode tables under the same owner/seal/append-only/hash rules, and bind a MANDATORY rule that their exact columns are pinned and Codex-re-audited (hash-map column binding) BEFORE any apply.
• Why needed: without instance columns, H04/H05/H06 are not byte-implementable → reopens the FIX..FIX6 divergence loop the corrected package was meant to close. Law: evidence-first, no_fake_PASS.
• How to verify: every H04/H05/H06 sub-payload key resolves to a named table.column; every doc-09 partition target has a CREATE TABLE; T1 re-review reads them.
• Blocks design approval: YES.

RP-02 — Reconcile the "ACTIVE sealed retention policy" numeric authority with the "exactly 27 / no 28th surface" invariant

• Severity: MEDIUM (BLOCKING — anti-hardcode coherence).
• Affected docs: 06 (CP-05 no-28th-surface), 09 (retention interval/capacity), 11 (self-review items 3 vs 8).
• Affected layer: readiness/no-bypass / disguised-hardcode.
• Current issue: doc 09 + self-review item 8 introduce an "ACTIVE sealed retention policy" carrying numeric interval + capacity-threshold authority that decides partition-maintenance behavior, but no retention/storage-policy manifest exists among the exactly-27, and CP-05 + self-review item 3 explicitly forbid an uncounted 28th authority surface. Internal contradiction.
• Proposed correction: state precisely which sealed surface holds retention interval/capacity — either (i) add a retention/storage-policy contract as an explicitly counted additional sealed surface (and update "exactly 27" to the new exact count, with seal/hash/quorum identical to the others), or (ii) host the values in an existing manifest (e.g. a storage/workload policy contract) and name it. Include them in the relevant control-state/readiness hash and exact-set seal.
• Why needed: an uncounted authority surface is precisely the disguised-extra-authority-surface this program rejects; leaving it both "sealed" and "not one of the 27" is unfalsifiable. Law: no disguised hardcode; exact-set sealed authority.
• How to verify: doc names the sealed surface + its count status + hash inclusion; negative test — mutate retention interval/capacity without new activation → partition-maintenance/readiness gate fails closed.
• Blocks design approval: YES.

RP-03 — Publish one consolidated object-creation + deferred-ALTER order and exact-set constraint verification

• Severity: MEDIUM (BLOCKING — integrity completeness).
• Affected docs: 02 (§2.6), 03, 04, 09, 10.
• Affected layer: referential integrity / apply order.
• Current issue: the global CREATE order and the complete deferred-ALTER FK set are split across five docs, and several cross-table FK cycles exist (evidence_registry ↔ principal_registry ↔ human_identity_registry; manifest_set ↔ manifest_activation; manifest_item_envelope → evidence_registry; code_catalog_item retirement evidence). An implementer must reconstruct a topologically valid order and the exact ALTER set. A forgotten ALTER FK is a SILENT (not fail-closed) loss of referential integrity.
• Proposed correction: publish one normative ordered list — catalog root → manifest_set → manifest_item_envelope → 27 children → support tables (operator_operand_compatibility, evidence_registry, human_identity_registry, principal_registry, analyzer_run, manifest_activation) → ALL deferred ALTER FKs (the 4 forward + 2 runtime in doc 03, the manifest_set/envelope FKs in doc 02 §2.6, the evidence↔principal↔identity ALTERs in docs 09/10, and the catalog retirement-evidence FK from RP-07) → seal/activate. Add an exact-set verification that the realized FK/constraint set in qt001_cp equals a sealed expected-constraint catalog (both EXCEPT directions), so no ALTER can be silently omitted.
• Why needed: completeness + makes a dropped FK fail-closed instead of silent. Cross-impact safety: "changing one detail can break another layer."
• How to verify: one ordered DDL list exists and is acyclic given the ALTER split; a seal/SA check compares realized constraints to the sealed expected set.
• Blocks design approval: YES.

RP-04 — Enumerate and exact-set-cover the catalog-family enforcement contracts

• Severity: MEDIUM (BLOCKING — anti-hardcode coverage).
• Affected docs: 03 (reference_contract), 05 (operand_column_contract), 06 (SA15 structural-literal classification), 04 (taxonomy).
• Affected layer: anti-hardcode root.
• Current issue: family/type/literal enforcement is delegated to sealed "contract" surfaces — reference_contract (catalog-typed FK column → expected family), operand_column_contract (operand_type → physical column), and the SA15 structural-literal classification catalog. Doc 04's bootstrap-family list names only "reference contract." If any catalog-typed FK column lacks a reference_contract row, or any operand type lacks an operand_column_contract row, that column silently loses family/type enforcement (the bare FK still passes any catalog item) — a disguised hole.
• Proposed correction: enumerate all three contract surfaces in doc 04's sealed taxonomy; specify that seal FAILS unless coverage is exact — one reference_contract row for every catalog-typed FK column, one operand_column_contract row for every operand type, and SA15 structural-literal classification present for every adapter numeric literal. Reconcile naming (are operand_column_contract and SA15 classification members of reference_contract or distinct sealed families?).
• Why needed: the entire anti-hardcode argument rests on these contracts; partial coverage = unsealed authority hole. Law: no disguised hardcode.
• How to verify: doc 04 lists all three as sealed surfaces; a seal/SA check fails on any catalog-typed column or operand type missing its contract row.
• Blocks design approval: YES.

RP-05 — Structurally enforce that code_catalog_item.item_payload is descriptive-only

• Severity: LOW (ADVISORY).
• Affected docs: 04, 06 (SA15).
• Affected layer: disguised-hardcode.
• Current issue: item_payload jsonb NOT NULL is declared descriptive-only, but nothing structurally prevents an adapter from reading operational values out of it (policy hidden in jsonb).
• Proposed correction: add an explicit rule + SA15 scan: no readiness/gate/vector/capability adapter may read code_catalog_item.item_payload for operational decisions; operational values come only from typed child columns.
• Why needed: keeps the "catalog cannot become another hardcode registry" guarantee enforceable, not merely asserted.
• How to verify: SA15 flags any adapter referencing item_payload operationally.
• Blocks design approval: NO (advisory).

RP-06 — Back the same-human-one-slot control with a DB-level UNIQUE constraint

• Severity: LOW (ADVISORY; depends on RP-01).
• Affected docs: 09/10 + the signoff/binding instance table from RP-01.
• Affected layer: governance / separation.
• Current issue: same-human-cannot-fill-two-slots is enforced by preflight logic + H04 hash binding, but doc 09 lists only an INDEX (activation_id, human_identity_id), which is not a uniqueness guarantee.
• Proposed correction: add UNIQUE(activation_id, human_identity_id) on the per-activation signoff/binding instance table so separation is PG-native fail-closed.
• How to verify: two signoff rows with the same (activation_id, human_identity_id) reject at DB level.
• Blocks design approval: NO (advisory).

RP-07 — Make catalog retirement-evidence FK consistent

• Severity: LOW (ADVISORY).
• Affected docs: 04, 09.
• Affected layer: integrity consistency.
• Current issue: code_catalog_item.retired_reason_evidence_id uuid NULL has no FK to evidence_registry, unlike manifest_item_envelope.retired_reason_evidence_id which gets an ALTER FK in doc 02 §2.6.
• Proposed correction: add the deferred ALTER FK (after evidence_registry exists; include in RP-03's order), or document why catalog retirement evidence is intentionally not FK-bound (bootstrap ordering).
• How to verify: catalog retirement evidence is FK-bound or explicitly excepted with rationale.
• Blocks design approval: NO (advisory).

RP-08 — Require Directus preflight observation-window completeness

• Severity: LOW (ADVISORY).
• Affected doc: 08.
• Affected layer: cutover feasibility.
• Current issue: the preflight derives Directus's "actual emitted query surface" from collection metadata + db access/audit evidence; an under-representative audit window could miss a rarely-emitted base-table read.
• Proposed correction: require the preflight evidence to assert observation completeness (min coverage period / source-completeness attestation) and fail closed if insufficient.
• How to verify: preflight evidence states observation completeness; insufficient window → BLOCKED_READ_PATH.
• Blocks design approval: NO (advisory; the both-EXCEPT-direction smoke already fails closed on any unmanifested read).

Summary

Blocking (must close before final approval): RP-01, RP-02, RP-03, RP-04. Advisory: RP-05, RP-06, RP-07, RP-08. Resolve the 4 blocking (RP-01 may take the explicit-downscope path B with mandatory re-audit) → republish → short T1 re-review → DESIGN_READY_FOR_CODEX_FINAL_APPROVAL → Codex final approval. No implementation, Stage 2.6B, permit, REAL_RUN, or QT001 apply before that.