03 - SUPERTRACK C — CP-03 Code Catalog Bootstrap / Seal / Ownership Review

Source reviewed: doc 04-cp03-code-catalog-bootstrap-seal-ownership.md (revision 2).

Verdict: CP03_VERIFIED

This is the anti-hardcode authority ROOT (my CP-03 called it the single most important surface). Codex published byte-level DDL for code_catalog_set / code_catalog_family / code_catalog_item.

Checklist evidence

• Exact catalog DDL — VERIFIED. Three tables with explicit columns, PKs, composite FK code_catalog_item(catalog_set_id,family_id)→code_catalog_family, UNIQUE(item_id), business-key UNIQUEs, ordinals.
• Code taxonomy — VERIFIED, and PG-native: required families (manifest type, lifecycle status, operand type, value type, artifact kind, privilege code, volatility, dependency kind, resolution status, scope type, quorum profile, rule set, fact definition, canonicalizer, unit, reference contract) are ROWS, not code literals; their exact set/count comes from the candidate catalog set and is bound by expected_family_count/expected_item_count. No family-count literal in code.
• Seal/hash fields — VERIFIED (version_no UNIQUE, payload_sha256, family_sha256, item_sha256, candidate_control_epoch, sealed_at, activated_at, superseded_by_*; CHECK activated_at IS NULL OR sealed_at IS NOT NULL).
• One-active enforcement — VERIFIED (CREATE UNIQUE INDEX ... ON code_catalog_set((true)) WHERE activated_at IS NOT NULL AND superseded_by_catalog_set_id IS NULL → at most one active catalog set globally).
• Ownership / Directus privileges — VERIFIED (all three owner qt001_cp_owner NOLOGIN; Directus/PUBLIC/runtime no DML/TRUNCATE/REFERENCES/TRIGGER/ownership/CREATE/EXECUTE; curated SELECT views only via ACTIVE privilege manifest; only owner SECURITY DEFINER entrypoints write).
• Activation state — VERIFIED (bootstrap packet is the only pre-catalog op, requires offline exact critical-quorum evidence; thereafter every change is a new candidate set, exact-set sealed, SHA-256-bound, quorum-activated, epoch-incrementing; referenced/active/history rows immutable; rollback = new version with prior payload).
• FK usage — VERIFIED (catalog item is the FK target for catalog-typed columns; family correctness via seal function per CP-02).
• Negative tests — VERIFIED (Directus/PUBLIC DML, update sealed, delete referenced, duplicate/reused ID, wrong count/hash/ordinal, unknown family, non-object item_payload, activation without quorum, rollback editing history).
• Catalog cannot become another hardcode registry — VERIFIED for the typed-value path: "operational typed values live in named child columns," and item_payload is constrained to jsonb_typeof='object' and declared descriptive-only.

Residuals (carried to RP, not CP-03 defects)

• RP-05 (advisory): item_payload jsonb NOT NULL is a LATENT disguised-hardcode surface. The "descriptive-only, never interpreted as policy" claim is a discipline assertion with no structural/scan enforcement. Add an explicit rule + SA15 scan that no readiness/gate/vector/capability adapter reads item_payload for operational decisions.
• RP-07 (advisory): 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. Likely a bootstrap-ordering artifact (catalog precedes evidence_registry). Either add the deferred ALTER FK after evidence_registry exists, or document the exception.

Conclusion

The root catalog is sealed, owner-only, versioned, exact-set/hash bound, and family codes are data not literals. CP03_VERIFIED; the item_payload discipline (RP-05) and retirement-evidence FK consistency (RP-07) are carried as residuals.