02 - SUPERTRACK B — CP-02 Inter-Manifest FK Targets Review

Source reviewed: doc 03-cp02-inter-manifest-fk-targets.md (revision 1), cross-checked against doc 02 inline FKs.

Verdict: CP02_VERIFIED

Checklist evidence

• FK targets explicit — VERIFIED. The "Exact Typed FK Map" names target table+column for every cross-reference I listed in CP-02 (operator_primitive_id, fact_id, operand_type_id, unit_id, value_type_id, volatility_code_id, action_id, left/right_class_id, policy_rule_set_id, canonicalizer_id, dependency_kind_id/resolution_status_id, analyzer_run_id/evidence_id, verifier_class_id, workload_profile_id, capability/metric/operator ids, artifact_kind_id, scope_type_id, tier_id, required_principal_class_id, target_manifest_type_id/quorum_profile_id, privilege_code_id, gateway_item_id).
• code_catalog root sealed — VERIFIED (catalog references target code_catalog_item.item_id; see CP-03 review).
• Typed FK map / actions clear — VERIFIED. All FKs ON UPDATE RESTRICT ON DELETE RESTRICT NOT DEFERRABLE; rationale (no physical delete; RESTRICT is defense-in-depth) stated.
• Forward vs inline split is correct and non-contradictory — VERIFIED. I cross-checked doc-02 inline FKs against doc-03's ALTER block. Inline cross-child FKs in doc 02 are all BACKWARD references in creation order (e.g. principal_separation→authority_action/principal_class; capability_measurement_requirement→capability/metric/operator; writer_repoint→gateway). The 4 FORWARD references that cannot be inline are correctly deferred to ALTER: policy_rule.operator_primitive_id, metric.unit_id, capability.workload_profile_id, signoff_requirement.tier_id. The 2 runtime FKs (dependency.analyzer_run_id→analyzer_run, dependency.evidence_id→evidence_registry) are deferred until docs 09/10 tables exist. No FK is double-defined.
• No activation deadlock — VERIFIED (lock order: control_epoch → manifest_set → catalog set → child tables in deterministic table-name/item-id order; FK validation reads already-sealed parents, never activates one).
• No orphan manifest reference — VERIFIED. Cross-child FKs target <child>.item_id (each child has UNIQUE(item_id)), not the generic envelope.
• No Directus-editable authority — VERIFIED (owner-only; see CP-01/CP-03/CP-07).
• Family correctness — VERIFIED as a mechanism: a bare FK to code_catalog_item(item_id) only proves "some catalog item." Family correctness (e.g. operand_type_id is specifically family OPERAND_TYPE) is enforced at SEAL by fn_assert_catalog_family(item_id, expected_family_id) reading the expected family ID from the sealed reference_contract catalog — no family string literal in code. Sound and PG-native.
• Negative tests — VERIFIED (wrong typed target, unknown target, retired target, family mismatch, delete referenced parent, activation-order inversion).

Residual (carried to RP-04, not a CP-02 target defect)

The seal-time family check is only as strong as the COVERAGE of reference_contract: if a catalog-typed FK column has no reference_contract row, its family is silently unchecked (bare FK passes any catalog item). The spec states the function holds no literals (good) but does not state that reference_contract coverage is itself exact-set-verified (one row per catalog-typed column, seal fails on any gap). This is a disguised-hole risk → RP-04.

Conclusion

FK targets and actions are fully specified and internally consistent with doc 02. CP02_VERIFIED; the family-enforcement coverage guarantee is carried as RP-04.