Method note
Known Then, Known Now: Why a Replay Must Not Rewrite the Past
A replay is useful only if it shows what was known at the time, not what we learned afterwards.
Evidence levelE0Concept
In brief
A replay is useful only if it shows what was known at the time. If today’s corrections are applied to yesterday’s picture, the replay becomes a story about what we now think, not a record of what was seen and decided.
The question
What should a replay show: the world as it was, or the world as we now understand it?
Context
States are revised. A late observation can change an earlier state, a source clock can be corrected and a classification can be refined. After an event, reviewers want to understand why someone acted as they did. If the replay shows the refined picture, the decision looks better or worse than it really was.
How we approach it
Each state keeps its observations, the time they were received and the time they refer to. The replay is designed to rebuild the state from what had arrived by that moment. Later knowledge is available as a separate, clearly labelled view, so both questions can be asked without mixing them.
What follows
A replay that does not rewrite the past is one a reviewer can trust. This is a design principle at E0; no replay behaviour has been measured.
What this does not establish
- That any replay has been validated against a real event.
- That a later view is wrong; it is a different question, kept separate on purpose.
Limitations
- This note describes a design rule, not a tested replay.
- Rebuilding a state from what had arrived assumes the arrival times were recorded faithfully.
- It does not say how long a replay takes, or how much history a deployment can keep.