Check a delegated obligation has a real owner

What the check observes

Each delegation must name a known class and an existing target requirement whose checklist carries that same class. The check also detects cycles, a rationale shorter than 32 characters, and a class that is both delegated and suppressed on the same requirement. The target's checklist makes the claim inspectable: removing the class there can break the delegation later.

Example: two requirements point responsibility at each other

SYS-REQ-042: rate_limit_respected → SYS-REQ-073
SYS-REQ-073: rate_limit_respected → SYS-REQ-042

Resolve the architecture:
Which requirement directly governs the actual limiter?

Resolve the finding

1. Resolve the class definition and inspect what behavior the delegation is assigning.
2. Choose the true owning requirement and ensure its checklist and evidence plan account for the obligation. Break cyclic delegation by making ownership explicit.
3. Write why the target owns the concern. If the obligation is locally required but unfinished, track a deferral; if it does not apply, review a suppression instead.

Run and interpret

proof audit --check obligation_delegation_resolves --verbose

This is a specification-stage error check. Delegation and suppression are distinct declarations and cannot simultaneously resolve the same class on one requirement.

A well-formed delegation proves neither that the target implements the behavior nor that its evidence is sufficient. A resolvable target can still be the wrong owner. Review the real architecture and authority for moving responsibility, then inspect the target's verification state. A rationale length floor is a minimum record-shape rule, not a judgment of the reasoning.

Continue from here

Understand baseline dispositions. Check the owner's evidence.

Bring an obligation that is said to be handled elsewhere and the proposed owning requirement. Bring a change to Proof.