B2.1 · A System Is an OTP Application — manuscript chapter 2.1

The noun, given a runtime shape.

“System” was Part I's load-bearing noun, and OTP is where the noun acquires a runtime shape: a supervised process owning a table behind an export list. Chapter 1.1 built the skeleton and promised the full treatment; this chapter delivers it without changing a line of the skeleton — which is the claim.

The chapter is content/bcs2.1.md; the rung behind it is bcs2.1, and its committed transcript closes PASS 5/5. Boundary, tree, ownership, restart semantics — each a decision made explicit and gated on stage.

The five gates, mapped to the dives. Drawn in transcript order. Select a gate to read its verbatim line and the dive that teaches it.

readout · Select a gate to read its verbatim line and the dive that teaches it. Five gates over the unchanged substrate; the full transcript is frozen in §2 below, the dives are mapped in §3.

§1

Decisions, not accidents

content/bcs2.1.md · Why

The stakes are not abstract on a trading platform — when the position store crashes at 14:30 with the book open, what restarts, what survives, and what cascades is a design decision with money attached, and a design decision that was never written down is still a design, only an accidental one. This chapter writes the defaults down and proves each on stage, so that every Part II system after it inherits decisions rather than accidents.

OWNERSHIP

Data dies with the owner, by design

A private ETS table dies with its owning process; durability is a different chapter's job — the written default, gated by R2.

CHECKPOINTS

Checkpoints are rows

State that must survive a process lives in a store; recovery runs through the boundary, not the heap — gated by R3.

RADIUS

one_for_one is the default

Wider is a written claim that the named children die together — the strategy as a blast-radius statement, gated by R4.

BOUNDARY

The export list is the boundary contract

Six domain functions plus OTP callbacks, nothing else; adding an export is an architecture change — gated by R1 and R5.

§2

The proof

content/bcs2.1.md · quoting bcs_rung_2_1_check.out

The full committed transcript, verbatim — it prints in the order boot, R1, R2, R4, R3, R5:

content/echo_data/runtimes/elixir/bcs_rung_2_1_check.out · verbatimfrozen

boot: two stores under one_for_one; native codec self-check passed at each init
R1 surface ok -- exports: six domain functions plus OTP callbacks, nothing else -- no table, no pid, no internals
R2 existence ok -- existence restored, data not: fresh table after kill -- durability is a different chapter's job
R4 radius ok -- sibling untouched (one_for_one): ord_store pid stable, row intact through prt_store's crash
R3 checkpoint ok -- recovered through the boundary, not the heap: re-put from a read-back row
R5 gate ok -- prt_store refuses an ORD name with {:error, :namespace} -- admitted kinds are per-boundary
PASS 5/5

The substrate's three modules (bcs.ex, bcs/property_store.ex, bcs/supervisor.ex) already are an OTP application in everything but the Application callback module — the proper callback module arrives with the umbrella adoption rung, where a Mix project exists to declare it in. The boot line carries clause three applied to startup: native codec self-check passed at each init — a store refuses to exist before the canon proves itself. The evidence stands beside bcs_rung_1_1_check.out: the skeleton's six gates, re-running green under the grown surface.

§3

The dives

three lessons, fixed by the chapter spec

B2.1.1

The Export List

R1 — the boundary is the export list: start_link/1, put/3, get/2, page_desc/2, record_entity/2, placement/1 plus OTP callbacks, nothing else; the private table never exported. R5 — the boundary declares its kinds: prt_store refuses an ORD name with {:error, :namespace}.

dive 1built B2.1.2

Existence and the Kill

R2 — existence restored, data not: the BEAM guards data, not existence; a private ETS table dies with its owner, by design. R3 — recovered through the boundary, not the heap: checkpoints are rows.

dive 2built B2.1.3

The Blast Radius

R4 — sibling untouched under one_for_one; start order as the dependency declaration; strategy as a written claim; the Go supervise loop.

dive 3built

§4

References

sources · related

Sources

Erlang/OTP — the supervisor behaviourrestart strategies; start order; the tree the two stores run under
Erlang/OTP — the ets moduleprotection levels — :private; table ownership and the owner's exit

B2 — The Elixir BCS Corethe chapter landing; the Part II arc
BCS — the course homethe law, the id anatomy, the chapter map
Functional Programming in Elixirthe umbrella where echo_data lives