CONCEPTS

Replay & determinism

Replay re-runs a decision against the same recorded inputs and policy to check that the outcome reproduces. When it does, the receipt is more than a story about what happened — it is a claim anyone can test.

What replay means here

Every evaluation submitted to POST /v1/evaluate carries its inputs with it: the claim, the evidence sources, and the policyConfig that governed the decision. Replay is the act of running that exact recorded input set back through the same policy and observing whether the same result comes out. It asks a narrow, mechanical question — given these inputs and these rules, does the decision reproduce? — and answers it yes or no.

This is different from an after-the-fact explanation. An explanation is a narrative assembled later: a summary of why a decision probably went the way it did, written by a human or a model reasoning about the record. A replay produces no narrative. It re-executes against the captured inputs and compares the outcome. An explanation can sound convincing and still be wrong; a replay either reproduces the result or it does not, and that distinction is recorded rather than argued.

How the API surfaces replay

The replay result is observable in the API contract at several points, so a caller never has to take determinism on faith.

• On the claim. The optional expected_replay_match boolean on the ClaimInput records what the submitter expected: whether re-running this claim should reproduce the same result. It states the expectation up front, before the evaluation runs.
• In policy. Setting requireReplay: true in policyConfig makes replay determinism a condition of admissibility rather than a passive observation. With it set, a claim that does not reproduce cannot be accepted.
• In the result. The response carries a top-level replay object, and the receipt embeds its own replay block reporting deterministic (whether the outcome reproduced) and a replay_hash over the replayed result. The hash lets two parties confirm they are comparing the same replayed outcome, not merely the same words.
• In admissibility. When replay is required and the result does not reproduce, the receipt's admissibility.status is set to NON_DETERMINISTIC — one of the three documented statuses alongside ACCEPTED and REJECTED.

The replay block in a receipt looks like this:

RECEIPT (REPLAY BLOCK)

"replay": {
  "deterministic": true,
  "replay_hash": "sha256:..."
}

A non-deterministic result is recorded, not hidden

Determinism is not assumed, and its absence is not suppressed. When a decision fails to reproduce, the receipt does not quietly drop the claim or paper over the discrepancy. It records the outcome plainly: the replay.deterministic field reads false, and where replay was required the admissibility status becomes NON_DETERMINISTIC.

This matters because the failure case is exactly where audit trails are usually weakest. A record that only ever shows success tells you nothing about its own reliability. A record that can show, and does show, when reproduction failed is one you can trust to be honest about the cases that matter most.

Why determinism makes a record falsifiable

Determinism is the property that turns a record into something testable. A non-deterministic claim is, in the strict sense, unfalsifiable: if re-running the same inputs can yield different outcomes, no later check can confirm or refute what the record asserts. There is nothing to hold the record to.

A deterministic decision is the opposite. Anyone holding the inputs and the policy can re-derive the outcome and compare it against the replay_hash in the receipt. If the recomputed result diverges from what the receipt claims, the discrepancy is detectable — which is precisely what it means for a claim to be falsifiable. Determinism is what makes "the system decided X" an assertion you can check rather than one you must accept.

This is why replay sits alongside evidence, policy, and Ed25519 attestation as a first-class part of the receipt. Attestation proves the receipt was issued by the server and not altered since. Replay proves the decision inside it can be reproduced from its inputs. Together they let a receipt be verified — independently, with POST /v1/verify or offline against the server's published key — rather than merely believed.