13 - Consolidated Correction Proposal Package (SUPERTRACK M)

9 proposals: 7 blocking, 2 advisory. T1 does NOT edit Codex docs; Codex remains design owner. Each proposal: issue, proposed spec, why, how-to-verify, blocks-implementation.

CP-01 - Surface the byte-level expanded 27-table DDL (or accept explicit downscope)

• Severity: HIGH. Affected doc: 02. Layer: manifest DDL / artifact-completeness.
• Issue: Doc 02 calls itself "Normative full DDL artifact" and says "authored SQL must match the expanded DDL exactly," but the body is contract-level (column names + constraint intent), and the authoritative byte-level CREATE TABLE DDL is deferred to an unsurfaced "local artifact." Doc 10 confirms SA01 must later prove authored SQL matches it - i.e. it is not yet reviewable.
• Proposed: Either (A) publish the expanded per-column DDL (explicit type, PK, all FK, exact CHECK) for manifest_set, manifest_item_envelope, the bootstrap code_catalog, and all 27 children into the reviewable KB; or (B) explicitly downscope this gate: state that the contract-level spec is the approved design, byte-level DDL authoring is a FIX7a author-mode step, and a MANDATORY Codex re-audit of T1-authored SQL (bound by SA01 hash) precedes any apply. Under (B), CP-02/03/04 must still be resolved at spec level because they are design gaps, not authoring detail.
• Why: An implementer cannot "match exactly" an artifact not present; leaving it deferred reopens the FIX..FIX6 divergence loop (new prose graded in isolation while the authoritative artifact drifts). Law: no_fake_PASS, evidence-first.
• Verify: KB contains expanded DDL OR an explicit downscope note + SA01 hash-binding rule; T1 re-review reads it.
• Blocks implementation: YES (path A) / Converts to controlled author-mode (path B with mandatory re-audit).

CP-02 - Specify inter-manifest FK targets

• Severity: HIGH. Doc: 02. Layer: referential integrity.
• Issue: Only the (manifest_id,item_id)->envelope FK is given. Cross-manifest references have no stated FK target/form: e.g. policy_rule_manifest.operator_primitive_id/.fact_id/.operand_type_id; capability_measurement_requirement.capability/.metric; capability_artifact_requirement.capability/.artifact_kind_id; principal_separation_manifest.left_class_id/.right_class_id/.action_id; readiness_gate_manifest.policy_rule_set_id; privilege_set_manifest.privilege_code_id; signoff_requirement_manifest required class.
• Proposed: For each cross-manifest column, state the target table and FK form. Since item_id is globally UNIQUE, define whether cross-child references are by item_id (recommended, FK to manifest_item_envelope.item_id) or by a natural code in the target child; state ON DELETE behavior is moot (no delete) but FK must be NOT NULL where required.
• Why: Without FK targets an implementer guesses integrity (macro guess-trigger: FK targets).
• Verify: every *_id / cross-reference column in doc 02 has a named FK target; negative test "unknown FK" exists per reference.
• Blocks implementation: YES.

CP-03 - Publish the bootstrap code_catalog DDL + seal/ownership (the FK-authority ROOT)

• Severity: HIGH. Doc: 02. Layer: anti-hardcode root / PG-native.
• Issue: "FK-bound sealed code-catalog rows, never CHECK literals" depends on a code_catalog (manifest_type, lifecycle_status, operand_type, ARTIFACT_KIND, privilege_code, volatility_code, ...) whose DDL, seal mechanism, ownership, and write-ACL are unspecified.
• Proposed: Specify the catalog tables with: owner qt001_cp_owner; Directus/PUBLIC no INSERT/UPDATE/DELETE; append-only/sealed semantics (or change requires the same quorum/epoch as manifest activation); each catalog row immutable once referenced; explicit list of code families and which children FK to them.
• Why: If the catalog is mutable/unsealed, authority is PG-hosted hardcode (disguised). It is the single most important anti-hardcode root.
• Verify: catalog DDL present; negative tests for Directus/PUBLIC catalog DML; SA15 scan includes the catalog as a sealed authority surface.
• Blocks implementation: YES.

CP-04 - Enumerate the "exactly-one typed operand" column set + CHECK

• Severity: MEDIUM. Doc: 02 (children 01, 14). Layer: CHECK semantics.
• Issue: "exactly-one typed operand" referenced without the operand column set or the CHECK expression.
• Proposed: Define typed operand columns (e.g. operand_bigint, operand_text, operand_sha256, operand_uuid, operand_code_id) and the CHECK: num_nonnulls(...) = 1 AND the populated column matches operand_type_id (FK catalog). Same pattern for capability_measurement_requirement.
• Why: CHECK not reviewable without columns (macro guess-trigger: schema columns).
• Verify: operand columns + CHECK present; negative tests for zero-operand, two-operand, type-mismatch.
• Blocks implementation: YES.

CP-05 - Seal all gate/vector thresholds; no numeric policy literal in adapters

