jonnify·bcs /bcs/ideas/ecs-to-bcs/the-three-deaths

B1.4 · dive — the three deaths

Three boundaries, three deaths.

The handle’s validity is scoped to one process’s current memory layout, and each scope violation has a name: the save file, the socket, the foreign store. Each death traces to a missing property of the identity contract — and each of the contract’s answers is already a committed measurement.

Source: content/bcs1.4.md · What and the diagnosis; the contract’s answers are on stage in bcs_rung_1_1_check.out.

The deaths, stepped. Select a boundary to read what dies, what the industry built around the corpse, and the missing contract property.
{idx | gen} one process, one layout the save file the layout is gone after restart the socket entity 4117 names nothing on machine B the foreign store a handle cannot be a foreign key
readout · Select a boundary. Static reading: restart kills the layout an index points into; replication mints a second identity scheme; a database grows serials, created_at columns, and per-table shard keys — and the silent join arrives with no compiler in reach.
§1

The deaths, named

content/bcs1.4.md · What
DEATH 1

The save file

An index is an address into an array arrangement that no longer exists after restart, so persistence becomes a swizzling pass — every table rewritten from handles to something durable and back — and the generation pattern serializes into noise.

DEATH 2

The socket

Entity 4117 on machine A names nothing on machine B, so replication mints a second identity scheme with bidirectional mapping tables at both ends — the dialect failure, self-inflicted before any foreign runtime is even involved.

DEATH 3

The foreign store

A handle cannot be a foreign key, so the database grows its own serials; created_at columns sprout beside them — the second clock; shard keys are invented per table — the routing table; and nothing anywhere checks that the integer arriving in the assets table was ever an asset — the silent join, at last, with no compiler in reach.

Three boundaries, one pathology: the handle’s name embeds the process’s private circumstances, so the name dies wherever those circumstances end.

§2

The diagnosis, in contract terms

content/bcs1.4.md · quoting bcs_rung_1_1_check.out

A handle is placement and liveness wearing identity’s clothes. The index is placement, leaked into the name — which is why the name dies whenever the layout does. The generation counter is a liveness check, and its own literature is candid that the check “isn’t waterproof” — collision detection over a reused slot, probabilistic by construction. The contract separates what the handle fused, and two of its answers are already in the committed transcript:

content/echo_data/runtimes/elixir/bcs_rung_1_1_check.out · G4–G5frozen
G4 ordered ok -- page_desc(2000) == byte-sort desc over 2000 minted ids; store holds no clock
G5 placed ok -- placement(USR0KHTOWnGLuC) -> 234878118

What remains in the name is exactly what a name should carry — kind and instant — at 65 bytes per key on the measured table, cheaper at rest than the handle’s own decimal shadow.

§3

What the handle fused, separated

content/bcs1.4.md · the diagnosis
One fused artifact, three contract properties. Select a property; the readout compares the handle’s answer with the contract’s.
the handle placement + liveness, fused placement — derived hash32(name), never embedded uniqueness — prevented the minting law never reuses a name kind — carried in the value and the type
readout · Select a property. Static comparison: hash32 derives the slot from the name — 234878118 at 0.9586 ns; the minting law makes the ABA case unrepresentable — two thousand mints paged in exact byte-sort order; the silent join dies at the gate — 200 / 400 / 400 / 404.

Generation counters are rejected by subsumption: detection of reuse is replaced by prevention of reuse, and a probabilistic guard for an impossible event is deleted weight. The store-side half of the third death — keys, serials, and shard schemes as a design surface — is taught applied in the Redis Patterns course.

§4

References

sources · related

Sources

Related