Runtime proof · OVERT
AI Governance Solutions Need a System of Proof
Most AI governance solutions are a system of record for intent. Add a system of proof — signed runtime receipts that show the control actually ran.
Most AI governance solutions are excellent at one thing: holding the intent. They store the policy, route the approval, track the risk register, and render a dashboard that says the control exists. That is real work, and it matters. But it is a record of what ought to happen — not evidence of what did. When an auditor, a regulator, or your own incident-response lead asks the harder question — did the control actually run, and can you show it independently — the dashboard goes quiet. This is the gap the next generation of AI governance solutions has to close, and it closes from underneath: with a system of proof.
This is not an argument to replace your governance platform. It is an argument to make its record honest.
The quiet gap in most AI governance solutions
Governance has always been able to say what ought to be done. It has rarely been able to prove what was. Policies, audit narratives, and self-reported logs record intentions and recollections — they are not evidence.
That distinction is easy to wave past in a procurement deck and impossible to wave past in a post-incident review. A control that is configured in a console is an assertion. A control that fired, on a specific request, with a specific configuration active, and left behind a record an outside party can check — that is evidence. Most AI governance solutions live almost entirely on the assertion side of that line. They tell you a guardrail is enabled; they cannot independently demonstrate that it engaged at the moment a model made a decision it should not have made.
The reason is structural, not lazy. Governance tooling sits above the runtime. It reads the policy, not the execution. So it inherits a blind spot: everything it knows about enforcement, it learns from logs the operator controls — and operator-controlled logs are exactly what an independent reviewer is trained to distrust.
System of record vs system of proof
The cleanest way to frame this is the distinction between a system of record and a system of proof.
A system of record is the authoritative home for a kind of intent. Your AI governance platform is the system of record for policies, risk classifications, approvals, model inventories, and control mappings. It answers what should be true. It is the right place to manage that, and you should keep it.
A system of proof answers a different question: what was demonstrably true at runtime? It does not hold opinions about policy. It holds tamper-evident artifacts — signed records that a particular enforcing component, in a particular configuration, handled a particular governed action and produced an outcome an outsider can verify. It is silent about everything it need not disclose, and load-bearing about the one thing that matters: the event happened, and here is the receipt.
These two layers are complementary, not competing. The system of record states the control. The system of proof shows the control ran. Put them together and the governance narrative stops being a story you ask people to trust and becomes a claim anyone can check. That is the upgrade — not a new dashboard, a new substrate under the dashboard you already have.
What “proof” actually means here
“Proof” is a word vendors abuse, so it is worth being precise. A system of proof for AI is not a richer log and not a prettier report. It rests on four commitments, and each one is testable:
- Evidence, not assertion. A governed action yields a receipt a third party can check — not a claim it is asked to trust.
- Containment by construction. Only cryptographic fingerprints and signatures cross the boundary; the protected content stays in your environment. Proof should never become a new way for sensitive data to leak.
- Independence by structure. Whoever attests is separate from whoever is governed. Self-attestation is not independent attestation, no matter how good the logging is.
- Measurement, not adjective. Safety expressed in intervals and sample sizes an auditor can reproduce — not in the word “robust.”
The fourth one quietly disqualifies most of what gets sold as AI assurance today. “Comprehensive coverage” is an adjective. “These enforcement points were in scope, these were excluded, and here is how the denominator was derived” is a measurement. A system of proof deals only in the second register.
Runtime coverage: where proof is actually generated
Proof cannot be retrofitted from a policy document. It has to be produced at runtime, as a by-product of the control doing its work. That is the motion that matters — runtime coverage — and it has a specific shape.
Controls enforce at the points where an AI system actually acts: the inference call, the tool call, the agent boundary. At each of those points an enforcing component permits, denies, overrides, or escalates — and as it does, it emits a signed record of the decision. The record names which component and configuration were active, what was in scope, and what the outcome was. Crucially, only hashes, signatures, and verification metadata cross the boundary. The prompt, the patient record, the trade, the customer data — none of it leaves. You get independent verification of the enforcement event without turning attestation into a fresh egress channel.
This is the practical answer to the questions mature security and risk teams keep hitting:
- Which control was actually live when this agent took that action? — trusted execution evidence.
- What was in and out of scope, and how was that boundary drawn? — reliable coverage accounting.
- Can these records be trusted if the operator’s own logs are in question? — tamper-evident telemetry that is not reducible to operator-controlled logs.
- Can we reconstruct the event history after an incident without dumping protected content into the review? — post-incident reconstruction without routine data disclosure.
A governance dashboard can describe the intent behind every one of those. Only runtime coverage can produce the artifact that settles them.
An open standard, so the proof outlives the tool
There is a failure mode worth naming: proof that only one vendor can generate and only that same vendor can check is not really independent — it is a second assertion wearing a lab coat. Verifiable AI only works if the verification is open.
That is why the receipts here are produced against an open standard — OVERT — published under a royalty-free patent covenant at overt.is and /standard. It defines, in the open, how a runtime control emits a record that any third party can verify, with the protected data staying home. The 1.1 release is additive and backward-compatible: an implementation conformant to 1.0 stays conformant to 1.1 unmodified. Among its supplementary requirements, version 1.1 adds an HTTP transport binding for cross-boundary attestation and an automated auditor-discovery protocol — the plumbing that lets an outside verifier check an enforcement event without ever touching your content. The point of putting it in a standard rather than a product is durability: your evidence should not depend on your relationship with a single supplier.
For a head of AI governance choosing platforms, this reframes the buying question. The right question is no longer “which AI governance solutions have the most features?” It is “which layer is my system of record, which layer is my system of proof, and do they fit together?” A governance platform that is honest about being the record — and that can sit on top of an open proof layer — is worth more than one that quietly pretends the record is the proof.
Coexistence, not replacement
None of this makes governance documentation obsolete. The policy still has to exist before anything can be measured against it. The risk register still has to be maintained. The approvals still have to be routed. Your AI governance platform remains the system of record, and it should.
What changes is what sits underneath it. Today, in most stacks, the answer is: nothing — the record points at logs the operator controls, and the chain of trust quietly ends there. A system of proof closes that loop. It takes every control your governance platform asserts and gives it a tamper-evident receipt that an auditor, a regulator, or an insurer can verify on their own terms. The dashboard keeps saying what should be true. The proof layer makes it demonstrable.
That is the whole pitch, and it is deliberately modest: we don’t want to replace your governance record. We want to make it honest.
If you are evaluating where proof should sit under your governance stack, you can get runtime coverage — or check a signed receipt yourself and verify a receipt to see exactly what crosses the boundary, and what stays home.