Find requirements thinner than their evidence

The verify-stage warning compares meaningful requirement variables with matched implementation decisions and witness-bearing test density. It uses indexed traces and cached derived metrics, refreshed when relevant authored content or workspace state changes. Thresholds live under project.checks.under_modeled_requirements. Findings distinguish an individual requirement from an inadequately modeled family of requirements sharing an implementation target.

A validator handles empty input, malformed syntax, a numeric range and duplicates. Its only requirement says that a request produces a result. Tests already distinguish the four cases; the model does not explain why their outcomes differ.

Behavior class     Requirement question
Empty input        Reject or accept a default?
Malformed syntax   Which error and which unchanged state?
Outside range      Which exact boundary is enforced?
Duplicate value    Keep, replace or reject?

These are illustrative review questions. More tests or variables do not automatically make the requirement better; each addition should explain an actual obligation.

Inspect the named requirement, code-side decisions and its siblings. Several narrow requirements may correctly explain one shared function. The implementation accounts for collective family coverage, including optional obligation-class policy, while retaining gaps on targets siblings do not explain. Decompose missing behaviors, replace vague booleans with causal conditions, or narrow overbroad implementation and test links.

proof mcdc compare VALIDATION-REQ-001
proof audit --check under_modeled_requirements_clean --verbose

This check does not show that a requirement is false, contradictory or incomplete in every semantic sense. Rich code may be incidental, and a small model can express a strong invariant. Read the actual conditions and assertions before accepting or dismissing the warning. Avoid adding unused variables to improve a ratio; domain and orphan checks should still reflect the real requirement surface.

Follow the evidence

Use the named function's branches to identify the first outcome that no requirement explains.

Review one requirement and its code. Bring the named decisions and sibling requirements so we can identify behavior the current model does not explain.

Inspect omitted comparisons · Review behavioral completeness