Check reference
Reconcile a requirement's variable list with its formula
A variable rename can update the formal sentence while leaving its metadata behind. variable_drift compares the authored list with the variables parsed from that same requirement.
Two representations of one requirement
The specification-stage warning checks requirements that have both FRETish text and a nonempty variables: list. It reports variables used by the formula but missing from the list, and listed variables the formula no longer uses. The parser supplies the comparison set. Empty lists, freeform text and unparseable sentences do not provide a comparable pair for this check.
Illustrative example: a renamed trigger
fretish: the worker shall always satisfy job_requested => job_accepted
variables:
- request_received
- job_accepted
Here request_received is stale and job_requested is missing from the list. Before replacing the name, confirm that the rename preserved its meaning. A new trigger could intentionally differ from the old one, in which case downstream requirements and evidence may also need review.
Use the parser's view
Compile the sentence and inspect semantics.variables. Reconcile the authored list with that output, then check that declarations exist in the owning component. If a removed name is now unused everywhere, review its declaration as a possible orphan. Keep remembered state and external inputs distinct; this check cannot decide ownership from a matching spelling.
proof compile "the worker shall always satisfy job_requested => job_accepted" --format json
proof audit --check variable_drift --verbose
The example sentence demonstrates the inspection workflow. The requirement's real temporal meaning still needs review.
Agreement is not a complete variable model
Matching names say nothing about value ranges, direction, concrete source binding or the adequacy of the formula. An absent list makes no disagreement claim and can pass this check while another declaration check fails. Do not erase a useful list just to avoid comparison. Repair the inconsistency, then rerun preflight and any analysis affected by a semantic change.
Follow the evidence
Use the parser's variable set to review one changed requirement before updating its metadata.
Review one variable mismatch. Bring the changed sentence and variable list so we can assess whether the difference is a stale name or a semantic change affecting other evidence.