Check reference

Review prose changes against formal intent

Changing a requirement's prose while leaving its formal expression untouched can create two conflicting versions of intent. description_delta_reviewed asks for that difference to be resolved.

What the check observes

The branch-aware check looks for description changes on FRETish-backed requirements whose FRETish did not change and that lack an appropriate impact review. A no-formalization-change decision records that the wording changed without changing the formal promise. It is not permission to make the prose describe new behavior while retaining a convenient old formula.

Example: from one retry to several retries

Illustrative case. The description changes from “retry once” to “retry until the deadline.” The existing formalization still permits only one retry. Calling this a clarification would preserve a contradiction between two requirement fields.

Description before: retry once after a transient failure.
Description after: retry until the request deadline expires.

Review question:
Did the approved retry policy change, or is the new wording wrong?

Resolve the finding

Compare old and new descriptions with the current formula, variable definitions, bounds, and assumptions.
For a true clarification, explain why the formalization still captures the same guarantee and record the no-formalization-change decision.
For a behavior change, update the governing requirement through the authorized change process and rerun the affected model and implementation checks. Correct an accidental prose edit instead of changing intent to fit it.

Run and interpret

proof audit --check description_delta_reviewed --verbose

This verify-stage check has error severity. A focused audit exposes the relevant branch delta and review state. Review decisions follow project policy; neither the writer's identity nor a fluent explanation alone determines authority to alter the requirement.

This check detects a particular review gap. If the configured Git base cannot be compared, its summary reports that the description review was skipped; read that limitation even when the result is displayed as pass. It does not establish semantic equivalence between arbitrary prose and FRETish, and a recorded decision can still be mistaken. A no-formalization-change review concerns wording, while no-authored-change concerns a code impact claim.

Continue from here

Review code impacts. Connect prose, models, and executable evidence.

Bring a wording change whose effect on the formal promise is unclear. Bring a change to Proof.