Practical guide
Scope a formal verification engagement around a decision
A useful verification engagement ends with evidence that helps someone decide what may ship. Begin with the behavior at risk and its implementation boundary.
Bring a claim and a reason it matters
“Verify payments” is too broad. “Retrying a completed request cannot create a second charge” is a useful starting claim. Identify the public entry point, persistence boundary, concurrency model and supported environments. Decide whether failures before and after database commit are included. Those details determine the model and the reproductions needed.
Illustrative engagement brief
| Item | Example decision |
|---|---|
| Behavior | Completed requests cannot charge twice |
| Boundary | Payment API, idempotency store and transaction |
| Cases | Concurrent duplicates, timeout after commit, restart |
| Evidence | Reviewed model, reproductions and scoped results |
| Acceptance | Supported outcomes and recorded unresolved cases |
Agree on exclusions as carefully as included cases. If the payment provider is a trusted contract in the model, identify that assumption and the evidence behind it.
Request artifacts you can inspect and rerun
A useful package includes requirement and source versions, assumptions, harnesses, solver and test outcomes, counterexamples, known issues and remaining gaps. A model witness needs an actual execution before becoming evidence about code. A code lemma needs its supported translation scope and preconditions recorded. Ask for explicit treatment of undecided analyses and tool limitations.
Choose methods after understanding the failure
State-machine analysis can expose an invalid sequence. A source lemma can address a local invariant in supported code. Property-based and differential tests can exercise behavior abstracted by the model. No single method automatically closes all those claims. Proof's requirements and evidence links should retain why each method supports the claim so a later change can trigger the relevant review.
Define the release decision separately
An engagement may establish a bounded property, identify a reproducible defect, or leave a question undecided. Do not relabel these to create a clean summary. Name who accepts residual risk and how required CI results will be enforced. A one-time report remains tied to its revision. Continued assurance needs renewed evidence when requirements, code or environment change.
Bring one consequential behavior
Discuss a scoped review with the requirement, implementation path, known failures and decision you need to make.