Accountable Only When It Is Verifiable

Knowledge Bank · Shelf: Verification & Proof

A deliverable arrives. It might be a code change, a document, an analysis. Someone — a reviewer, a client, a colleague downstream — has to decide whether to trust it. And almost immediately, that decision runs into a structural problem: the only account of how the work was produced is the record the producer keeps. The logs live on the producer's server. The producer can edit them. The producer can regenerate them. The reviewer is asked, in effect, to accept the producer's word about the producer's work, and to call the result accountability.

This is not a new problem, but AI agents have made it sharper. When an agent produces work at volume, the reviewer's window into what happened narrows to whatever the operator chooses to expose. A log entry saying a check passed is not evidence that a check passed. It is a claim. The gap between the two is where trust quietly gets misplaced — not through dishonesty, necessarily, but through the simple fact that a record controlled by one party cannot, by itself, settle a dispute involving that party.

Our position is narrow and we will state it once: accountable can only be when it is verifiable. Not when it is asserted, not when it is logged, not when it is described in a report. When a stranger can check it.

What sealing means, in plain words

Agent Proof is evidence infrastructure built against the provenance problem. In its dogfood stage it issues sealed certificates — so far, only for the operator's own release-gate verdicts. The mechanics matter less than the properties they produce, so here is what a certificate actually is.

Each certificate is canonical JSON — a deterministic serialization, so the same content always hashes the same way. That payload is bound by a SHA-256 hash. The certificate is signed with an Ed25519 key. It is chained by hash to the previous certificate, so removing or reordering one breaks the chain visibly. And it is entered in an append-only transparency log.

The consequence is the point: any stranger can re-verify a certificate without trusting the issuer's server. You do not need our permission, our API, or our goodwill. You need the format specification, the certificate, the log, and the public key. If the payload was altered, the hash fails. If the signature was forged, the signature check fails. If a certificate was removed from the middle of the chain, the chain fails. Verification is a computation the reader performs, not a statement the producer makes.

One framing rule we hold to strictly: a certificate states what was checked and what resulted. It never says a bare "safe." It never promises anything about the sealed work. A certificate that read "this is fine" would be an opinion wearing the costume of evidence. A certificate that reads "these checks ran, these were the findings, this was the verdict" is a fact a stranger can test.

The dogfood record

We built this dogfood-first, which means the first certificates attest the operator's own release-gate verdicts — our decisions about our own products, sealed before anyone outside had a reason to care.

The record: 23 certificates sealed in one hash chain, covering gate verdicts for 19 products and surfaces. Of those verdicts, 22 were PASS WITH FINDINGS and 1 was BLOCKED. All 23 pass a standalone verifier written from the format specification alone — 23/23 verified. The verifier was not built from our codebase; it was built from the written spec, which is the only meaningful test of whether the format is actually verifiable by an outsider.

The BLOCKED verdict is the one worth dwelling on. A log that only carries good news is marketing, not evidence. If the first chain had contained 23 passes and nothing else, a reasonable reader would conclude that the gate either never fires or that failures are quietly excluded. Sealing the BLOCKED verdict into the first chain — putting our own unfavorable outcome into the permanent, chained, independently checkable record — is what makes the passes mean anything. Selectivity is the easiest way to corrupt an evidence system without touching a single hash. The chain is only informative to the extent it is not curated.

The tamper tests

Claims about tamper-evidence are cheap. We ran three deliberate tamper attacks against the sealed record. All three failed verification, as designed. The untouched control verified.

That is the whole result, and it is stated plainly because it is a test of the mechanism, not a proof of virtue. Three attacks is a small number. It establishes that the obvious alterations — the ones any adversary would try first — are caught by the hash, the signature, and the chain respectively. It does not establish that no attack exists. What it does establish is the property that matters for a reader: verification fails when the record is altered, and it fails in the hands of someone who does not trust us.

The limitations, as plainly as the results

The certificates are signed with a labelled dogfood key; no production signing key exists yet. The public verify surface is not built. The submission API is not built. Billing is not built. Revocation is not built. Nothing has been sold. No external certificate has been issued.

We list these in the same paragraph style as the results because they carry the same weight. A certificate system whose verification surface is not yet public is, today, a demonstrated mechanism rather than a service. The 23/23 result was produced by a verifier written from the spec — which is the right test — but that verifier is not yet a public tool any reader can point at a certificate. Until it is, the evidence chain is checkable in principle and by us in practice. We would rather say that than round it up.

What this means for a reader of any research, including ours

The question to carry away is not "is this trustworthy?" It is "what can I re-verify?" Those are different questions, and only the second one has an answer you control.

When you read a claim — ours or anyone's — ask what stands behind it that you could check without the producer's cooperation. Ask whether the record is append-only or editable. Ask whether unfavorable results are in the record alongside favorable ones, or whether the log only carries good news. Ask whether the verification path runs through the producer's server, because if it does, you are back to trusting the party with an interest in the outcome.

For our own part: the certificates exist, the chain exists, the BLOCKED verdict is in it, and the tamper tests failed as they should. The public verify surface does not exist yet, and we will not describe it as though it does. That is the current state of the record — stated so that you can hold us to it, which is the only kind of accountability that means anything.