The technology: the loop, in code, with one small trace

How exactly is this implemented at the program level, and how the system checks its own consistency.

Source: lib/core/wave/create-wave-engine.ts, lib/core/runtime/create-wave-runtime.ts, lib/core/membrane/create-membrane.ts, lib/core/registers/*.

§The register file — the machine's whole state, as one value

Everything the machine is doing right now — where its two cursors are, what every listener has collected so far, which outside answers are still pending — lives in exactly one value, the register file. Nothing is held in a private variable anywhere else. Every single change to it goes through one function, recordTransition, which — in the same movement — writes the change and appends a line to a journal naming which function made it, from which file, under which tuple's context. This journal is not a debugging afterthought; it is how Part 6.4 can trace a gesture through every ring with total confidence, and how Part 7.4 can show exactly which check ran when.

§The two cursors that make "exactly once" true

Two independent counters walk the same log, never sharing a position, never moving backwards:

• takeNextTuple advances the engine's own cursor and hands the tuple to every listener and doer inside the machine — this is the "hand it to every processor" step of 1.3's rhythm.
• sweepNextTuple advances the membrane's cursor, entirely independently, and offers the same tuple to every outside controller.

Because each cursor only ever moves forward by exactly one, a tuple is seen by the inside machinery exactly once and offered to the outside world exactly once — the specification's exactly-once discharge guarantee is not a promise kept by convention; it is a direct consequence of there being only one way to advance either counter.

§The settle loop — alternation until quiescence

runtime.settle:
  repeat:
    engine.run over the current pending records      # the "wave" of 1.3
    membrane.sweep — offer every new tuple to every controller
    if nothing is waiting on an outside answer: done — return the log
    otherwise: wait for the EARLIEST outside answer to arrive,
               feed its records back in as the next pending batch,
               go around again

This is the whole of createWaveRuntime.settle — under twenty lines, and it is the only place the machine ever waits for the outside world. Every request the system handles, however large the chain of consequences turns out to be, is exactly one call to this loop, run once, to completion.

§A trace small enough to hold in your head

The very first wave of any session — the moment a person's opening question is committed — is a compact instance of every piece above, drawn from a real session (loop-sem-1, walked in full in the companion technical reference):

Seventeen tuples, one wave, one call to settle, no gaps in the numbering — and every arrow in that table is a real journal line, not an inference. The full front-door step in the companion technical reference reproduces every one of these tuples' exact payloads and every journal transition behind them.

§How the machine checks itself

Because every state change is journalled the same way, the codebase can and does hold itself to mechanical proof rather than only careful writing: a golden fixture test replays a fixed script and checks the resulting log byte-for-byte against a known-good recording; a parity oracle runs the identical script two ways — continuously, and via a snapshot-and-restore in the middle — and checks the two runs are indistinguishable; the ring-discipline guard (met properly in Part 6) scans every file's imports to confirm no ring reached past its neighbour. None of this proves any one finding is correct — that is always a human's job, taken up fully in Part 7 — but it proves the machinery that produced it did not silently misbehave on the way.