The closure

A chain that walks is not yet a guarantee. The guarantee is the completion rule — four clauses that, together, make “done” a closure rather than a claim.

A rung is done only when every deliverable maps to a story, every story's criteria pass, every requirement is satisfied, and every invariant holds under test — and every gate is run, not asserted. Close the four clauses on the right over F6.1; this is the closure A1.05 calls correct by definition.

The completion rule Run, not asserted On the Portal References

The four clauses · close them over F6.1

(a) every Deliverable maps to at least one User story. On F6.1 the Coverage line covers D1…D7 — no deliverable is absent. The clause holds.

The completion rule

The chain is walkable; the rule is what makes a closed chain a guarantee. A rung is done only when all four clauses hold together: (a) every deliverable maps to at least one user story, (b) every user story's acceptance criteria pass, (c) every requirement is satisfied, and (d) every invariant holds under test. Drop any one and the rung is not done.

This is the operational form of A1.05 — Correct by definition: completion is a closure over traced, executed checks. The phrase “executed” is the load-bearing word — a gate that is written but never run proves nothing, which the next section makes concrete.

# specs.approach.md — the completion rule (verbatim).
A rung is done only when
  (a) every Deliverable maps to at least one User story,
  (b) every User story's acceptance criteria pass,
  (c) every Requirement is satisfied, and
  (d) every Invariant holds under test.

# "Correct by definition" means exactly this closure: there is no behavior in
# the increment that is not pinned by an acceptance check or an invariant, and
# no gate that is merely asserted rather than run.

(a) covered: Every deliverable appears in the stories file's Coverage line, so each maps to at least one story that realizes it.
(b) accepted: Each story's Given/When/Then runs green — the acceptance criteria pass, not merely exist.
(c) satisfied: Every numbered requirement (FN.M-R#, tagged [US: …]) is implemented.
(d) holds: Every invariant is exercised by a check under test — established by construction and pinned, not assumed.

Run, not asserted

The closure is only as good as the gates that prove it. “Correct by definition” names a specific failure to avoid: a gate that is merely asserted — written down, claimed, but never executed against the increment. Such a gate proves nothing. The rule requires every gate to run.

Switch the mode below to contrast the two. When the acceptance check runs against the increment and passes, the behaviour is pinned and the clause holds. When it is only asserted — present in the file but never executed — the behaviour is unproven and the rung is not done, however confident the claim reads.

A gate · run or merely asserted

Run · the acceptance check executes against the increment and passes, so the behavior is pinned. The clause holds — the gate is run, not asserted.

A gate proves something only when it runs: “correct by definition” rules out the gate that is asserted but never executed.

The closure on the Portal

On the Portal, F6.1 closes only when all four clauses hold. (a) Its Coverage line maps D1…D7 to US1…US5 — no deliverable is uncovered. (b) Each story's Given/When/Then runs: US1's “GET /health returns 200 ok”, US2's “a known user id renders that user's courses”. (c) Each requirement F6.1-R# carrying [US: …] is implemented. (d) INV1 through INV5 are each exercised — the master invariant by a static search of apps/portal_web/lib/, INV4 by an injected %Portal.Error{} that renders a 422.

When those gates run and pass, F6.1's Definition of Done is met and the rung is correct by definition. The framework that makes each gate runnable is taught in F6 — the Portal on the web; here the concern is the closure, not the code.

# F6.1 closes only when all four clauses hold — over the real triad.
(a) covered     ok   # Coverage: D1→US1 · … · D7→US4,US5  (every D# present)
(b) accepted    ok   # each Given/When/Then runs green (e.g. US1: /health → 200 "ok")
(c) satisfied   ok   # each F6.1-R# [US: …] implemented
(d) holds       ok   # INV1…INV5 each exercised by a check
                  → "correct by definition"   # the closure A1.05 names

the principle

“Done” is a closure over four clauses — deliverables covered, criteria pass, requirements satisfied, invariants hold — and every gate is run, not asserted.

on the Portal

F6.1 closes only when its Coverage line covers D1…D7, every Given/When/Then passes, every requirement is met, and INV1…INV5 hold under test — the rung's Definition of Done.

The completion rule is the guarantee: a rung is done only when all four clauses close and every gate is run — the exact closure A1.05 calls correct by definition.

Recap — four clauses, every gate run

The completion rule closes “done”: every deliverable mapped to a story, every story's criteria passing, every requirement satisfied, every invariant holding under test — and every gate run, not merely asserted. Drop one clause and the rung is not done; that is what “correct by definition” means. With the closure in hand, the last dive does the inverse: it breaks one link and reads the gap.

Next in A4.6: A4.6.3 · A broken link — remove one link and the rule reports not done and names the exact hole.

References

The sources behind the completion closure and run-not-asserted, and where it connects in the course.

Sources

Humble & Farley — Continuous Delivery — every gate run, not asserted; done means the checks have passed.
Adzic, G. — Specification by Example — examples that are executed as the acceptance, not merely written down.
Cohn, M. — User Stories Applied — the story's acceptance as the test of done.

Related in this course

A4.6 · Traceability — the module hub.
A4.6.1 · The chain — the previous dive.
A4.6.3 · A broken link — the next dive.
A1.05 · Correct by definition — the idea this closure makes operational.
F6 · The Portal on the web (Phoenix) — the real chapter F6.1's gates come from.