KB-1520

RP-04 Catalog-Family Enforcement Coverage — Refinement

5 min read Revision 1
fix7architecturet1-reviewrp04catalog-family-coverage

05 - SUPERTRACK E — RP-04 Catalog-Family Enforcement Exact-Set Coverage (REFINED_BLOCKING)

Decision: all three contracts are MEMBERS of code_catalog (the root surface) — no new surface

The three enforcement contracts must be code_catalog FAMILIES, so they live inside the single already-counted/sealed authority root (code_catalog), not as distinct uncounted support contracts:

  1. reference_contract — already a bootstrap family (doc 04). Maps each catalog-typed FK column → expected family_id. Consumed by fn_assert_catalog_family.
  2. operand_column_contract — make it a code_catalog family. Maps each operand_type item → its physical operand column (and the fixed column set). Consumed by fn_assert_typed_operand.
  3. structural_literal_class (SA15 classification) — make it a code_catalog family. Classifies each permitted structural numeric literal (datatype shape) so SA15 can fail any UNCLASSIFIED numeric literal in adapter/function source.

Family count moves 16 → 18; this is DATA-driven via code_catalog_set.expected_family_count (no hardcoded count in code), so it is not hardcode. doc 04's family taxonomy text must explicitly list these three.

Exact-set coverage checks (at seal; fail-closed)

  • reference_contract: COUNT of catalog-typed FK columns across all 27 children + support tables == COUNT of reference_contract rows, AND both-EXCEPT match by (table, column). Any catalog-typed FK column with no reference_contract row → SEAL FAIL.
  • operand_column_contract: every operand_type item in the ACTIVE catalog has exactly one operand_column_contract row, and the union of mapped columns == the fixed operand column set on policy_rule_manifest / capability_measurement_requirement (both-EXCEPT). Missing/extra → SEAL FAIL.
  • structural_literal_class: SA15 enumerates every numeric literal in every hash-bound adapter/function source; each must match a structural_literal_class entry; any unclassified literal → readiness FAIL (this is the CP-05 SA15 blocker, now backed by a sealed classification family rather than an implicit allow-list).

Negative tests

  • Missing reference_contract row for a catalog-typed FK column → SEAL FAIL.
  • Missing operand_column_contract row for an operand type → SEAL FAIL.
  • Unclassified numeric literal in an adapter → readiness FAIL.
  • Add a new catalog-typed column without its reference_contract row → SEAL FAIL (regression guard).

Cross-impact (required fields)

  • Affected docs: 03 (CP-02 family-by-seal), 04 (CP-03 taxonomy — add 2 families), 05 (CP-04 operand), 06 (CP-05 SA15).
  • Affected contracts/tables/manifests: code_catalog_family/code_catalog_item (3 families); operator_operand_compatibility; every child with a catalog-typed FK column; every adapter/operator_primitive source.
  • Affected hashes: code_catalog payload hash (families/items) → flows into plan_content H01 (policy/operator manifest) and control_state H02 (active catalog). Adding families changes catalog payload_sha256 deterministically.
  • Affected readiness gates: READINESS_MANIFEST_EXACT (catalog seal), CAPABILITY_BEHAVIORAL / TIER_POLICY_PASS / SIGNOFF_AUTHENTIC (adapters resolve operands via operand_column_contract), and the CP-05/SA15 numeric-literal blocker feeding multiple gates.
  • Affected bypass vectors: an unmapped catalog column or unclassified literal is a disguised-hardcode bypass; exact-set coverage closes it.
  • Affected rollback path: catalog change = new sealed catalog version; coverage re-verified at each seal.
  • Affected Directus/read path: none (catalog is owner-only).
  • Affected PG-native enforcement: code_catalog FK + seal functions (fn_assert_catalog_family, fn_assert_typed_operand) with NO literals; SA15 over hash-bound source as a fail-closed blocker (not authority-granting).
  • Affected no-hardcode proof: closes the contract-coverage hole in supertrack J; makes the anti-hardcode ROOT provably complete.
  • Verification after Codex edits: doc 04 lists all 3 families; seal fails on any catalog-typed column / operand type / numeric literal lacking its contract row; family count is data-driven via expected_family_count.

Refined verdict: REFINED_BLOCKING (3 families inside code_catalog root; exact-set coverage at seal).

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-rp-proposal-refinement-cross-impact-2026-06-07/05-rp04-catalog-family-coverage-refinement.md