A6 · orientation dive 3
How you build it here
Harden the built increment from A5 — do not rebuild it. Parse every boundary value, supervise every process, and accept only when an invariant is proven, not asserted.
Take what passes its demo and make it production-grade. A parsed boundary value is the only thing the core trusts; a supervised process is the only kind that may crash; a proven invariant is the only kind that may be accepted. Acceptance closes against the proof, not the agent's self-report — the same review discipline A1.05 named. Pick a mode on the right to compare what an example asserts against what a property proves.
Assert vs prove · pick a mode
The method
The method is to harden the built increment, not to rebuild it. A5 produced code that passes its demo; A6 takes that code and makes it survive production through four moves, in order. First, parse at the boundary: untrusted input becomes a typed value at the edge or is rejected there, and the core never re-checks because it trusts the type. Second, supervise every process: a crash is isolated by a supervisor and the process restarts clean, so the failure does not propagate. Third, prove, don't assert: acceptance closes only when a property test proves the invariant across generated inputs. Fourth, accept against the proof: the Operator accepts a rung when the property holds, the boundary rejects malformed input, and the supervisor isolates a crash — never on the agent's self-report.
- parse at the boundary
- Untrusted input becomes a typed value at the edge or is rejected there. The core trusts the type and never re-checks.
- supervise every process
- A crash is isolated by a supervisor and the process restarts clean; the failure does not propagate.
- prove, don't assert
- Acceptance closes only when a property test proves the invariant across generated inputs — not three chosen examples.
- accept against the proof
- The Operator accepts the rung against the property, the boundary, and the supervisor — never the agent's self-report.
This is the same acceptance discipline A1.05 — correct by definition named: done is a closure over proven, executed checks, and A6 makes the proof a property, not an example.
The boundary gate
The boundary is where parse-don't-validate earns its keep. A boundary that parses is total: every input is turned into a typed value or rejected, and nothing leaks through un-checked. A boundary that merely validates returns a boolean and lets the original untrusted string travel on, to be re-checked — or forgotten — downstream. Parsing makes the typed value the only thing the core ever holds. Feed the gate below a sample input and it reports the boundary's verdict: a typed value, or a rejection.
The boundary parse gate · pick an input
A property test proves; an example asserts — and a parsed boundary value is the only thing the core ever trusts.
The method on the Portal
The Portal runs all four moves on its branded identifiers. Portal.ID.generate/1
mints a fresh id; Portal.ID.decode/1 is the boundary — it turns a string into a
struct carrying .type and .timestamp, or rejects it, so the
core holds only decoded values. A supervisor isolates a crashed process. And the round-trip invariant —
a generated id decodes back to itself — is proven with a property test across generated inputs, not the
three the author happened to pick. Acceptance closes against that proof. The supervision tree and the OTP
process model are taught by the companion Elixir course; this chapter cites
them and does not re-teach them, and invents no Portal surface or API beyond
Portal.ID.generate/1 and Portal.ID.decode/1.
The principle
Harden the built increment against the four pillars; accept it only when an invariant is proven and a parsed boundary value is the only thing the core trusts.
On the Portal
Portal.ID.decode/1 parses a string into a typed struct or rejects it; a property
test proves a generated id round-trips; a supervisor isolates a crash — and acceptance closes against
the proof.
A6 accepts the increment against the proof, not the demo: a property holds across generated inputs, the boundary rejects what is malformed, and the supervisor isolates what crashes.
Recap — harden, parse, prove
You harden the built increment from A5 rather than rebuild it: parse every boundary value into a typed value, supervise every process so a crash is isolated, and accept the rung only when an invariant is proven across generated inputs rather than asserted on a chosen few. A parsed boundary value is the only thing the core trusts. The Portal runs all four moves on its branded ids. That completes the chapter's orientation — the chapter then turns to its teaching modules, detailed once A6's triad is seeded. The next part, A7, runs the whole loop end to end on the Portal, on top of the production-grade increments A6 produces.
Next in the course: A7 — the Portal exemplar, the zero-to-production run that composes every prior Part, hardening each rung to production quality before the next.
References
Primary sources for parsing at the boundary, a closed error discipline, and proving an invariant across generated inputs — and where the production-grade increment this dive builds carries on into the course.
Sources
- King, A. — Parse, don’t validate — a parsing boundary is total: every input is a typed value or a rejection, never an un-checked string travelling on.
- Wlaschin, S. — Railway-oriented programming — a closed error discipline: parse, then carry success or a typed failure, never a surprise.
- Elixir — StreamData — proving a round-trip invariant across generated inputs rather than asserting it on a chosen few.
Related in this course
- A6 · Reliability and correctness — the chapter landing.
- A6 · What the chapter covers — the four pillars this method applies.
- A1.05 · Correct by definition — done as a closure over proven, not asserted, checks.
- A5 · The agent brief — the built increment this dive hardens.
- Companion · Phoenix (F6) — the real Portal web build.
- Companion · Functional Programming in Elixir — the Portal’s OTP foundations (cited, not re-taught).