Navigation
What We AreThe BrainPortfolioThe Lab's LabBuilt For YouThe WhiteboardServices & Prices
Let's Talk →
← The Whiteboard

What is the Replay Test?

One question that separates an AI system from a demo with error handling. It takes about a minute to apply and most production systems fail it.

The Replay Test is a single question you apply to any AI-touching capability. Can you rebuild the answer without calling the model? If not, you don't have a system. You have a demo with a try/except around it. A capability passes if, given the stored record alone, you can reproduce the output byte-for-byte six months later without a network call to a provider. It fails if reproducing the answer requires asking the model again and hoping.

Ross Jones — Founder, The Hopium Lab. Last modified 21 July 2026.

Engineering commentary, not legal advice. I apply this to my own systems before they carry anything that matters.

Why does reproducibility matter more than accuracy?

Because accuracy is a claim and reproducibility is evidence, and only one of them survives an argument six months later.

An inaccurate answer you can reproduce is a bug: you can find it, explain it, fix it, and show the auditor exactly what happened and when. An accurate answer you cannot reproduce is a coincidence you are relying on. When somebody asks why the system made that decision in March — and in a regulated context somebody will — "the model said so" is not an answer, and re-running the prompt today gives you a different output from a different model version against different retrieved context.

Accuracy is a claim about the past. Reproducibility is the only mechanism that lets you defend it.

What does passing actually require?

Passing requires that everything which influenced the output is captured before the output is produced, not after.

In practice that means five things. The input is hashed as received, at the trust boundary, before any normalisation touches it. The model identifier and version are recorded as fields, not inferred. The prompt is stored by content hash rather than by template name, because templates change. Retrieved context is captured as it was retrieved, not re-fetched later from a corpus that has since been reindexed. And the output is committed at generation, before redaction or formatting rewrites it.

Do that and the record is self-sufficient. Miss any one and you have a log that describes a decision without being able to reconstruct it — which is the most common shape of AI logging I encounter, and it looks completely fine until the day it matters.

What fails the test, and how badly?

Most production AI fails it, and the failures sort into three tiers.

What you haveReplay resultWhere it hurts
Output stored, prompt not storedCannot rebuild at allYou cannot explain any past decision. Total failure.
Prompt stored by template nameRebuilds the wrong thingThe template changed in April. You reconstruct a decision that was never made — worse than having nothing, because it looks authoritative
Prompt and inputs stored, retrieval not capturedRebuilds sometimesPasses in testing, fails on exactly the records where the corpus has changed — which are the contested ones
Everything captured, model version driftingRebuilds with caveatsDefensible if the version is recorded. Indefensible if it is not
Full capture, deterministic replay proven on a schedulePassesYou can answer the question

The second row is the one worth staring at. Storing prompt_template: "risk_assessment_v2" feels like diligence. It is worse than storing nothing, because a reconstruction that silently uses today's template produces a confident, wrong account of what happened — and hands it to whoever asked.

Doesn't temperature zero solve this?

No, and this is the most common wrong answer in the field.

Setting temperature to zero and pinning a seed reduces sampling variance. It does not make the system reproducible, because the model weights can change underneath you, the provider can route you to a different serving stack, floating-point non-determinism exists on GPU inference, and none of that is under your control or visible to you. People discover this, report it, and are told to set a seed — which they already did.

The layer is wrong. You do not make the model deterministic. You make the system deterministic around a non-deterministic component. The model is allowed to be a coin flip, provided you recorded which way it landed, what it was asked, and what it could see when you asked.

Temperature zero is a request. An append-only record is a guarantee. Only one of them still works when the provider changes something they never told you about.

Which capabilities have to pass?

Not all of them, and pretending otherwise is how this becomes an unaffordable programme nobody finishes.

Apply one question per capability: does a wrong answer here cost money, credentials, an audit finding, or somebody's trust? If yes, it must pass, and the model may only propose — never compute. If no, it can stay probabilistic and unlogged, and you have saved yourself the expense.

A drafting assistant that suggests wording to a human who then edits it does not need to pass. A capability that scores an application, prices a contract, flags a temperature excursion, or decides what a person is shown does. The split is usually far smaller than teams expect: in most systems I have looked at, fewer than a fifth of the AI-touching capabilities genuinely need to pass, and nobody had ever written down which fifth.

Writing that list down is most of the value. A capability that cannot declare which side of the line it sits on has not been designed yet — it has been assembled.

How do you run it?

Take your riskiest capability and try to rebuild last month's output from what you stored. Not from the live system — from the record.

THE REPLAY TEST — one capability, thirty minutes
The Hopium Lab · v1.0 · 21 July 2026

Pick a decision this system made at least 30 days ago. Then, using ONLY
the stored record and no call to any model provider:

[ ] Can you retrieve the exact input as it arrived?
[ ] Can you retrieve the exact prompt sent, by content, not by name?
[ ] Can you retrieve the retrieved context as it was at that moment?
[ ] Can you identify the model and version that answered?
[ ] Can you produce the output byte-for-byte?
[ ] Can somebody who does not work here verify all of the above?

Six yeses: it passes. Five: it does not. There is no partial credit,
because the missing one is the one you will be asked about.

The last box is the one people skip and the one that matters most. A record only you can verify is not evidence, it is an assertion — and the whole point of the exercise is to be able to hand somebody else the proof.

Most teams run this and discover the answer is no. That is a useful morning. The alternative is discovering it during an incident review, with a lawyer in the room.

Ross Jones, Founder, The Hopium Lab. Last modified 21 July 2026. The Replay Test is also sold as a fixed-price engagement — but the question above is free and you should run it yourself first.