Check reference

Check the shape of requirement levels

A project can contain several requirement levels while leaving gaps between them. levels_connected checks a small set of structural conditions that reveal disconnected specification setup.

What the check observes

The implementation counts active requirements by configured spec type. It reports an empty configured level, stakeholder and software/integration levels with no system level between them, and components that contain both system and software/integration requirements but have no software-to-system satisfies link. Unknown spec mappings are not treated as a validated level. These conditions are narrower than proving every node reaches a stakeholder need.

Example: two levels share a component but no link

Illustrative case. The payments component has system and software requirements, but none of its software requirements names a system parent. Both directories may be populated and locally readable while their relationship is missing.

Component: payments
  L1: SYS-REQ-042, SYS-REQ-043
  L2: SW-REQ-101, SW-REQ-102
  L2 → L1 satisfies links: none

Review which system behavior each software requirement refines.

Resolve the finding

  1. Inspect whether an empty configured level is planned work or a configuration mistake. Keep genuinely required missing work visible.
  2. For a hierarchy gap, author the system-level behavior that connects the stakeholder need to software responsibilities.
  3. For a component finding, review and add the legitimate satisfies links. Then run per-requirement checks, because one component link cannot validate every child.

Run and interpret

proof audit --check levels_connected --verbose

The current check is specification-stage and error severity. It counts active records, excluding retired, superseded, and rejected requirements. Components without a declared component name do not participate in its component-pair predicate.

A passing result is not full graph connectivity, complete stakeholder provenance, or proof of correct decomposition. Use system_requirements_linked and l2_software_complete for their per-record predicates, plus substantive review of the relationships. A diagram can make missing or implausible links easier to inspect.

Continue from here

Inspect the hierarchy visually. Check each software parent link.

Bring a requirement hierarchy whose levels exist but do not explain how the product promise reaches code. Bring a change to Proof.