Replaying offsets is not enough when computation changes its inputs

A deterministic state transition maps a prior state and a defined event to one next state and output. A current wall-clock read, mutable external lookup, random draw, thread race, or changing configuration adds another input. Merely rereading the event does not recreate that value. For model enrichment, pin the model and feature version or retain the original lookup result when the contract requires replaying the original decision. An alternative contract can intentionally recompute with current information, but then label it as recomputation rather than reproduction of the original result.

A random seed helps only with additional control over generator state, algorithm, call ordering, and partitioning. Rescaling or a new code branch can consume draws in a different order despite the same initial seed. Using processing-time timers can also make event-to-output timing or expiry depend on replay speed. Event-time rules reduce some timing dependence, but watermark and late-data policies still matter. Record code, schema, serializer, configuration, and artifact versions alongside source positions so an audit can reconstruct which computation was intended.

Interleaving across partitions can change after recovery. An associative, commutative exact aggregate can tolerate some reorderings mathematically, while a sequence-sensitive state machine cannot. Floating-point addition is not exact real addition, so even a mathematical sum can change its final bits under another reduction order. Decide whether the contract requires bitwise equality, a justified numerical tolerance, or an invariant such as a conserved integer count. Do not apply a tolerance to identifiers or financial-style integer units merely to make a replay comparison pass.

An external side effect is not a pure replay input or output unless the protocol makes repeated execution compatible. Sending an HTTP request again can read different data or commit a second effect. Managed-state checkpoints cannot roll back arbitrary remote work. Use a compatible transactional or idempotent mechanism where required, and retain evidence of its outcome. Distinguish a function being executed twice from a logical contribution becoming visible twice. A deterministic function can still duplicate a side effect if called again without a correct external boundary.

Build a fixture containing input records, initial state, source positions, artifact versions, lookup responses, and the expected output invariant. Run it through a failure-free path and a restore path with deliberately changed partition timing. Include a failure after external commit but before its acknowledgment, and inspect durable effect count. If current-data recomputation is intentional, compare against that separately specified target. Version changes need an explicit state migration or compatibility decision; a successful restart that silently changes the transition function does not establish equivalent results.

The probability lab demonstrates why identical distributions are weaker than identical histories. Reset, explicitly set BOTH p=0.5 and n=10, inspect the exact binomial bars, then Play or Step. Reset and re-set BOTH identical controls for comparison: the bars remain identical because the lab computes probabilities, not sampled outcomes. Edits retain elapsed time; playback only highlights a bar. This does not show a seeded event sequence or a deterministic stream processor. Explain how two different ten-trial histories can have the same success count and distribution, then identify which actual sequence and state inputs a replay test must preserve.