Engineering guide
Connect requirements to executable checks
An executable requirement has a precise relationship to a check that can run. The valuable part is the preserved meaning from the approved promise through the model or test to the observed result.
Separate the promise from the mechanism
Suppose the system must reject a transfer when funds are insufficient and leave both balances unchanged. That is the promise. A state model, an example-based test, and a property over account balances are different mechanisms for examining it.
Illustrative chain. Approved intent → system requirement → software responsibility → implementing transfer function → tests or model checks → result bound to the examined versions.
Do not let the current implementation define expected output merely because it is easy to execute. Recover candidate intent from authoritative sources and resolve conflicting interpretations before treating a check as an acceptance oracle.
Make the domain and assumptions explicit
A model needs declared variables and constraints. For the transfer example, specify whether amounts can be negative, how currencies and rounding are represented, and whether concurrent updates are in scope. An elegant boolean formula can omit the numeric boundary that caused the actual defect.
proof validate --preflight specs/system transferPreflight requires both a configured spec path and component. It detects modeling setup problems before solver invocation. It does not decide whether the business rule is the right one.
Choose complementary observations
| Evidence | What it can establish |
|---|---|
| Example test | The assertions held for the executed input and implementation. |
| Property test | The property held for the generated cases in that run. |
| Model analysis | A result about the encoded model under its assumptions and analysis scope. |
| Integration test | An observation across the exercised real boundary and environment. |
A model counterexample may reveal an inconsistent promise, an incorrect abstraction, or a possible implementation failure. Reproduce and investigate before calling it a code defect. A repaired example does not by itself close every member of a failure class.
Retain the chain when things change
Trace the check to the requirement it examines and retain run provenance. A requirement edit can invalidate the oracle; a code edit can invalidate the result; an environment change can invalidate an assumption. Regenerate and rerun the affected evidence rather than presenting an old green report as current assurance.
proof review req SYS-REQ-042 --gate --runThis runs a requirement-focused review loop. Its scope is narrower than final project acceptance, and its verdict must be interpreted alongside missing or unsupported evidence.
Continue from here
Build tests from expected behavior. Manage the assumptions behind checks.
Bring one requirement that should become executable and the implementation it governs. Bring a change to Proof.