Check reference
Check whether a requirement actually constrains behavior
“Whenever a request arrives, a response follows” says little if the model forbids requests. vacuity_clean helps distinguish meaningful analyzed requirements from vacuous or unchecked ones.
Why a true formula can be unhelpful
An implication is true whenever its antecedent is false. That logical rule is useful, but it can conceal a model mistake: an assumption may prevent the trigger, or a formula may make the intended response irrelevant. Vacuity analysis investigates whether the requirement meaningfully constrains the modeled behavior. The audit check warns both about potentially vacuous results and eligible formalizations with no vacuity result.
Illustrative example: an unreachable retry
Assumption: retry_requested is always false
Guarantee: when retry_requested, a retry completes
Review question: can the intended trigger ever occur?
The guarantee can hold without any retry completing. If real clients can request retries, the assumption is wrong. If the operation truly cannot occur in this mode, narrow the requirement's scope and explain where the behavior is specified instead. Do not invent a test event that the reviewed model explicitly excludes.
Separate vacuous from unchecked
Read the finding's state. For a vacuous result, inspect triggers, temporal scope, assumptions and response formulas together. For an unchecked result, first determine why the requirement did not receive eligible analysis. Refresh verification after fixing the model or analysis path. Solver timeout and unsupported translation should remain visible as uncertainty, rather than being treated as evidence of meaningful behavior.
proof workflow check --stage verify --verbose
proof audit --check vacuity_clean --verbose
A nonvacuous model still needs a code connection
Vacuity is one dimension of model quality. A nonvacuous requirement may still omit an error case, use an unrealistic input domain or describe behavior the implementation never follows. Pair it with domain and gap analysis, then retain executed witnesses for the implementation. The check's default warning severity does not itself describe merge behavior; audit failure policy and the required CI integration determine enforcement.
Follow the evidence
Try to construct one reachable trigger and one behavior the requirement forbids.
Review one vacuity finding. Bring the trigger, assumptions and response so we can assess whether the intended behavior can occur and what the formula actually rules out.
Find unspecified outputs · Understand the different formal questions