Runtime and replay

Audience: developers · Read route: rebuild · Reflects specification v0.1

A runtime holds no master copy of state. It holds an ordered stream of recorded actions and rebuilds state by applying them; the log is the source of truth, and state is a function of the log. This page describes that mechanism at the depth needed to rebuild it. The property it produces, that any change is detectable and any past state is recoverable, is the subject of the next page, Data integrity and verification.

Three roles as replaceable adapters

The runtime contract is expressed as three roles. Each is a replaceable adapter behind a port contract, so an implementation can swap any one of them without touching your domain code.

• The reader admits recorded actions from the public audit layer, in log order, and replays each one through the method body that recorded it.
• The writer takes a method invocation, encodes it as a recorded action, signs it, and submits it through the overlay towards the audit layer.
• The recorder persists the reconstructed canonical state and continuously verifies that a fresh replay reproduces the state it holds.

Because the roles are adapters, a runtime that plugs a no-op into the writer becomes a read-only replica, and one that plugs a no-op into the reader becomes a submit-only worker. That is the whole of the topology story, developed on the Topologies page. The wallet that holds keys and the storage that holds bytes are adapters on the same footing: swap the wallet to relocate custody, swap the storage to change where content lives.

Deterministic replay

Two readers that consume the same recorded actions in the same order arrive at identical state. This holds because a method body is a pure function of the current state and the incoming recorded action, and nothing else. A method body reads no clock, draws no randomness, and makes no network call. The time a method needs is carried inside the recorded action, so replaying an old action a year later produces the same result it did the day it was recorded.

This is what makes state portable rather than owned: any party holding the log and the keys it is entitled to can reconstruct exactly the state the recording party holds, without asking that party for a copy and without trusting the copy it would get.

The self-check and the drift halt

The recorder replays recently applied actions and compares the result against the state it has stored. Agreement is the normal case. Disagreement is drift, and drift has only three possible causes: the stored state was tampered with, a method body was not pure, or the storage layer is corrupt. None of the three is safe to continue through, so drift is grounds to halt rather than to paper over: a runtime that keeps serving after drift is serving state it can no longer prove.

Schema evolution by method version

Method bodies change as a domain evolves, but a change must never silently alter the meaning of an action already recorded. Each recorded action carries the method version it was recorded with, and replay applies that version. A newer version applies only to actions recorded after the cutover. The cutover itself is a recorded action, so the point at which meaning changed is on the log, in order, like any other event. There is no untracked schema change.

The rules behind this page

The MUST rules for log-order reconstruction, pure method bodies, drift detection and halt, per-action method versioning, and recorded cutover are in the base protocol specification, Section 3.5. This page explains the mechanism behind those rules; the specification states what an implementation MUST do, and Section 6 names the behavioural checks that demonstrate deterministic replay and drift detection.