Topics / Engineering practice
Software verification starts with a claim you can check.
Verification asks whether software meets specified requirements. Useful evidence identifies the claim, the method, the observed result and the exact version checked.
Choose the method to fit the claim.
A type checker, an integration test and a model checker answer different questions. Start with the behavior that matters, then select a method that could reveal a violation. Keep validation alongside verification: a faithfully implemented requirement can still describe the wrong product.
| Claim | Possible evidence | Remaining question |
|---|---|---|
| A retried payment is charged once | Concurrent and delayed-request scenarios with ledger assertions | Do the chosen failures cover the relevant integration? |
| A decision depends on each condition | Independent-effect test pairs | Are the conditions and expected outcomes correct? |
| A modeled counter never becomes negative | Solver result with assumptions and model revision | Does the running implementation match the model? |
Keep the result attached to its basis.
Record inputs, expected outcomes, actual outcomes, producer, environment and revisions. “Passed” without an identifiable run is too weak to reuse. If a requirement, dependency or build configuration changes, decide which conclusions need to be checked again.
Illustrative example
The test passed on the wrong build.
A release candidate changes a serializer. Yesterday’s integration run used the previous binary. The test may be relevant, but that result does not establish the new serializer’s behavior. Retain the old result as history and run the required scenario on the candidate.
Carry one claim all the way to its result
Illustrative plan: a serializer must preserve an account identifier exactly. Use an identifier with leading zeros, such as 00123. Serialize it, parse the result and assert that the decoded identifier is still the string 00123.
| What needs checking? | Start with | Also inspect |
|---|---|---|
| A concrete failure or compatibility promise | A regression or integration test with an explicit expected result | Legitimate neighboring behavior and the candidate binary |
| A rule across many generated inputs | A property test or fuzzer with a meaningful failure oracle | Input distribution, exclusions and replayable failures |
| An invariant in a defined model | A solver or model checker suited to the property | Assumptions and the connection to the implementation |
| The suite's treatment of a Boolean decision | Measured condition-independence witnesses | Requirements absent from that decision and assertion quality |
For the serializer, retain the input, expected value, actual decoded value, command, candidate revision and output. If the actual value is 123, the type matters: an integer and the string 00123 are different results. No run is claimed for this illustrative plan.
To inspect an executed example, follow the retention-change walkthrough, including the failed check and its declared dependency.
What Proof contributes.
Proof connects requirements, implementation links and verification records in the Software Intent Graph. This makes the basis of a claim inspectable and helps identify missing or stale evidence. It does not make an untested assertion true.
For a first deployment, pick one change and agree on the evidence needed to accept it. Compare the effort spent collecting that evidence with the existing process, including setup and maintenance.
Try it on your software
Choose one claim that deserves stronger evidence.
Bring a consequential change and the checks you already run. We will help connect the result to the promise.