BR-842: the audit manifest, field by field
What each field attests — and the one thing the manifest refuses to assert.
The audit manifest is the artifact an examiner reads. It is a per-output, hash-chained, append-only record that attests one thing: this output is reproducible from these inputs by this model. It is also, deliberately, the thing that refuses to attest the one thing no honest system can: that the output was correct.
BR-842 is the manifest spec. It is per-output — one manifest per decision, not one per model — because the unit of audit is the decision, not the system. It is hash-chained, so the fields link to each other and to the chain of NodeVersions that produced the inputs. It is append-only, so a manifest cannot be edited after the fact without breaking. Together, those three properties are what make the manifest the artifact that answers can you show your work with a record instead of a narration.
The fields
The manifest carries the model identity (hash-pinned, not named — a model swap does not invalidate the historical record), the input NodeVersions (L1 to L4 refs, hash-chained into the GNL), the prompt template id and generation config (what was asked and how), the agent trace (which of the 23 A2A agents participated, CRDT-merged), the output bytes and timestamp (what came back, signed), the replay anchor (a hash that lets a third party reproduce the computation), and the AxisOverrides if any (typed, recorded, in the chain). Each field answers a question an examiner would ask, before they ask it.
The replay anchor
The replay anchor is the one field that turns a claim into a check. It is a hash that represents the full computation — inputs, model, config, trace — such that a third party with the same model and the same inputs can rerun and compare bytes. A manifest without a replay anchor is a story; a manifest with one is a reproducible computation. That is the field an examiner uses to verify, not to read. Can I reproduce this is answered by running it, not by trusting the manifest.
The replay anchor turns a claim into a check. A manifest without one is a story; a manifest with one is a reproducible computation.
- Model identity, hash-pinned — a model swap does not invalidate the historical record.
- Input NodeVersions, hash-chained — the exact versions the model read, still in the chain.
- Replay anchor — a hash that lets a third party rerun the computation and compare bytes.
- Agent trace, CRDT-merged — which of the 23 agents participated, in what merge order.
The one thing it refuses to assert
The manifest attests provenance and reproducibility. It does not attest truth. There is no field that says this output was correct, and there will not be one. Certified is not True is not a marketing line; it is the boundary the manifest is built around. The refusal to certify truth is what makes the certification of provenance credible — because the manifest is not overclaiming, the fields it does attest are the ones it can actually guarantee. An examiner who asks do you certify this is correct gets an honest no, and an honest here is how it was produced, which is the question you actually need answered.
Per-output, not per-model
A model card describes a model; a manifest describes a decision. The unit of audit is the decision — the specific output a regulator asks about — and a per-model artifact cannot answer per-output questions without a reconstruction. The manifest is per-output because the question is per-output: which model, which inputs, which trace produced this specific forecast on this specific date. A per-model card averages over decisions; a per-output manifest points at one. That is why the manifest is the artifact an examiner reads, and the model card is the artifact a reviewer reads. They are different artifacts for different questions, and BR-842 is the per-output one.
What runs vs what is gated
The manifest substrate is built: the chain, the fields, the replay anchor, the override recording. What is gated is the accuracy claim the manifest explicitly does not make. Gate 1 is the reproducibility gate — the full-chain-walk that verifies the bytes match. Gate 1b is the calibration gate — a shadow run must beat a disclosed baseline on one forecastable series before any forecast side is positioned as accurate. The manifest is the record; the gates are what earn the words on it. We are pre-revenue, building the POC; the manifest is built, and the gates are the ones the accuracy claim waits behind.
The manifest certifies that the computation is reproducible. It does not certify that the output was correct. The first is a property of the substrate; the second is a promise no honest system keeps — and the refusal to make it is what makes the first credible.
— BR-842 spec note