A proof layer that advertises only its strengths is doing the thing it was built to prevent. Everything below is a real boundary of the current design, not a disclaimer written by a lawyer.
Attestations and receipts are unsigned digests. They detect tampering; they do not resist impersonation. Nothing here proves who issued a receipt — only that its contents have not changed since issuance.
That is deliberate, not an oversight. Keyless verification is what lets anyone check a receipt with a JSON parser and a hash function, with no keys, no network and no trusted third party.
210 of the 608 published cases are inconclusive. They are stated on the receipt, in the report, in the artifacts table, and here. They are not folded into a pass rate and they are not rounded away.
An inconclusive case means the analysis could not responsibly resolve it. Reading it as a pass reintroduces exactly the overclaiming this format exists to make non-conformant.
The source and mock test suite proves the harness behaves as specified. It says nothing about any model's behaviour.
Frontier findings are only the published campaigns on the artifacts page, with their subjects named and their inconclusives attached. Mock and free-tier targets are identified as such, so a receipt cannot imply frontier-class testing that did not occur.
The browser verifier checks what is verifiable from the receipt alone: the profile version, the honest-statistics rule, the digest shapes, the named subject. It confirms the numbers are internally consistent.
It cannot confirm the campaign happened. The issuer's own verification.verified field is a claim, and the profile says so. Only the evidence tier, run against the artifacts, re-derives the result.
The harness does not autonomously submit to bounty programmes. Acceptance is a separate, governed decision, and approving over a failing gate requires an explicit force flag that attaches the failed gates to the record.
The learning loop is not an autonomous redesign engine. It produces flags; humans accept them against gates.
Nothing on this site asserts that a tested system is secure, that an absence of findings is an absence of vulnerabilities, or that a passing campaign transfers to a different deployment, version or configuration.
A campaign is evidence about what happened in that campaign, against that named subject, at that time.
Nothing below exists today. Each item is listed with the condition that would start it, because a roadmap stated as capability is the same overclaiming in a different tense.
| NEXT STEP | GATE |
|---|---|
| Keyed signing of receipts and attestations, SCITT-style | A relying party demands authentication, not just tamper detection |
| Receipt media-type registration with IETF | The draft is submitted and cited |
| Working-group adoption or standards track | The receipts wave consolidates, or a WG asks |
| Frontier expansion — more models, more technique classes | The spend cap holds and the acceptance gates stay honest |
The IETF draft is prepared and idnits-clean. It has not been submitted. Media-type registration is gated on that submission, and this page will say so until it changes.
An evaluator that cannot show its own error bars is not evidence-grade either. The learning loop records critic overturn rates, rejection-reason feedback, redesign flags against technique classes, and judge calibration.
Where an acceptance was forced over a failing gate, the forcing and its reason are on the record rather than smoothed out of it.
Every number on this site is derived from a published bundle, and every published campaign links the receipt behind it. If a count does not reconcile, the verifier will say so about our receipts exactly as readily as about anyone else's.