KB-5EDE

RP-03 Consolidated DDL Order + Expected-Constraint Catalog — Refinement

6 min read Revision 1
fix7architecturet1-reviewrp03constraint-catalog

04 - SUPERTRACK D — RP-03 Consolidated DDL Order + Expected-Constraint Catalog (REFINED_BLOCKING)

Two parts

RP-03 has (1) a documentation artifact: one consolidated CREATE + deferred-ALTER order; and (2) an enforcement artifact: a sealed expected-constraint catalog with both-EXCEPT verification. Codex's directive: the expected-constraint catalog must live inside an ALREADY-COUNTED/SEALED authority surface — do NOT introduce a new uncounted expected-constraint table.

Part 1 — Consolidated creation + deferred-ALTER order (documentation, no new surface)

Publish one normative ordered list. Recommended order:

  1. code_catalog_set → code_catalog_family → code_catalog_item (bootstrap, offline quorum).
  2. manifest_set → manifest_item_envelope → operator_operand_compatibility.
  3. The 27 children in dependency order (inline FKs are all backward refs).
  4. Support tables: evidence_registry, human_identity_registry, principal_registry, analyzer_run, manifest_activation, and the RP-01 runtime-evidence tables.
  5. ALL deferred ALTER FKs as one explicit set: the 4 forward (policy_rule.operator_primitive_id, metric.unit_id, capability.workload_profile_id, signoff_requirement.tier_id); the 2 runtime (dependency.analyzer_run_id, dependency.evidence_id); the manifest_set creator/sealed/activated FKs and envelope retired-evidence FK (doc 02 §2.6); the evidence↔principal↔human_identity cross FKs (docs 09/10); and the catalog retirement-evidence FK from RP-07.
  6. Seal/activate. Reversal = exact reverse order, dropping only empty candidate-only objects; catalog root last.

Part 2 — Expected-constraint catalog INSIDE authority_scope_manifest (child 20)

authority_scope_manifest already enumerates protected control-plane objects with expected_owner_role, expected_acl_sha256, source_sha256. Extend it (within surface #20 — NO new surface) so each control-plane TABLE object carries the expected constraint set:

  • Add field expected_constraint_set_sha256 qt001_cp.sha256 — the canonical hash (built per CP-06 H-rules) over that object's ORDERED constraint set.
  • The canonical per-constraint payload (what the sha256 covers, and what the realized snapshot is compared against) must contain, per constraint: constraint_name; table_identity; ordered column list; constraint_type (PK/UNIQUE/FK/CHECK/INDEX); FK target table+columns; ON UPDATE/DELETE action; deferrability; CHECK source (normalized) or index predicate; uniqueness/partial flag; activation version. Store this expected detail as the sealed authority_scope object payload (already hashed into the manifest), so it is reviewable and the sha256 is reproducible.

Verification (both-EXCEPT, PG-native, not source-text-as-authority)

  • Snapshot the REALIZED constraint set from pg_constraint + pg_index + information_schema for each authority_scope table object (these are PG STRUCTURAL catalogs — authoritative truth, not regex/source text).
  • Build the canonical realized constraint set per CP-06 rules; recompute sha256; compare to sealed expected_constraint_set_sha256.
  • Both-EXCEPT name+detail check: missing expected constraint → FAIL; extra unknown constraint → FAIL for authority-relevant types (PK/UNIQUE/FK/CHECK on control-plane tables), or QUARANTINE/operator-review for benign non-authority index types — Codex to choose; default FAIL (fail-closed).
  • A dropped deferred-ALTER FK then makes the realized set MISSING that FK → OBJECT_AUTHORITY_IMMUTABLE fails closed. This converts the prior SILENT integrity hole into a fail-closed readiness block (the whole point of RP-03).

Cross-impact (required fields)

  • Affected docs: 02 (§2.6 + consolidated order), 03 (deferred FKs), 04 (catalog order), 09/10 (support-table order), and authority_scope_manifest #20 definition.
  • Affected contracts/tables/manifests: authority_scope_manifest #20 (gains expected_constraint_set_sha256 + payload); every qt001_cp table whose constraints are in scope.
  • Affected hashes: authority_scope item hash now includes expected_constraint_set_sha256 → manifest_set payload_sha256 → H01 plan_content + H02 control_state.
  • Affected readiness gates: OBJECT_AUTHORITY_IMMUTABLE (extended to compare constraint sets — NO new gate, stays 14), READINESS_MANIFEST_EXACT (exact-set seal).
  • Affected bypass vectors: a missing/altered constraint is an authority-drift bypass; both-EXCEPT closes it.
  • Affected rollback path: the consolidated order defines reversal; a half-applied ALTER set is caught by the constraint exact-set check.
  • Affected Directus/read path: none (authority_scope is control-plane; Directus no access).
  • Affected PG-native enforcement: pg_constraint/pg_index structural reads; canonical hash per CP-06; owner-only authority_scope writes.
  • Affected no-hardcode proof: no new surface (lives in #20); pg_catalog structural truth, not source-text-as-authority.
  • Verification after Codex edits: one consolidated order doc exists and is acyclic given the ALTER split; authority_scope #20 carries expected_constraint_set_sha256; deleting any deferred ALTER FK in rehearsal → OBJECT_AUTHORITY_IMMUTABLE FAIL.

Refined verdict: REFINED_BLOCKING (expected-constraint catalog inside counted surface #20; consolidated order published).

Back to Knowledge Hub knowledge/dev/reports/architecture/t1-fix7-rp-proposal-refinement-cross-impact-2026-06-07/04-rp03-constraint-catalog-refinement.md