Practical guide
Find failure sequences in a state model
Some defects live in the order of events rather than in one function call. Model checking analyzes a transition system against properties of its possible behaviors.
Model the choices that can change the outcome
A transition model defines state, initial conditions and allowed steps. A property specifies what those steps must preserve or eventually achieve. Tools such as SPIN support safety and liveness analysis. The important design work is deciding which concurrency, failures and environmental choices belong in the model, and which are deliberately abstracted.
Illustrative example: two workers acquiring a lock
| Step | Worker A | Worker B |
|---|---|---|
| 1 | observes free | idle |
| 2 | has not acquired yet | observes free |
| 3 | enters critical section | has not acquired yet |
| 4 | still active | enters critical section |
The property forbids both workers being active together. This trace violates it if the model allows observation and acquisition as separate steps. Making acquisition atomic in the implementation may repair the protocol. Merely making it atomic in the model would hide the defect unless the source actually provides that guarantee.
Make the assumptions reviewable
Define whether a worker can crash while holding the lock, whether release is guaranteed and whether waiting workers are eventually scheduled. Mutual exclusion is a safety claim. Eventual acquisition is a progress claim and may need fairness assumptions. A model can establish one while failing the other. Keep these properties separate in the result.
Read the verdict and search scope together
A counterexample is a behavior of the model; replay it against the intended system boundary to determine whether it reveals a product defect or an abstraction error. A clean bounded search covers its bound. An exhaustive finite-state result or a successful inductive argument has a different scope. Unknown and resource exhaustion remain undecided outcomes. Name the method and model revision when reporting any of them.
Use Proof without changing the meaning of the method
Proof's component realizability path asks whether an authored contract admits a strategy under its assumptions. It does not automatically model-check the deployed source. Requirements, source lemmas and executed tests provide additional parts of the evidence chain. Select the analysis that answers the question and retain the source connection.
proof realize specs/system lock_controller --format json
This example is a contract-analysis invocation, not a claim that the worker interleaving above was verified by it.
Follow the evidence
Write the shortest failure sequence you fear, then verify that your model can represent it.
Review one failure-sequence model. Bring the transitions and the sequence you need to rule out so we can assess whether the abstraction preserves the relevant system behavior.