Requirement file
- id SYS-REQ-014
- component autopilot
- assume sensor_valid
Topic · Design by contract
Gist
Design by contract is an assume/guarantee pair at a component boundary: the callee names what it needs, the caller names what it provides. Proof runs that as a check on the YAML. proof check integration specs/system names every assumption that no other component guarantees. Jama still authors. Proof is not Eiffel, and a match is not a Kind2 proof.
proof check integration specs/system
Keep Eiffel if you need assertions in source. Keep AGREE if you need a solver on the contracts. Proof does not certify the composition.
01 · The assume nobody promised
sensor_valid is not a contract until someone guarantees it.You can write "autopilot assumes sensor_valid" under SYS-REQ-014 and still have no guarantee in the sensors file a merge gate can hold.
Design by contract is Meyer's name for the same split: a precondition the environment must meet, a postcondition the component must meet. Wikipedia files it under contract programming. Eiffel puts require/ensure on the routine. AGREE and CoCoSpec put assume/guarantee on a Lustre node. This page is the check: each assumption in one component, a guarantee in another, matched on shared variable names.
The one-function lemma H1 lives on Z3 / Kind2 on one function. The temporal-formula H1 lives on linear temporal logic. Integration checking does not discharge a lemma. It does not simulate a trace. It walks the graph and reports unmatched assumptions as integration gaps.
proof check integration specs/system
proof check integration specs/system --format json
proof help check
On this install the teaching graph is four components. Autopilot assumes sensor_valid. Until the check runs, CI cannot fail when sensors never wrote that guarantee.
02 · The exhibit
SYS-REQ-014 already assumes sensor_valid. The check names the variable that has no guarantee. Click the tabs.
Requirement file
This push
No guarantee from sensors. No named gap. The assume never entered CI.
Silent assumeRequirement file
Still last week's shall. Still one assume. Still no named finding until the check runs.
Keep the SYS-REQProof
Same requirement files. A silent assume, or a named gap. Click the tabs.
| component | assume | guarantee from | result |
|---|---|---|---|
| autopilot | sensor_valid |
sensors | unmatched |
| navigation | gps_signal |
gps | unmatched |
| Surface | What they do | What Proof does | What we lose |
|---|---|---|---|
| Design by contract | Wikipedia / Meyer: precondition, postcondition, invariant on a routine. | proof check integration matches assume to guarantee by shared variable names. No solver. |
A match is not a proof the guarantee implies the assume. |
| Eiffel require / ensure | Assertions in source. The compiler or the runtime checks the routine. | Not this command. Proof does not inject require/ensure into Go, C, or Eiffel. | No source-level contract language. |
| AGREE / CoCoSpec | Assume/guarantee on a Lustre node. The solver checks the composition. | Kind2 compositional checking is not this command. Matching here is heuristic (Level 2). | No compositional Kind2 run on this check. |
| Z3 / Kind2 | A lemma on one function, or realizability of one component. | That H1 lives on Z3 / Kind2 on one function. A contract match is not a lemma. | This command does not discharge a lemma. |
| Linear temporal logic | One formula, one finite trace. | That H1 lives on linear temporal logic. Integration checking does not simulate a trace. | This command does not walk a trace. |
| Jama / DOORS | Author and store the programme, including free prose about interfaces. | Jama still authors. Proof holds the assume as a file the check can re-read. IBM DOORS stays a mention on Proof vs Jama. | Not an ALM. Jama still authors. |
The teaching requirement is SYS-REQ-014. Autopilot still assumes sensor_valid. Sensors still have no guarantee that names that variable. That is the gap.
id: SYS-REQ-014
component: autopilot
assume: sensor_valid
proof check integration specs/system
Cross-Component Integration Check: specs/system
Components: 4
Assumptions checked: 20
Matched: 1
Unmatched: 19
Unmatched assumptions:
autopilot: sensor_valid (no guarantee from sensors component)
proof check integration specs/system --format json
The JSON includes a dependency_graph field: which component depends on which, read from the shalls, not from a slide. A match is a shared variable name and a constraint expression. It is not a proof that the guarantee implies the assumption. Early graphs report most assumptions unmatched. That is expected. The check is how you close the list instead of hoping a reviewer remembers the boundary.
03 · The honest loss
Proof names an unmatched assume in the YAML. It does not prove the composition. Jama still authors.
Matching is heuristic. The checker looks for a guarantee that names the same variables as the assumption. It does not run Kind2 with compositional contracts. It does not run AGREE. It does not check that the guarantee is strong enough. A match can be the wrong polarity, the wrong bound, or a different unit. Reviewers judge. Proof does not inject Eiffel require/ensure. Proof does not rewrite Go asserts. We have not run this against a frozen Eiffel, AGREE, or CoCoSpec corpus. The loss is named, not scored.
The one-function lemma H1 stays on Z3 / Kind2 on one function. The temporal-formula H1 stays on linear temporal logic. Jama still authors.
04 · Nearby questions
What is contract based design? Same cluster, smaller Ads string. Same URL. Do not mint a twin.
What is assume-guarantee? The NASA / FRET name for the same split. Same URL.
What is precondition / postcondition? Meyer's routine-level pair. Same URL. Proof does not put those on a Go function.
What is compositional verification? Solver-backed composition. Not this command. Kind2 compositional checking is not shipped here.
What is linear temporal logic? One formula, one finite trace. LTL.
Is Proof Eiffel? No. Jama still authors. Proof matches assume to guarantee so CI can fail when a boundary has no provider.