Skip to content

Deterministic Replay Protocol

Reconstruction protocol — instantiates Event-Log-Centered Modeling

Reconstructs a past state or sequence by re-applying the same events in the same order through the same logic, so the rebuild is reproducible down to the last detail.

An event log is only worth keeping if you can turn it back into state on demand — and turn it back into the same state every time. Deterministic Replay Protocol is the discipline that guarantees this. Given a range of events, it re-applies them one by one, in their canonical order, through a pinned version of the fold logic, so that replaying the same events always yields a bit-for-bit identical result. Its defining commitment is reproducibility: not merely "rebuild the state" but "rebuild it identically, every time, for anyone" — which is what makes replay usable for audit, for debugging a past incident, and for regenerating a projection after its code changes. The protocol's real content is everything that must be nailed down — order, logic version, starting point, and the assertion that the event set is complete — for the rebuild to be trustworthy rather than merely plausible.

Example

An autonomous-vehicle team investigates a hard-braking incident. The car's black box has been streaming events to the log — perception detections, planner decisions, actuator commands — each with its sequence marker. To understand why the car braked, engineers do not reason from summary logs; they run the deterministic replay protocol: load the vehicle's event range for the ninety seconds around the event, pin the exact software version that was running, and re-apply every event through it. The reconstructed decision sequence is identical to what happened on the road, so they can watch the planner's state evolve step by step.

The protocol earns its name at the completeness check. Before trusting the reconstruction, the team asserts the range is complete — no dropped perception frames, no gaps in the sequence numbers — because a replay missing three frames would deterministically produce a wrong answer and look just as confident. Only once completeness is established do they trust that "the planner never saw the pedestrian until frame 1,412" is a finding and not an artifact of a hole in the log. The same replay, run next week on a different machine, reproduces the sequence exactly — which is what lets it stand up in a safety review.

How it works

What distinguishes replay from merely "reading the log" is the set of things it must control to be deterministic:

  • Fix the rebuild path. A defined route from a known starting point (origin, or a trusted checkpoint) forward through the event range to the target state.
  • Pin the order and the logic. Replay honors the canonical event order and applies a specific version of the fold function — same inputs, same code, same output.
  • Quarantine nondeterminism. Wall-clock reads, random values, and external calls made during original processing are treated as recorded inputs, not re-invoked, so the rebuild does not diverge.
  • Assert completeness of the range. The protocol states explicitly that every event in the replayed window is present and gap-free — because a faithful-looking reconstruction from an incomplete log is worse than no reconstruction.

Tuning parameters

  • Replay start point — from origin versus from a checkpoint. From origin is maximally faithful but slow; from a checkpoint is fast but trusts the checkpoint's correctness.
  • Logic-version binding — replay through the original code version versus the current one. Original reproduces history exactly; current tests how today's logic would have handled the same events (a migration, not a reconstruction).
  • Completeness strictness — how hard the protocol fails on a detected gap. Strict refuses to produce a result on any missing event; lenient reconstructs with an explicit caveat.
  • Determinism enforcement — how aggressively nondeterministic inputs are captured and pinned. Tighter capture guarantees identical rebuilds but instruments more of the original path.
  • Replay scope — whole-system versus single-entity replay. Narrow scope is cheap and targeted; whole-system replay is exhaustive but expensive.

When it helps, and when it misleads

Its strength is that it converts an audit or a debugging session from argument into demonstration: instead of speculating about past state, you rebuild it and watch it unfold, and anyone can rerun the same replay and get the same thing. It is also the engine behind rebuilding a projection when its logic changes — regenerate, don't migrate.

It misleads in two ways. First, determinism is a property you must engineer, not assume: if the original processing read the clock, called a flaky service, or depended on thread timing, a naïve replay silently diverges and produces a confident falsehood. Second, replay is only as honest as its completeness claim — a gap-free-looking log with silently dropped events reconstructs the wrong past with full conviction, so completeness must be asserted, not hoped. And replaying through today's logic while calling it "what happened" quietly rewrites history. The discipline is to pin the version explicitly, capture nondeterministic inputs as recorded events, and never present a reconstruction without its completeness statement attached.

How it implements the components

Deterministic Replay Protocol realizes the reconstruction side of the archetype — the components that turn stored events back into trustworthy state:

  • replay_and_rebuild_path — it defines the route from a starting point through the ordered events to a reconstructed state.
  • event_completeness_statement — it asserts the replayed range is present and gap-free, without which the rebuild cannot be trusted.

It rebuilds but does not store, order, or dedupe: the canonical log and its sequencing are Append-Only Event Store; making replayed side effects safe to re-apply is Event Replay Deduplication; and fast rebuild-from-snapshot is Snapshot Plus Replay.

Notes

Determinism and idempotency are often conflated but are different guarantees. Deterministic replay ensures the computed state is identical on every rerun; it says nothing about the side effects re-issued during replay (emails, payments, downstream calls). Replaying a log that re-fires those effects can do real damage. Keeping the two separate — deterministic reconstruction here, idempotent effect-application in Event Replay Deduplication — is what makes replay safe to run against a live system.

References

Record-and-replay (deterministic replay) is an established debugging and reproducibility technique: capture a program's inputs and nondeterministic choices, then re-execute them to reproduce the exact run. Its correctness depends entirely on capturing every source of nondeterminism.