Check reference

Check obligation catalog integrity

An obligation can be named in several places. catalog_completeness detects when those names no longer agree, before an undefined class is mistaken for an enforced requirement.

What the check observes

The check enforces four relationships: project-declared obligation classes have catalog definitions; signal-rule obligation references resolve to catalog entries; project catalog entries are declared by the project; and requirement checklist entries are declared or cataloged. Its findings identify the broken relationship. This is integrity checking across the configuration and requirement corpus, not an assessment that every domain hazard has been considered.

Example: a class exists only in the checklist

Illustrative case. SYS-REQ-042 lists a project-specific retry budget obligation, but the project has not declared or defined it. A familiar-sounding name does not tell Proof what evidence or applicability rule that class requires.

# Requirement excerpt
obligation_checklist:
  - retry_budget

# Inspect the project's existing definitions
proof catalog list --source project
proof catalog show retry_budget

Resolve the finding

Decide whether the name is a typo for an existing class or a distinct behavior the project needs to govern.
For a new class, define its applicability and evidence expectations, declare it in project configuration, and use the same ID in signal mappings and checklists.
Withdraw an incorrect reference only when it does not represent an applicable obligation. Keep required but unfinished coverage visible instead of deleting the promise.

Run and interpret

proof audit --check catalog_completeness --verbose

This is a specification-stage error check. Run it after edits to the project catalog, signal mappings, or requirement checklists. The focused command checks this integrity surface only.

A clean catalog can still omit an important requirement or encode a weak evidence rule. Review the class meaning and actual requirement risks separately. Catalog integrity, obligation selection, decomposition, and evidence depth are different checks.

Continue from here

Select applicable catalog obligations. Find classes without enforcement or evidence.

Bring a requirement and the obligation class you expect the project to enforce. Bring a change to Proof.