Engineering guide
Make requirement assumptions reviewable
An assumption states what the system relies on from its environment. If it is false, even a correctly verified model can describe the wrong operating situation.
Put the boundary in the right place
A queue consumer might assume messages arrive in order. A database client might assume committed writes survive process restart. A controller might assume a sensor stays within a specified error bound. Each is a claim about something outside the modeled responsibility, and each needs an owner or evidence basis.
Illustrative failure. The consumer's model assumes no duplicate messages, while the deployed queue permits redelivery after a timeout. A green model result under the assumption cannot establish correct behavior for the real deployment.
Do not recast an implementation defect as an environmental assumption simply to keep the guarantee satisfiable.
Record what would justify relying on it
| Record | Purpose |
|---|---|
| Condition and scope | State exactly when and where the assumption must hold. |
| External owner | Identify who can confirm or change the environmental guarantee. |
| Evidence or contract | Show the basis for relying on the condition. |
| Review date and invalidators | Identify when confidence must be reconsidered. |
An owner's name is not evidence that the owner accepted responsibility. A review date is not a substitute for examining the boundary.
Inspect and disposition the current assumptions
proof req assumptions list
proof req assumptions status SYS-REQ-042
proof audit --check assumptions_status --verboseThe assumption check is advisory by default: ordinary open assumptions remain visible without automatically becoming warnings. Its clean output must not be read as proof that all assumptions have been discharged.
The review command can record states such as open, discharged, known_issue, accepted_risk, or invalid. Choose the state that matches the evidence, and supply the required references. Discharged means there is a basis for the condition; invalid means the reasoning that relied on it must be reassessed.
Propagate an invalid assumption
If queue behavior invalidates the no-duplicates assumption, inspect every guarantee and test that relied on it. The repair may require idempotency, a different queue contract, or an authorized narrowing of the supported deployment. Record the decision and rerun affected analysis and implementation checks.
Preserve the old assumption and why it changed. That history helps a future deployment or agent avoid reintroducing the same unsupported premise. Evidence about one environment does not automatically transfer to another.
Continue from here
Investigate model conflicts. Specify external boundary contracts.
Bring one assumption whose truth depends on another component or deployment environment. Bring a change to Proof.