Check reference

Follow obligations into children or implementation

An accepted obligation needs a place where it becomes concrete. This check follows each eligible parent's checklist into its active children, or into code when the requirement is a leaf.

What the check observes

A child covers a parent class when it satisfies the parent and either lists the class explicitly or matches its catalog tag predicate. The check works one relationship at a time rather than proving a transitive refinement. A parent suppression resolves that class. When there are no active children, the requirement is a leaf and needs an implementation trace for its remaining obligations. Terminal children do not keep a parent artificially decomposed.

Example: a leaf promise has nowhere to land

Illustrative case. SW-REQ-042 promises bounded retry behavior and carries a boundary obligation. It has no child requirements and no implementing code trace. A complete description alone cannot identify where the promise is realized.

SW-REQ-042
  obligation_checklist: [boundary]
  active satisfying children: none
  implementation traces: none

Decision: trace its implementation or refine it into a real child.

Resolve the finding

Check whether the requirement is genuinely a leaf or whether a missing satisfies link hides an existing child.
For a parent, allocate each obligation to the child that actually governs it. For a leaf, identify the implementation artifact or record unfinished implementation work.
Preserve applicable obligations when deferring work. Use suppression only for a justified non-applicability decision, not as a substitute for missing code.

Run and interpret

proof audit --check obligation_decomposition_complete --verbose

This is a verify-stage warning check. Parent eligibility excludes terminal records, assumptions, and constraints. Explicit deferrals remain visible; accepted known-issue dispositions are separate debt states rather than proof of implementation.

A child's tag match or an implementation trace is structural evidence of allocation, not proof that the code satisfies the class. The check does not run the implementation or establish logical implication between parent and child. Inspect evidence completeness and substantive refinement separately.

Continue from here

Allocate stakeholder classes. Inspect verification evidence.

Bring an obligation that appears in the hierarchy but has no clear implementation owner. Bring a change to Proof.