A6 · orientation dive 2
What the chapter covers
Four pillars, named at the course roadmap's altitude: OTP supervision, boundaries, parse-don't-validate, and property tests — each closing one failure A5 leaves unproven.
A5 leaves a built increment correct on the happy path but not proven under failure. A6 covers the four techniques that close that gap, each turning one happy-path weakness into a production guarantee. The module-by-module breakdown is deferred — A6's triad is not yet seeded — so this dive names the scope, not invented detail. Pick a pillar on the right to read the failure it addresses and where its OTP mechanics are taught.
The four scope pillars · pick one
The four pillars
A6's scope is four pillars, each named at the course roadmap's altitude and each closing one failure a happy-path demo is blind to. They are not features; they are the same increment made to hold under conditions the build never exercised.
- OTP supervision
- A crash is isolated and recovered, not propagated. What it adds: a failing process is restarted clean instead of taking neighbours down.
- boundaries
- Untrusted input meets a single edge before it reaches the core. What it adds: the core trusts only values that crossed the boundary.
- parse-don't-validate
- The boundary turns an untrusted string into a typed value or rejects it there. What it adds: the typed value carries its own guarantee inward, with no downstream re-check.
- property tests
- An invariant is proven across generated inputs, not asserted on a chosen few. What it adds: a property holds over thousands of generated inputs, not three examples.
Each pillar's OTP mechanics — the supervision tree, the process model — are taught by the companion Elixir course. This chapter cites them and does not re-teach them.
Coverage is all four
Each pillar closes exactly one failure case, and the four cases are independent: a boundary that parse-don't-validates closes a malformed input, a supervisor closes a propagating crash, and a property test closes an unproven invariant. Coverage is not partial credit — an increment is production-grade only when every failure case it can hit is closed. Toggle the pillars below and the matrix reports how many of the four cases are covered; with no pillar, none are.
The coverage matrix · toggle the pillars
A6's scope is four pillars, each closing one case; coverage is production-grade only when every case is closed, not some.
The pillars on the Portal
The Portal lands all four pillars in one place. Its boundary parses an untrusted string into a typed value
with Portal.ID.decode/1 — which returns a value carrying its
.type and .timestamp, or rejects the input — so a
malformed id never reaches the core. A supervisor isolates a crashed process. And a property test proves the
round-trip invariant: a generated id from Portal.ID.generate/1 decodes back to
itself across generated inputs, not three chosen ones. The supervision tree and the OTP process model are the
companion Elixir course's — cited here, not re-taught.
The principle
Production-readiness is four named techniques — supervision, boundaries, parse-don't-validate, property tests — each closing a specific happy-path weakness, and complete only together.
On the Portal
Portal.ID.decode/1 parses input into a typed value, a supervisor isolates a
crash, and a property proves a generated id round-trips — the four pillars landed on one running
system.
A6's scope is four pillars; the module set that teaches them is detailed once the triad is seeded.
Recap — the scope, deferred where the triad is not
A6 covers four pillars: OTP supervision, boundaries, parse-don't-validate, and property tests. Each closes one failure a happy-path demo is blind to, and an increment is production-grade only when every case it can hit is closed. This dive names the scope at roadmap altitude; the module-by-module breakdown waits on the chapter's triad. The next dive turns the scope into method — how you harden a built increment against the four pillars here.
A6's module-by-module breakdown is deferred until its triad (a6.md,
a6.stories.md, a6.llms.md) is seeded — the same
spec-first pattern A4 and A5 used. This dive names the chapter's scope, the four pillars, not an invented module
list.
References
Primary sources for the four pillars — parsing at the boundary, a closed error discipline, property-based proof, and safe incremental release — and where this chapter's scope is sequenced in the course.
Sources
- King, A. — Parse, don’t validate — the boundary pillar: turn an untrusted string into a typed value or reject it there.
- Wlaschin, S. — Railway-oriented programming — a closed error discipline that the boundary and supervision pillars compose into.
- Elixir — StreamData — the property-test pillar: prove an invariant across generated inputs.
- Humble, J. & Farley, D. — Continuous Delivery — keeping each hardened increment releasable.
Related in this course
- A6 · Reliability and correctness — the chapter landing.
- A6 · Why reliability is its own layer — the failures these pillars close.
- A6 · How you build it here — the four pillars turned into method.
- A4 · The spec layer — the spec that defines done.
- Companion · Phoenix (F6) — the real Portal web build.
- Companion · Functional Programming in Elixir — the Portal’s OTP foundations (cited, not re-taught).