A4.5 · The spec layer
Invariants that must always hold
An invariant holds for every value, always. An acceptance check holds for one scenario. Naming the two apart is how a spec states the rules a slice must never break, separately from the examples that prove it behaves.
An invariant is universally quantified — true for all values, at all times, named once and exercised by checks. An acceptance check is one named scenario — a single Given/When/Then that proves one example. The Portal's master invariant is the canonical example. Three dives: invariant vs check, the master invariant, and why “always” needs more than a finite set of passing checks.
An invariant, or a check
A spec carries two kinds of claim about a slice. An invariant is a rule that holds for every value the increment can take — it is named once, in the spec's Invariants section, and quantifies over all inputs. An acceptance check is one scenario — a single Given/When/Then on a story that proves one example behaves. The first says for all; the second says for this case.
Select a statement below to classify it. The master invariant and “the error set is closed” are invariants — universal rules. A single Given/When/Then is a check — one scenario. The readout names the kind and why.
Classify the statement · invariant or check
An invariant is a universal rule; a check is one scenario — the spec names them apart, and a rung is done only when every invariant holds and every check passes.
The three dives
Each dive takes one move, in the arc tell apart → read the canonical one → hold it for all: distinguish an invariant from a check, read the Portal's master invariant as the canonical example, and see why “always” needs more than a finite set of passing checks. Read them in order — A4.5.1 starts.
Invariant vs check
Two true statements, two kinds of claim: a universal rule that holds for all values against a single scenario. Which one names a rule the slice must never break, and where each lives.
The master invariant
The Portal's web chapter rests on one universal rule. Read it verbatim as the canonical invariant, and see how a static-search check samples it without replacing it.
Always true
An invariant says “for all”; a finite set of passing checks samples it but never closes it. Why “always” is held over a stream of values, not asserted from one green scenario.
After A4.5, the next module — A4.6 · Traceability — correct by definition — walks the chain from deliverable to story to check and invariant, and closes “done” by a rule. Return to the A4 chapter navigation to continue.
References
The sources behind the invariant-as-universal-rule and where it connects in the course.
Sources
- Adzic, G. — Specification by Example — the example that doubles as a check, distinct from the rule it samples.
- Humble & Farley — Continuous Delivery — invariants held continuously over every change, not asserted once.
- Gherkin reference — Given/When/Then as the structured form a one-scenario check takes.
Related in this course
- A4.5.1 · Invariant vs check
- A4.5.2 · The master invariant
- A4.5.3 · Always true
- A4 · The spec layer — the chapter.
- A1.05 · Correct by definition — the closure invariants feed into.
- A1.04 · Two layers: roadmap and specs — the spec layer invariants live in.
- Companion · Phoenix (F6) — where the master invariant is implemented.