The four-input replay recording (ADR-0029), as a value.

A recording holds exactly what a replay needs to reconstruct a run:

• machine - the compiled document a session was started over (Statifier.Machine, the output of Statifier.compile/1).
• opts - the normalized options Statifier.Session.start_link/2 would have passed to Statifier.MachineState.new/2: :session_id, :trace, :datamodel, and :max_macrostep_rounds, defaulted and sorted so two recordings of the same run compare equal.
• entries - the delivered events, timer firings, cancel markers, and interpret/2 batches, in the session's serialized input order.

Together, machine and the first entry's implicit initialization plus the rest of entries are the whole of what a run needs to be reproduced - nothing else about a session (its pid, its subscribers, its live timer references) is part of a recording, because none of it is an input; all of it is either derived or process-shaped.

The route snapshot rides on the entry, not as a fifth input

ADR-0048 decision 2 has the caller stamp a Statifier.Send.Routes.t() snapshot onto %MachineState{} before every core drive; decision 3 has each recorded entry that triggers a drive carry the snapshot that drive was judged against. This is an attribute of an existing entry, not a new recording input and not a new entry kind - ADR-0029's four inputs (machine, opts, and the two entry-producing kinds it already named) are unchanged in kind. Every entry() variant therefore widens by one trailing Statifier.Send.Routes.t() | nil field, including :cancel, which becomes {:cancel, routes} rather than a bare atom: a cancel drives Statifier.Interpreter.cancel/1, whose exit walk can run <onexit> blocks containing <send>, so it needs a snapshot exactly as every other drive does. nil means the driver declared nothing - the same meaning nil carries on %MachineState{}.routes itself - and opts's own :routes key carries the snapshot in force for the implicit session-start initialization, riding where every other Statifier.MachineState.new/2 option already rides.

:session_id is resolved, not supplied

A caller starting a session may never pass :session_id at all, letting Statifier.MachineState.new/2 generate a fresh sess_ id (ADR-0008). A recording still needs one concrete value stored, or replaying it would regenerate a different id and diverge from the run it is meant to reproduce. new/2 therefore takes the id the session actually settled on - read back off machine_state.datamodel["_sessionid"], exactly as Statifier.Session.init/1 does - not whatever the caller passed (or did not pass) as an option.

A batch is one entry, not several

An interpret/2 call hands a session a list of effects to plan and perform as one unit, in the same handle_cast that serializes every other input. Splitting that list into one entry per effect would lose the fact that they arrived together, at one position in the input order, rather than as several separate calls that happened to be adjacent - a distinction replay needs, since Statifier.Session.Effects.plan/1 and any effect-derived routing decisions apply to the batch as interpret/2 presented it. Storing the whole batch as {:interpret, effects, routes} preserves that boundary exactly.

The timer ref is dropped, not recorded

A live session mints a make_ref/0 correlation id purely to match a fired :statifier_delayed_send message back to the Statifier.Session.Timers entry that scheduled it - a detail of how one process tracks its own in-flight timers, with no meaning outside that process and no reproducible value across runs (a fresh reference is unequal to every past one, by definition). What a recording needs from a firing is only its send_id (nil for an unnamed send) and the Statifier.Event.t() it delivered, so put_timer/3 takes exactly those two and no reference ever reaches this struct.

Nothing here reads a clock

Ordering in entries is ordinal - each entry's position in the list - and that is sufficient: ADR-0034 decided that replay reproduces firing order and relative timing, never re-waiting the original delays, so a wall-clock timestamp would be a value replay is obligated to ignore. ADR-0029 named the four inputs a sound recording needs, and none of them is a clock reading. This module calls no Process.* or System.* time function, and the Mix.Statifier.AdrGuard allowlist that lets Statifier.Session alone touch wall-clock time does not name this file.

The binary contract

to_binary/1 and from_binary/1 (ADR-0057) give a recording a versioned binary envelope: {:statifier_recording, format_version, chart_blob, opts, entries, anchor}. A version-1 envelope omits the trailing anchor slot entirely (five elements, not six carrying nil); from_binary/1 reads both shapes (see below). A version-2 envelope has all six slots but predates caller_context on %Statifier.Event{} and the two durable-timer effect structs (ADR-0063): its stored inputs decode with caller_context: nil defaulted on import, which is safe exactly because no context was ever attached to the inputs an older blob holds. Six slots -

• format_version - this module's own version tag, checked before the nested chart is touched (ADR-0057 decision 4): a future format this build cannot read reports as a version mismatch rather than failing confusingly further in.
• chart_blob - machine travels as a nested Statifier.Chart.to_binary/1 blob, never a compiled term (ADR-0014 item 2, ADR-0052 decision 3). from_binary/1 recompiles it through Chart.from_binary/1, which checks its own format version and its own recompiled identity in its own order - a chart-format bump is therefore never forced to be a recording-format bump, or the reverse (ADR-0057 decision 3). A nested chart failure surfaces wrapped as {:error, {:chart, reason}} rather than flattened, so the caller always knows which decoder refused.
• opts - the normalized session options, with :invoke_handlers written as module name strings rather than atoms.
• entries - written in entries/1's append order, not the struct field's internal reversed order; that reversal is a prepend-list storage optimization this module alone knows about (decision 1 is what makes restoring it on decode legal), and a blob that copied the raw field would bake that implementation detail into the format.
• anchor - anchor/1's blob, or nil - see the moduledoc's "Anchored recordings" section (ADR-0060 decision 6). Present only in a version-2 envelope; a version-1 envelope's absent sixth slot decodes to the same nil.

:invoke_handlers cross the boundary as strings, never as atoms, because :safe decoding refuses to create atoms a blob names and a module's atom exists on a node only once that module is loaded (ADR-0052's Consequences, ADR-0057 decision 5). from_binary/1 resolves every string back with String.to_existing_atom/1, collecting every failure - not just the first

• into {:error, {:unknown_handler_modules, names}}, sorted, so a host learns the whole set of modules it needs to load in one round trip.

What the codec does not, and cannot, verify: that a resolved handler module's planning callbacks (ADR-0051 decision 4) behave the way they did when the recording was made. Replay's determinism depends on that equivalence for any recording naming a handler, and ADR-0057 decision 5 records it as an accepted environmental limit - the same class as ADR-0034's OTP MapSet-iteration caveat - rather than something a codec could check. perform/2, the impure half of a handler, is never called by replay at all (lib/statifier/replay.ex), so it needs no equivalence.

Anchored recordings

ADR-0060 decision 6: a recording made by a resumed session begins somewhere other than the chart's initial configuration - the position the session was resumed from. anchor/1 carries that starting point as a Statifier.Position.to_binary/1 blob, never a %MachineState{} and never a %Machine{} - the blob keeps "no compiled term is ever serialized" true by construction (ADR-0052 decision 3), and it is what Statifier.Position.from_binary/2 already knows how to identity-check against machine/1 on replay. anchor: nil (the default, and what every recording made before this decision decodes to) means "start at Statifier.Interpreter.initialize/2," exactly as before this field existed. An anchored recording's entries/1 stream contains no initialization effects, because a resumed session performs no initialization (ADR-0060 decisions 1 and 4 skip initialize/2 entirely) - Statifier.Replay.run/1's anchored branch reflects that by performing no effects of its own before folding the first entry.