• Severity: MEDIUM. Docs: 03, 05. Layer: readiness/no-bypass / disguised-hardcode.
• Issue: SCALE_SAFE 600000ms / 1073741824 bytes, CAPABILITY_BEHAVIORAL "exact 3 runs", gate count 14, hash count 7, BV06 Q_CRITICAL_3 read as adapter literals.
• Proposed: State per threshold its sealed source (SCALE_SAFE -> workload_profile_manifest #23 / capability_measurement_requirement #14; "3 runs" -> capability manifest/measurement; "14" -> readiness_gate_manifest.expected_item_count; "7" -> hash_component contract count; Q_CRITICAL_3 -> quorum_requirement_manifest). Add an explicit rule: adapters contain NO numeric policy literal; all thresholds/denominators are read from sealed manifest fields.
• Why: literal thresholds in adapters are disguised hardcode and a mutable-denominator vector if mis-authored.
• Verify: doc states source per threshold; SA15 scans adapters for numeric literals; negative test mutates the sealed value and the gate reacts.
• Blocks implementation: YES.

CP-06 - Pin hash determinism: bytea encoding, array order, numeric form

• Severity: MEDIUM. Doc: 04. Layer: hash canonicalization.
• Issue: bytea(32) SHA-256 values are embedded in jsonb payloads, but jsonb has no bytea type and no encoding is specified (hex vs base64 vs \x) -> non-deterministic hash across implementers.
• Proposed: Universal rule: every bytea embedded in any hash payload is encode(value,'hex') lowercase. Make every array aggregation use a total, unique ORDER BY (e.g. ordinal then item_id). State all numeric payload values are integers in jsonb canonical integer form (floats already forbidden). Record cross-PG-major-version jsonb-text stability as an explicit assumption requiring re-validation on upgrade.
• Why: an unpinned encoding silently breaks every hash-seal the anti-hardcode/anti-bypass argument depends on.
• Verify: doc states the encoding once in the universal rule; sensitivity tests include "same logical value, different bytea encoding -> must produce identical hash" only under the mandated encoding; ORDER BY present in every array map.
• Blocks implementation: YES.

CP-07 - Resolve Directus base-table-vs-view read preservation

• Severity: MEDIUM. Doc: 06. Layer: cutover feasibility.
• Issue: "SELECT only manifest-listed presentation views (base-table SELECT only separately proven)" + "Reads continue through sealed views" is internally ambiguous; if Directus emits base-table queries and base-table SELECT is revoked, the cutover predictably aborts.
• Proposed: State definitively whether Directus (A) retains base-table SELECT on exactly the manifest-listed base tables (simplest; preserves current reads), or (B) is migrated to presentation views with proof that every current Directus-emitted query is covered by a view and Directus is reconfigured accordingly. Preflight must capture Directus's ACTUAL emitted query surface (base table vs view) and evaluate the no-go BEFORE any revoke.
• Why: closes the original feasibility risk so the cutover is a completable forward step, not a guaranteed abort.
• Verify: doc names path A or B; preflight inventory source is Directus's real queries; smoke proves each read post-cutover.
• Blocks implementation: YES (for FIX7b cutover).

CP-08 - Specify registry/evidence table placement, seal, and retention/partitioning (ADVISORY)

• Severity: LOW. Docs: 08, 09, 12. Layer: evidence model / long-horizon scale.
• Issue: human_identity_registry, principal_human_binding, capability-run evidence, dashboard exports are not among the 27 sealed children; their schema/owner/seal and retention/partitioning are not stated.
• Proposed: Place them in qt001_cp, owner-only, append/immutable, Directus/PUBLIC no DML; add a retention/partitioning note (they scale with plans/activations/runs, not object count). Make the dashboard mutable-denominator catch an explicit named check.
• Why: completeness + avoid an unsealed authority/evidence surface; long-horizon growth hygiene.
• Verify: tables listed with owner/seal; retention note present.
• Blocks implementation: NO (advisory).

CP-09 - Bind Level-B CI identity/reviewer to a named manifest (ADVISORY)

• Severity: LOW. Doc: 07. Layer: governance binding.
• Issue: "manifest-approved workload identity / operator human reviewer" do not cite which manifest child binds them.
• Proposed: Cite the binding manifest(s) (authority_scope #20 / principal_class #06 / signoff_requirement #16 / quorum_requirement #19 / human_identity_registry) so the CI identity/reviewer is governed by sealed manifest authority, not a free CI string.
• Why: keeps the Level-B channel under the same authority model as the rest.
• Verify: doc cites the manifest; infra-preflight evidence references it.
• Blocks implementation: NO (advisory).

Summary

Blocking: CP-01, CP-02, CP-03, CP-04, CP-05, CP-06, CP-07. Advisory: CP-08, CP-09. Resolve the 7 blocking (or accept CP-01 path B with mandatory re-audit, and still resolve CP-02..CP-07) -> short T1 re-review -> DESIGN_READY_FOR_CODEX_FINAL_APPROVAL.