Check reference
Check the contract's variable boundary before solving it
A solver answers the model it receives. variables_declared preflight checks that the model's names and ownership are coherent before that answer is useful.
Who controls each value?
A caller-controlled value belongs on the input side. A component-produced result is an output. Remembered values need a state model. Proof's mode variables are controllable in the generated contract; a caller-selected setting called a mode in product prose may therefore need direction: input. Names alone cannot settle this choice. Undeclared variables and invalid directions are hard preflight errors.
Illustrative example: a client-controlled limit
A request contains requested_limit, while the server decides accepted_limit. A guarantee that the client always sends a positive request tries to control the environment. The intended rule may instead require the server to reject nonpositive requests.
requested_limit: input
accepted_limit: output
rejected: output
Behavior to specify:
nonpositive request -> rejection
valid request -> bounded accepted limit
If positivity is a real environmental assumption, state who enforces it at the boundary. Do not make malformed input disappear just because that simplifies the proof.
Run the component preflight
Correct declarations and directions in the owning variable file, then rerun the affected component's preflight. The check also gives structural advice on guarantee conjuncts supported only by input variables. Such an advisory is not a solver proof of unrealizability. A matching unconditional assumption can explain an input constraint; a merely overlapping assumption does not establish the same condition.
proof validate --preflight specs/system limits
proof audit --check variables_declared --verbose
Preflight readiness is not verification
A clean boundary model can still be incomplete or wrong about production data. Preflight does not establish realizability, absence of vacuity, or code conformance. Direct preflight can exit successfully with warnings, whereas an audit using its default warning failure threshold can fail on them. Preserve that command-policy distinction when wiring CI and reporting a result.
Follow the evidence
Write down who chooses each disputed value before changing its direction.
Review one contract boundary. Bring the preflight finding and component interface so we can assess who controls each disputed value before changing the model.
Review environmental assumptions · Inspect unconstrained behavior