A3.4 · Thin but robust · dive 3
Always live
Every rung leaves the node booting clean and serving —
GET /health answers 200 and the route renders. The mainline
is never broken.
This is the strictest of the seven properties and the liveness criterion of the whole ladder. A rung that lands red is not done; it is a regression. Step through the nine F6 rungs on the right and watch each one leave the system green — the ledger is all-green by construction.
The rung ledger · step through the nine
A rung is done only when it leaves the system live
Of the seven properties, “always live” is the strictest, because it is the one that makes a ladder
of thin slices safe to climb. The criterion, verbatim from the F6 roadmap, is exact: every rung leaves the dev
node booting clean and serving — GET /health answers
200 and the rung's route renders.
A rung that meets all three is green: it boots, it is healthy, its route renders, its harness passes — done. A rung that fails any of them is red: it is not done, and the mainline is broken until it is green again. A red rung is reverted or fixed before the next begins, so the ledger of landed rungs is all-green at every step. That all-green ledger is exactly what lets the roadmap re-order the rungs freely — each one stands on a green rung below it, and re-ordering edits the roadmap, never a spec.
- boots clean
- The node starts with no crash and no unsupervised child failing.
- /health → 200
- The liveness endpoint answers
200— the node is up and serving. - route renders
- The rung's own route returns its page; the new capability is reachable.
- harness green
- The rung's fast test passes, so the slice is proven, not merely present.
Always live is what separates a ladder from a pile of half-finished branches. Because each rung leaves the mainline green, the next rung — or a re-ordering of the rungs — always builds on a working system.
Break a rung, watch the check catch it
The liveness criterion is only useful because it fails loudly. Break a rung in any of the ways below and the liveness check reports it red — the rung is a regression, caught before it can be built on. The two figures teach different moves: the hero steps the ledger green-by-green to show the criterion holding; this one breaks a rung to show the criterion catching a failure.
Break a rung · pick a failure
A red rung is not a rung — the liveness check turns a broken mainline into a caught regression.
Always live, on the Portal
On the Portal, F6's nine rungs f6.1 through f6.9 each leave
the node live. f6.1 boots and serves the root; f6.3 adds
persistence and still boots and serves; f6.6 adds live updates and still answers
GET /health with 200. The new pieces a rung introduces —
an endpoint, PubSub, Presence — are supervised children, so adding a rung adds a route and a supervised
process, never a reason for the node not to boot.
That is the payoff of the master invariant for liveness: because every surface calls only the facade and renders only the closed error set, a new rung cannot reach into the engine and destabilise it. The engine's crash isolation is untouched, the node keeps booting, and the ledger stays all-green — which is exactly what makes the roadmap free to re-order its rungs.
# The liveness criterion — a rung is done only when all three hold. # GET /health → 200 AND the rung's route renders AND the node boots clean rung = "f6.6 — interactivity (live search, live create)" boots_clean = true health = 200 # the liveness endpoint answers route_renders = true # /catalog returns its page live? = boots_clean and health == 200 and route_renders # A red rung (any of the three false) is a regression — reverted before the next begins.
Always live is the bar a rung clears to count as done — boots clean,
/health answers 200, the route renders — so the
mainline is never broken and the ladder is safe to climb.
Every F6 rung holds it under the master invariant — the web layer calls only the
Portal facade and renders only the closed %Portal.Error{}
set — so a new rung adds a supervised child and a route, never a reason for the node not to boot.
A rung is done only when it leaves the system live; a red rung is not a rung, it is a regression.
Recap — the mainline stays green
Always live is the strictest of the seven properties and the liveness criterion of the whole ladder: every
rung leaves the node booting clean, GET /health answering 200,
and its route rendering. A green rung is done; a red rung is a regression, reverted before the next begins. The
all-green ledger is what makes the roadmap free to re-order rungs without editing a spec. With this, A3.4 is
complete: thin is a vertical slice, robust is the seven properties, and the strictest of them keeps the
mainline live.
Next in A3: A3.5 · Milestones and iterations — grouping robust rungs into shippable milestones, each run through one iteration. Return to the A3.4 hub to revisit the module.
References
The sources behind the always-live discipline, and where it connects in the course.
Sources
- Humble & Farley — Continuous Delivery — keep the mainline releasable at every commit; a red build stops the line.
- Hunt & Thomas — The Pragmatic Programmer — a working skeleton kept alive and grown, never a broken half-build.
- Beck, K. — Extreme Programming Explained — continuous integration: the system always builds and runs.
Related in this course
- A3.4 · Thin but robust — the module hub.
- A3.4.2 · What robust adds — the previous dive (always live is property seven).
- A3.3 · Anatomy of a roadmap.md — the rung line each live rung fulfils.
- A1.05 · Correct by definition — the harness that keeps a rung green.
- A1.02 · Contracts — the contract that keeps a rung from destabilising the engine.
- F6 · The Portal on the web (Phoenix) — where the framework holds the liveness criterion on every rung.