Find obligation classes with no enforcement backing

What the check observes

For an active requirement's cataloged checklist class, the check looks for either signal-rule backing or evidence. Signal mappings and built-in rule metadata can name the class. Evidence may be an annotation, an authored obligation-evidence cell, or a satisfying profile result. A finding requires both forms of backing to be absent. Suppressed, deferred, and delegated classes are already dispositioned and are excluded from this predicate.

Example: a project class has a definition but no check

Class: retry_budget
Catalog definition: present
Requirement checklist: present
Signal-rule mapping: absent
Evidence for requirement/class pair: absent

Resolve the finding

1. Read the class definition and decide how this concern should be observed in the project.
2. Add an appropriate signal mapping or genuine evidence source. Scenario classes may legitimately rely on tests rather than static signals.
3. If the obligation is applicable but not yet backed, track the work explicitly. Do not attach an unrelated rule or test merely because it uses the same class name.

Run and interpret

proof audit --check obligation_enforcement_backed --verbose

This specification-stage check defaults to warning. An explicitly disabled check reports skip, not pass. The audit CLI defaults to a warning failure threshold unless project configuration overrides it.

One backing signal or evidence cell is enough for this check. That does not establish complete evidence depth, a passing execution, or adequate assertions. Uncataloged classes belong to catalog_completeness; missing required evidence types belong to obligation_evidence_complete. Read those results together rather than treating one clean check as full verification.

Continue from here

Resolve catalog integrity. Check required evidence types.

Bring a checklist class that appears enforced but has no identifiable observation behind it. Bring a change to Proof.