Independence Without Replay Is Still Weak

The Distinction

A verifiable record makes three distinct claims, and most systems conflate them. Existence means the record is present and was issued. Integrity means the record has not been altered since issuance. Fidelity means the record accurately reflects what the system actually did. These are not the same claim. Passing one does not imply passing the others.

Independence — achieved through external anchoring, cryptographic signing, or third-party timestamping — addresses existence and integrity. A signed receipt proves that someone issued a receipt with those contents, and that the contents have not changed. It does not prove the contents were accurate at the time of writing. That accuracy question is fidelity, and independence leaves it entirely open. The evidence path runs from the record outward. It says nothing about whether the record was constructed faithfully from the execution it claims to document.

Fidelity is a claim about capture — whether the mechanism that produced the record could be influenced by the system it was recording. A record written by the system under review, at the system's discretion, about the system's own behavior, carries only the system's assertion of fidelity. External anchoring does not change this. You can cryptographically seal a lie.

Replay closes the fidelity gap by a different mechanism. If an execution can be replayed from its evidence artifacts — and the replay produces the same result — the record demonstrates fidelity, not just integrity. The replay does not depend on the system's claim about what happened. It re-derives the outcome from the same inputs. Independence without replay is better than nothing. It is not a complete proof surface.

Why It Matters

The failure mode is specific: a record with strong integrity properties but weak fidelity properties can pass audit while the system behavior it describes was incorrect. The auditor verifies the signature, checks the anchor, confirms the hash chain — and returns a clean result. Everything that was checked passed. What was not checked was whether the record contents matched the execution. That gap is invisible to an integrity-only review.

Consider an AI agent that logs its own reasoning trace and submits the trace as the proof artifact. The trace is signed by an external notary, timestamped, immutable. Integrity passes. But the trace was written by the agent, describing what the agent chose to describe. If the agent omitted a step, hallucinated an intermediate result, or summarized a branch it never took, the signed trace reflects none of that. The auditor has a verified record of what the agent claimed it did. They do not have a verified record of what the agent did.

This matters most when the audit is load-bearing — when a downstream decision, a compliance gate, or an operator approval depends on the audit result. An integrity pass on a low-fidelity record is not a weaker version of a complete verification. It is a false signal. It has the form of a passed proof and the substance of an unchecked assertion.

Real-World Example

A CI/CD pipeline runs a build, executes a security scan, and produces a signed artifact. The artifact receipt includes the scan result, the commit SHA, the build timestamp, and a hash of the binary. The receipt is signed by the pipeline operator's key and anchored to an external transparency log. Any downstream consumer can verify existence and integrity: the receipt was issued, it has not changed, it was issued at the recorded time.

Now suppose the pipeline was misconfigured: the security scan ran against a cached copy of the source tree from a previous commit, not the commit recorded in the receipt. The scan passed because the cached tree had no findings. The receipt records a passing scan against the correct commit SHA. Both claims in the receipt are wrong in the same direction — the scan was not run against what the receipt says it was run against.

The receipt passes every check an integrity-only verifier can perform. A replay-capable verifier re-runs the scan against the recorded commit SHA and gets a different result. Fidelity fails. The transparency log did not fail. The signature did not fail. The thing that failed was the assumption that a well-anchored record is a faithful record.

The Test

Before treating a signed, externally anchored record as evidence that a system behaved correctly, ask:

Could the contents of this record be inaccurate — through omission, summarization, or wrong inputs — while every integrity check still passes?

A passing answer requires a mechanism that captured evidence at execution time, from a source the executing system could not have modified, and a replay path that re-derives the outcome from those artifacts independently.

A failing answer looks like: "The record is signed and the signature is valid."

Closing Principle

Independence is the threshold for verification. It is not the ceiling. A record that is externally anchored but not replayable has been verified to exist and verified to be unchanged. Whether it was ever accurate is still open.

Replay is not a bonus property of a strong proof system. It is what distinguishes "this happened" from "this was recorded."

If this looks familiar, reading more won’t fix it → /review

See also: Why Third-Party Verifiers Still Fail When the Evidence Path Is Controlled — the review that applies this distinction to a live audit scenario.