Give software requirements enough formal detail

The check selects a non-cross-component spec when both its own type and its parent spec require FRETish. It examines review and approved guarantees whose requirement strategy requires FRETish. Omitted requirement types default to guarantee. The implementation reports empty FRETish and recognized incomplete two-boolean envelopes. Cross-component specs have a separate interface check. The default severity is warning.

A software requirement says retries stop after five attempts. Its formula says only retry_requested implies retry_handled. Both “stop after five” and “retry forever” can fit that vague boolean summary, depending on how handled is defined.

Description obligation: no sixth attempt after five failures
Model needs: attempt count, failure condition, stop decision
Boundary examples: attempts 4, 5 and 6
Code evidence: the branch that decides whether to retry

This sketch identifies missing content; it is not a completed formalization. Define when the counter increments and resets before choosing the temporal rule.

Add the threshold and its outcome to the child's formalization, using declared variables with the correct directions and domains. Keep the child trace connected to its real parent obligation. Genuine prose-only lower layers can use an informal strategy, but that is a scope choice rather than formal verification. Do not move a hard behavioral requirement out of scope to improve a completeness number.

proof audit --check software_formalization_complete --verbose
proof validate --preflight specs/software retry

This content check does not show that the formula is realizable, that the child refines its parent, or that code obeys it. Review those separately with model analysis, cross-layer checks and implementation evidence. The example uses a conventional software spec path; the configured layer may have another name. Treat warning severity independently from the audit failure threshold and any CI merge enforcement.

Follow the evidence

Choose one child requirement and retain the exact bound or exceptional outcome inherited from its parent.

Review one software requirement. Bring its parent obligation and implementation so we can assess whether the child formalization preserves the bounds and exceptional outcomes that matter.

Check system requirements · Inspect parent and child domains