Replay answers one question: given the same recorded world, does the system make the same decisions? It is how a change to the system is tested against real past runs without touching the outside world.
Architecture contract
How replay works
Replay re-runs a finished run at the decision and tool boundary to answer one question: given the same recorded world, does the system make the same decisions?- Effects are recorded-only. Every external call is served from the recording. This is the only replay mode.
- Nothing is executed live. A call with no recording fails that step with
ERR_REPLAY_UNRECORDED. It is never sent to the real system. - Decisions are recomputed. The replay reconstructs which node ran, the evidence it saw, the capability or tool it resolved, and why it branched. Generated text does not need to be reproduced token for token.
- Divergence is reported. The result is
equivalent,diverged_expected(a difference caused by something you deliberately changed) ordiverged_unexpected.
Current implementation
Replay is on main, internal only. A cassette is recorded from a finished run’s receipt chain. Replay runs in recorded-only mode and produces aDivergenceReportV1. The gate has a replay mode: tool results and policy decisions are served from the recording, and any attempt to execute live is denied on every gate path. The internal work runtime service accepts POST /v1/replays and enforces effects: recorded_only, and an operator command records and checks replays. None of this is reachable through https://api.allternit.com yet. Replay remains on the critical path for the Agency API alpha, which also needs the public endpoint.
Availability
Developer relevance
Replay never causes effects, so you can use it freely to compare a changed authority profile, completion criteria or model class constraints against a real run. Treatdiverged_unexpected as a regression signal. A step that fails with ERR_REPLAY_UNRECORDED means the recording is incomplete, not that the system called out.