Practical guide
Ask the right question with formal methods
Formal methods make a claim precise enough for mathematical analysis. Their value depends on the question, the model and its connection to the system.
Different questions need different evidence
| Question | What the result concerns |
|---|---|
| Satisfiability | At least one assignment or behavior meets the constraints |
| Realizability | A component strategy can meet guarantees for admissible inputs |
| Model checking | The analyzed transition model satisfies a selected property |
| Code proof | A translated implementation meets a claim under stated assumptions |
A Z3 satisfiability query asks whether constraints have a model. Kind2 contract analysis explicitly distinguishes satisfiable and realizable contracts. Related solver technology does not make these claims interchangeable.
Illustrative example: a request that cannot be served
Guarantee 1: request implies reply
Guarantee 2: reply is always false
Satisfying case: request=false, reply=false
Conflicting case: request=true
The guarantees have a satisfying behavior when no request arrives. If the environment may issue a request, no reply choice can satisfy both at that step. Repairing that conflict can make the contract realizable while the actual implementation still drops requests. The implementation connection needs separate evidence.
Choose a consequential boundary
Authorization decisions, arithmetic bounds and resource-state transitions are useful starting points. Define the intended outcome, input ownership and environmental assumptions. Retain invalid inputs whose handling matters. Decide what a counterexample would look like. A model omitting outages, overflow or concurrent callers cannot answer claims about those behaviors.
Keep the analysis paths distinct in Proof
proof realize specs/system gateway
proof verify-properties specs/system gateway
proof verify-lemma ./internal/gateway
These commands address component realizability, authored variable properties and source lemmas for an illustrative component. Select the path that answers the actual question. Requirements and trace links retain the intended claim; verdicts, assumptions, tests and exclusions explain its support. Generated fixtures can help design tests, but their existence is not an execution result.
Report what remains undecided
Name the model revision, domain, solver outcome and source boundary. Unknown and timeout mean the analysis did not decide. A proved property may still be weak or vacuous. Review omitted behavior and the source connection before using a result to justify release. A command becomes a merge gate only when its exit status feeds the required CI check and repository policy enforces it.
Follow the evidence
Choose one consequential behavior and bring its requirement, code and current tests.