The gates

A closure is only as trustworthy as the thing that re-runs it. A quality gate removes the person from the verdict: it runs the checks mechanically and returns pass or fail, the same way every time.

That is what turns “A+” from praise into a repeatable result — the state of a page or a rung when every gate passes. Toggle the ten gates on the right; STATUS: PASS lights only when all ten pass. One failing gate fails the suite.

What a gate is Opinion vs gate Two real suites References

The gate panel · the course's ten cms gates

10/10 gates pass · STATUS: PASS — A+ (repeatable: re-run for the same verdict).

A gate removes the person from the verdict

The closure (A1.05.1) names what must be green; the proofs (A1.05.2) make each check a real execution. One risk remains: if “every check passed” depends on a person remembering to run every check, then done is back to being an opinion — held more carefully, but still an opinion. A quality gate removes the person from the verdict. It runs the checks mechanically and returns pass or fail, the same way every time, on demand.

A suite of gates passes only when every gate passes; one failing gate fails the whole suite. That is the closure rule applied one level up — and it is what makes “A+” repeatable. “A+” is not a grade somebody awards; it is the state of a page or a rung when every gate passes. Run the gate again tomorrow and the verdict is the same, because the gate, not the mood of a reviewer, decides.

quality gate: A mechanical check over an artifact that runs without human judgement and returns pass/fail.
suite: A set of gates that passes only when every gate passes; one failing gate fails the whole suite.
repeatable A+: The same inputs through the same gates yield the same verdict every time. The grade is a check's output, not a grader's opinion.
boundary: A gate checks what is mechanically testable. Taste, scope, and judgement stay with the Operator — the gate proves a route resolves, never that it is the right route.

The gate does not replace judgement; it discharges the mechanical part of it so attention is free for the part that is not mechanical. Reliability beyond the gate is the subject of A6.

An opinion swings; a gate repeats

The property that matters is repeatability. An opinion verdict moves with the reviewer: the same work scores differently on a generous morning and a harsh afternoon. A gate verdict does not move: the same artifact through the same gates returns the same result on every run. That is the whole reason a gate is worth building — not that it is stricter, but that it is constant.

Move the reviewer-mood slider and re-run the gate over one fixed artifact whose true result is 10/10 pass. The opinion grade swings across the full range as the mood changes; the gate grade stays A+ on every run. The opinion is a function of the mood; the gate is a function of the artifact.

Reviewer mood versus the gate · same artifact, 10/10

reviewer mood even

opinion: B+ (mood-dependent) · gate: A+ (10/10, constant) — only the gate repeats.

A gate is worth building because it is constant: the opinion grade is a function of the mood, the gate grade a function of the artifact, and only the second repeats.

Two real gate suites

This is practised, not hypothetical, in two places the course already uses. The course itself runs the cms ten gates over every page — containers, svg, no-future, voice, storage, motion, degrade, links, pager, refs. A page ships only at STATUS: PASS, all ten green; “A+” is exactly “ten gates pass.” This page cleared that suite before it shipped.

The Portal runs its acceptance harness over each rung. The “enrol” closure — including “enrol twice → no duplicate” — is re-run mechanically; the rung is accepted when the harness is green, not when someone says so. Both make the same move: done is a set of checks (A1.05.1), the checks are executed not asserted (A1.05.2), and a gate re-runs them so the verdict repeats. The Portal's OTP internals are taught by the companion Functional Programming course; this course cites them rather than re-teaching them.

# The course's gate over every page — ten checks, pass only when all pass.
$ cms check --require-refs why/correct/gates.html
  [PASS] containers · svg · no-future · voice · storage
  [PASS] motion · degrade · links · pager · refs
  STATUS: PASS   # A+ = 10/10. Re-run → the same verdict.

# The Portal's harness over the "enrol" rung — the closure, re-run mechanically.
assert enrol(learner, course) == :ok           # C2
assert count_enrolments(learner, course) == 1   # C3 — green; accepted, not asserted

the principle

A mechanical gate re-runs the closure's checks without judgement and returns pass/fail, so the suite passes only when every check is green and “A+” is a repeatable output, not an opinion.

on the Portal

The acceptance harness re-runs each rung's closure — “enrol twice → no duplicate” included — and accepts only when green; the course runs the cms ten gates over every page.

Gates hold the closure: they re-run every check mechanically, so “A+” is the repeatable output of a passing suite rather than an opinion laid on top.

Recap — correct by definition, held by a gate

A quality gate runs the closure's checks without human judgement and returns pass/fail; a suite passes only when every gate does. That makes “A+” the constant output of a passing suite rather than a reviewer's opinion — the course runs the cms ten gates over every page, the Portal runs its acceptance harness over every rung. With this, A1.05 closes: done is a closed set (A1.05.1), made of proven not asserted checks (A1.05.2), held by a mechanical gate. The whole of chapter A1 — why an agile agent workflow — is now in hand.

Forward: the spec the checks derive from is built out in A4 (the spec layer), and reliability beyond the gate is A6. Back: this gate is how the provable completion of a thin slice (A1.01) and the four artifacts (A0.2.2) are enforced. Return to the A1.05 hub to review the module.

References

Primary sources for mechanical, automated verification, and where it connects in the course.

Sources

Humble & Farley — Continuous Delivery — the deployment pipeline as a chain of automated gates a candidate must clear, stage by stage.
Beck, K. — Extreme Programming Explained — continuous integration and automated acceptance tests as the mechanical verdict.
Adzic, G. — Specification by Example — living documentation: the executable spec is re-run, so it cannot drift from the system.

Related in this course

A1.05 · Correct by definition — the module hub.
A1.05.2 · Proven, not asserted — the previous dive.
A1.01 · The two failure modes — provable completion of a thin slice.
A0.2.2 · The four artifacts — the artifacts a gate checks.
A2.04 · Acceptance criteria with Given/When/Then — the checks a gate re-runs.
A1 · Why an Agile Agent Workflow — the chapter.