oneproof.dev
home · the deposition test

The deposition test

A buyer's checklist for AI evidence. A companion to logs are testimony, not evidence — 8 September 2026.

Most AI-governance tools are bought on a sunny-day demonstration: the dashboard is green, the audit trail scrolls convincingly, the reports export to PDF. None of that is the test that matters. The test that matters is the rainy day — the moment an auditor, a regulator, an insurer, or a disputing counterparty asks what a system did and on what basis, and will not accept your account of it as the answer.

Call it the deposition test. Imagine the record you keep today being handed to someone who distrusts both you and the software that produced it, with instructions to check it themselves. What survives that handover is evidence. What does not is testimony wearing an evidence badge.

Here is what to ask a vendor — or your own platform team — before you rely on the answer. None of these questions is about features. Each is about whether a claim survives someone who has no reason to be generous.

1

Can a third party verify a record without calling you?

Ask for the exact procedure by which an outside party checks one record — one decision, one answer — using only what you would hand them. If the procedure at any point requires your API, your database, your login, or your cooperation, then the evidence is your service, not the record. A service can be decommissioned, migrated, or simply disbelieved. The good answer a file you can export, plus a public reference point, plus a check anyone can run offline. The tell "you'd log into our portal."

2

Is the record bound to the action, or only to the session?

Ask whether the record ties to this specific action, with these specific parameters, authorised for these specific reasons — or only to "this agent was allowed to operate here." Fraud and error that happen inside a valid session, through approved channels, are invisible to session-level records, and that is precisely where the loss sits. The tell the demo shows roles and scopes, not per-action decisions.

3

Does the record carry what produced the decision — not just the decision?

Ask which policy version was in force, which model and configuration actually ran (not which was configured), and what the inputs were as received. A verdict without its causes tells you an incident happened without telling you whether it recurs. "Why did this look correct at the time" is almost always the real question. The tell the record shows the outcome and a timestamp, and nothing about the state that decided it.

4

Can the answer be re-derived, or only re-run?

Ask what happens when someone tries to reproduce a result a year later, after the model is deprecated and the pipeline rebuilt. Re-running is a new measurement with a new instrument; it can disagree with the original for reasons unrelated to what actually happened. Evidence is re-derivable from the sealed record; it does not depend on the live system still existing in its original form. The tell "we'd just run it again."

5

Does absence mean something definite?

Ask what a missing record proves. If a gap might mean the action never happened, or might mean logging failed, or might mean something filtered it downstream, then the presence of records proves little either. The good answer the system can say, of a given action, that its silence is itself a recorded fact. The tell "we'd have to look into why it's not there."

6

Where does the check live — and who can change it?

Ask where the logic that decides whether a record is self-consistent actually runs. If the rule for checking the data lives only in the vendor's codebase, the counterparty can read your fields but cannot check them. Evidence travels with its own verifier, or with a written specification precise enough that a second party can build one. The tell the data is exportable but the meaning of it is not.

7

Are cryptographic guarantees on by default, or described in the brochure?

Ask which protections — signing, tamper-evidence, independent anchoring — are actually engaged in your configuration, versus available in principle. A default you did not deliberately turn on is not a guarantee you hold. The tell the security page lists capabilities without saying which are active for you.

8

When a check fails, how many answers can it give?

A verifier that can only say "valid" is a decoration. Ask whether it distinguishes verified, contradicted, and could-not-check — and confirm that a corrupted download is reported as unreadable, not as a failed record. Telling a counterparty their evidence is bad when what is bad is their copy of it is the most expensive error the whole system can make. The tell a single green tick, and no vocabulary for the other outcomes.

How to run the test in a procurement conversation

Take one real decision the system made last week. Then:

  1. Ask the vendor to produce the record for it and hand you the files.
  2. Ask for the procedure to confirm — on your own laptop, with their software uninstalled — that the decision was authorised under the policy that was in force at the time.
  3. Change one byte of the file, and confirm the check notices.

If that exercise can be completed, you are buying evidence. If it cannot, you are buying a more elaborate way to give testimony — which is fine for operations, and worth exactly nothing on the day the question is external.

This is not a counsel of distrust. It is the recognition that trust does not survive scale, staff turnover, and an outside party with no reason to extend it — and that the record is what remains when the people who could vouch for the system have moved on.