Why reliability is its own layer

A5 — the agent brief turns an A4 spec into running code and produces a built increment: code that exists and passes its own acceptance. That is a genuine milestone, and it is not production. A demo passes the inputs the author chose; production sends the inputs the author did not. The reason A6 is a layer of its own — not a footnote to the build — is that the work it does is invisible to the demo that signed A5 off.

Reliability is not more features; it is the same increment made to hold under conditions the happy path never exercised. A boundary that rejects a malformed value, a supervisor that isolates a crash, a property that proves an invariant across generated inputs — none of these change what the increment does on the valid case. They change what it does on every other case. That is why the work earns its own layer: it targets the inputs the build was never tested against.

Three failures separate a build that passes its demo from one that survives production. The first is an unhandled malformed input: the demo sent a well-formed value, a real caller sends a garbled one, and without a boundary that parses or rejects, the malformed value travels inward and corrupts state far from where it entered. The second is a crashed process that propagates: one operation raises, and without supervision the failure takes neighbours down with it. The third is an invariant held by luck: the test asserted a property on three chosen examples, and a fourth input no one imagined breaks it. Select a failure below to read its consequence-if-unhandled and the pillar that prevents it.

The Portal grounds all three failures in one place. Its identifiers are branded values minted by Portal.ID.generate/1 and read back by Portal.ID.decode/1, which returns a typed value carrying its .type and .timestamp — or rejects the string. That decode is the boundary: a malformed id never reaches the core, because the core trusts only a decoded value. A crashed process is isolated by a supervisor, so one failed operation does not take its neighbours down. And the round-trip invariant — a generated id decodes back to itself — is proven across generated inputs, not asserted on a chosen few. The supervision tree and the OTP mechanics belong to the companion Elixir course; this chapter cites them and does not re-teach them.

Reliability is its own layer because the work it does is invisible to the demo that signs the build off. A5 produces a built increment correct on the happy path; three failures — a malformed input, a crashed process, an invariant held by luck — separate that from an increment that survives production, and a happy-path demo exercises none of them. A6 exists to name and close exactly that gap. The next dive lists the four pillars that close it: OTP supervision, boundaries, parse-don't-validate, and property tests.

Primary sources for parsing at the boundary, a closed error discipline, and proving an invariant rather than asserting it — and where the built increment whose gap this dive names is produced in the course.