The replay anchor: handing a third party the hash

Reproducibility is the property that separates a record from a claim. A log that says "the model produced this output" is a claim; a log that hands a third party a hash and says "rerun the computation and compare the bytes" is a check. The first asks the examiner to trust the log; the second lets the examiner verify the log. The field that makes the difference is the replay anchor — a hash that lets a stranger reproduce the computation bit-for-bit and confirm the output matches. Without it, the manifest is a signed claim. With it, the manifest is a verifiable record.

We are pre-revenue and building the POC. This post is about the replay anchor field in the manifest (BR-842), and why it is the one field that turns reproducibility from an assertion into a check.

What the replay anchor is

The replay anchor is a hash that captures everything needed to reproduce the computation: the model version (hash-pinned), the input NodeVersions (L1 through L4 of the GNL, hash-linked), the prompt template and generation config, the agent trace (which of the 23 A2A agents participated, in what order, CRDT-merged), and the output bytes. A third party with the anchor and access to the same model and inputs can rerun the computation and compare the output bit-for-bit. If the bytes match, the output is reproducible — not because the manifest says so, but because the third party checked.

Reproducibility by a stranger

The strength of the replay anchor is that the third party does not have to trust the firm that produced the output. The examiner, an auditor, a regulator, a counterparty — anyone with the anchor and the inputs can reproduce the computation and verify. This is what makes the manifest different from a self-attestation: a self-attestation says "we checked, and it is reproducible"; a replay anchor says "here is the hash, you check." The first is a promise; the second is a check. An examiner reads the two differently, because one of them is verifiable and the other is not.

A self-attestation says "we checked, and it is reproducible." A replay anchor says "here is the hash, you check." The first is a promise; the second is a check.

• The replay anchor captures model, inputs, prompt, agent trace, and output — enough for a stranger to reproduce bit-for-bit.
• Reproducibility by a stranger is the property that separates a record from a self-attestation.
• The examiner does not have to trust the firm; the examiner verifies the hash.
• Without the anchor, the manifest is a signed claim; with it, the manifest is a verifiable record.

What the anchor does not prove

The replay anchor proves reproducibility, not truth. A reproducible wrong decision is still a wrong decision; the anchor lets a third party confirm the firm produced it, not that the firm produced the right thing. Calibration — whether the decision was accurate — is a separate, gated loop (Gate 1b): shadow runs against ground truth, scored with Brier and log-loss via deino-eval. The anchor is the audit story; the calibration loop is the accuracy story. The anchor earns the word "reproducible"; the loop earns the word "probability." We keep them separate because that is where the honesty is.

The replay anchor is the field that turns a claim into a check. Reproducibility by a stranger is the property that earns the word — and the word is reproducible, not true.

— replay anchor design note

Why this field is the one that matters

Every other field in the manifest is a record of what happened; the replay anchor is the field that lets someone else confirm it happened. That is the difference between a manifest and a log: a log records, a manifest verifies. The anchor is what makes the manifest a manifest. Without it, the record is only trustworthy to the people who wrote it; with it, the record is trustworthy to anyone who holds the hash. We are building the POC, and the anchor is the field we would not ship without — because a manifest without an anchor is a claim, and a claim is not what an examiner is asking for.