Reliability and correctness

A5 leaves a built increment that passes its own demo. A6 makes it production-grade — it survives a malformed input, a crashed process, and an invariant proven across generated inputs rather than asserted on a chosen few.

“It builds and the demo passes” is not yet “it survives production.” A happy-path increment can still crash on a malformed input, leak a crashed process, or hold an invariant only by luck. This chapter closes that gap with the techniques that turn a built increment into a production-grade one: OTP supervision, boundaries that parse-don't-validate, and property tests — named here at the course roadmap's altitude and practised on the Portal.

Where we are The gap A5 leaves What this chapter covers Orientation dives The chapter modules References

Where we are

The course is one argument carried across eight parts. The first six are built: A0 framed the method, A1 made the case for thin, provable slices, A2 turned a vision into a backlog, A3 planned its delivery, A4 defined and proved each rung, and A5 briefed a Claude Author and turned a spec into running code. A6 is where that running code becomes production-grade. A7, the Portal exemplar, runs the whole loop on top of it.

The arc below walks the eight parts. Select one and the readout reports its title, what it delivers, and whether it is built — the same orientation this landing exists to give. The default selection is A6, the part you are reading.

The course arc — eight parts, A0 to A7

A6 · Reliability and correctness — /reliability. Delivers: an increment built to production quality — supervision, boundaries that parse-don't-validate, and properties proven across generated inputs. Status: you are here. · 6 of 8 parts built before this one; A5 leaves a built increment correct on the happy path but not proven under failure — that gap is what this chapter closes.

A0–A5 built the apparatus and turned a spec into running code; A6 makes that code survive production. A passing demo is not a production guarantee.

The gap A5 leaves

A5 — the agent brief wraps an A4 spec in a machine-readable brief and runs a Claude Author to turn it into code. A5 produces a built increment: code that exists and passes its own acceptance. That is real, and it is not enough. A demo passes the inputs the author chose; production sends the inputs the author did not. Three failures separate “it builds” from “it survives”, and a happy-path demo is blind to all three.

An unhandled malformed input travels inward and corrupts state far from where it entered. A crashed process propagates and takes neighbours down with it. An invariant held by luck — asserted on three chosen examples — breaks on a fourth input no one imagined. A6 exists to close exactly this gap: it names what production-readiness A5 leaves unproven, and proves it.

The principle

A built increment that passes its demo is not yet production-grade. Production-readiness — supervision, boundaries, proven invariants — is separate work from the build, and it is the work A6 names.

On the Portal

The Portal's boundary parses untrusted input into a typed value — Portal.ID.decode/1 returns a struct or rejects the string — a supervisor isolates a crashed process, and a property test proves an id round-trips across generated inputs.

A5 says “it builds and the demo passes.” A6 says “it survives a malformed input, a crashed process, and an unproven invariant.”

What this chapter covers

A6's scope, named at the course roadmap's altitude, is four pillars: OTP supervision (a crash is isolated and recovered, not propagated), boundaries (untrusted input meets a single edge before the core), parse-don't-validate (that edge turns a string into a typed value or rejects it there), and property tests (an invariant proven across generated inputs, not asserted on a chosen few). The figure below is a survival meter: a happy-path build covers none of the four failure cases; each pillar toggled on closes exactly one.

The four-pillar survival meter · toggle a pillar

No pillar enabled — 0 of 4 failure cases survive. A demo passing the happy path covers a single valid input; production sends the rest. Toggle a pillar to close its case.

A6's modules will be enumerated when its triad (a6.md, a6.stories.md, a6.llms.md) is seeded. The chapter's scope, per the course roadmap, is OTP supervision, boundaries that parse-don't-validate, and property tests — the techniques that turn a built increment into a production-grade one. This landing names that scope; the module-by-module breakdown follows the triad.

Orientation dives

Three short dives orient you before the chapter's teaching modules. Read them in order: why reliability is its own layer and the failures it prevents, what the chapter covers, and how you harden a built increment here.

A6 · divebuilt

Why reliability is its own layer

The gap A5 leaves, and the three failures a happy-path demo is blind to: a malformed input, a propagating crash, an invariant held by luck.

A6 · divebuilt

What the chapter covers

The four scope pillars at roadmap altitude — supervision, boundaries, parse-don't-validate, property tests — each closing one failure case.

A6 · divebuilt

How you build it here

Harden the built increment: parse every boundary value, supervise every process, and accept only when an invariant is proven, not asserted.

The chapter modules

A6 is the course's first chapter not yet specified. The earlier chapters were built from a seeded triad — a chapter spec, its user stories, and its agent brief — before their modules were authored. A6 has no triad yet, so its module set is not enumerated here. Naming modules before they are specified would invent work the course has not decided; the honest move is to name the scope at the roadmap's altitude and defer the breakdown.

A6's modules will be detailed once its triad (a6.md, a6.stories.md, a6.llms.md) is seeded — the same spec-first pattern A4 and A5 used. The chapter's scope, per the course roadmap, is fixed: OTP supervision, boundaries that parse-don't-validate, and property tests. Start with the orientation dive Why reliability is its own layer, which names the failures the chapter prevents.

References

The sources this chapter draws on for parsing at the boundary, a closed error discipline, property-based proof, and safe incremental release — and where the built increment it hardens is produced in the course.

Sources

King, A. — Parse, don’t validate — turn untrusted input into a typed value at the boundary, so the core trusts only what crossed it.
Wlaschin, S. — Railway-oriented programming — a closed error discipline: every operation returns a value or a typed failure, never a surprise.
Elixir — StreamData — property-based testing: prove an invariant across generated inputs rather than asserting it on a chosen few.
Humble, J. & Farley, D. — Continuous Delivery — keeping each increment releasable, which a production-grade increment must be.

Related in this course

A5 · The agent brief — the built increment A6 hardens.
A4 · The spec layer — the spec that defines done.
A1.05 · Correct by definition — done as a closure over proven, not asserted, checks.
A1.03 · The Author/Operator loop — the loop that accepts a rung against its proof.
A6 · Why reliability is its own layer — the failure-it-prevents dive.
Companion · Phoenix (F6) — the real Portal web build.
Companion · Functional Programming in Elixir — the Portal’s Elixir and OTP foundations (cited, not re-taught).