What we publish, and what we don't
We sign receipts about systems we did not build. Until now there was no written rule governing which of them go up. There is one now, and it is this page, because a company selling disclosure should disclose the rule it discloses by.
A rule you cannot check is a claim, not a rule.
So every row below says what we do, and the last section says how to hold us to it without taking our word for any of it.
What publishes by default
| Subject | Published? | Note |
|---|---|---|
| Our own claims, and claims about open-source systems | Yes, by default | The receipts board is this row. We pick the claim, we run it, and the result goes up whichever way it falls. |
| A customer's claim, where the engagement says so | Yes, by agreement | Agreed before the work starts, not negotiated after the result is known. |
| A customer's claim, where it does not | No | We hold the receipt and issue a summary attestation instead. See below. |
| A claim we cannot verify | Yes, as unsupported or error | Unsupported means we could not analyze it; error means the run failed. An unverifiable claim and a failed one are different findings, and both are informative. |
| A correction to a published receipt | A new signed record | Never an edit to the old one. A receipt is content-addressed, so editing it breaks its own hash and the build fails. |
The unsupported/error rows are the ones worth arguing about, so here is the argument. A ledger containing only decisive results is a ledger that has been filtered. Publishing what we could not verify is what makes the rest of it credible.
A signature is not evidence of correctness. It proves the record has not been altered and that our key signed it. It says nothing about whether the finding is right. We keep that line on every page because sliding from signed to true is the exact failure this company exists to name.
What a client gets instead
When a customer's finding stays private, they still get something they can show. A summary attestation is a short signed statement that the work was performed, carrying the headline result and no technical detail. They can give it to a regulator, an underwriter or a prospect without circulating the full report.
This is the audit convention rather than our invention. A SOC 2 report is confidential and NDA-gated, and the restriction is printed by the auditor. What the attestation pattern adds is proof the work happened, which is the part a buyer actually needs to see.
When we can name a client
With their written consent, and never without it. No client list is published by default.
We are not going to pretend this is unusual. Assurance firms do not publish client lists at all. The professional code requires specific client consent before a firm discloses information about a client that is not already public, and engagement letters routinely bar the use of a client's name outright. Naming a client here will always be their choice, made in writing.
When we find something dangerous
We reserve the right to publish a finding of imminent, severe harm, and we will not withhold one for longer than 60 days after telling the client. That window can be extended only if both sides agree and the client is working on a fix.
It is a right, not a promise. Writing "we will publish" would commit us to something we might not be able to follow through on, and a commitment we might break is worse than one we never made. What we can say honestly is that the option exists, that it has a deadline, and that we will exercise it where the harm warrants it.
This is a term of the engagement, stated before signing. A client who agreed to it has agreed to it. That is what makes it a term rather than a surprise.
What we hold back on purpose
A policy that only reserves the right to publish is one-sided, so this one reserves the right to withhold as well. We may hold back material that would foreseeably cause more harm published than withheld. We hold back a subset of attack strings, because publishing all of them would make a claimed fix impossible to verify afterwards. Personal information that turns up during a run stays out.
The larger reserve is the probe set. Publishing a probe is what lets a system be tuned on it, so we hold a private set of items that isn't published anywhere. It holds 6 items as of October 2026. So far it has been run by us against one model, which is a self-assessment rather than a second opinion, and there is no aggregate result to publish yet. When there is one, the number publishes and the items don't.
Where the work runs
In the customer's environment. Nothing leaves the building, and here is the evidence rather than the assurance.
The verifier was already local by default: the system under test runs against a model on loopback, and the in-process path never opens a socket. One component was the entire exposure, the probe generator, and it called an external API unconditionally. Turning it off is a single environment variable pointing at a local model. A test asserts the request that would be sent, inspecting the target and the headers, rather than mocking a response. That distinction is the point. A mocked test proves the code path exists. This one proves where the request goes.
The honest exception. If the system you want verified is a frontier model, verifying it means calling that model. There is no way around it. That is your choice of system, not our architecture, and we would rather say so than sell the guarantee alone.
Why this is tested and not promised.
In May 2026 a sandboxed evaluation run breached three real companies. A harness misconfiguration had granted live internet access. The evaluations were believed to be isolated, and the belief was the vulnerability. Prompt-based assurances of containment are not controls. A test that inspects the request is a weaker claim and a stronger check, and we would rather have the second one.
How to check this page
| Claim | How to check it |
|---|---|
| No fee depends on the verdict | No engagement has ever been priced on outcome, and no success fee exists. The pilot fee is a credit against the engagement and it is the same credit either way. |
| A published receipt cannot be quietly changed | Every receipt is content-addressed and signed. Change one character and the hash stops matching. The build runs the verifier first and exits non-zero when a receipt fails. |
| We publish the unfavourable result | The board carries falsified verdicts, and the rejected set is live and linked. A verifier that only publishes passes has published nothing. |
Our independence is assessed on a separate page, including the seven criteria we currently fail. The structural risk of being paid by the party under verification is named there rather than here, because it belongs with the rest of our conflicts.