Skip to content

Documentation is not evidence

Most “AI governance” is documentation: a policy PDF, a control spreadsheet, a screenshot of a dashboard, a vendor questionnaire. All of it describes what your system is supposed to do. None of it proves what your system actually did on any given request. That gap is where audits, incidents, and legal discovery go wrong.

DocumentationEvidence
”We filter PII.""On request 7a3f…, the PII control ran and flagged 2 spans — here is the signed receipt.”
A policy documentA cryptographic record produced by the act of enforcement
Trust the operator’s wordVerifiable by a third party who distrusts the operator
Can be written after the factBound to the moment of execution, tamper-evident

Documentation answers what should happen. Evidence answers what did happen — and lets someone else check it.

  • Audits want proof a control ran on the transactions in scope, not that a policy exists.
  • Incidents require knowing exactly what the AI did, in order, with integrity you can defend.
  • Regulators and insurers increasingly want claims that are quantified and reproducible, not attested by questionnaire.
  • Procurement is slow precisely because buyers can’t independently verify vendor claims.

A screenshot can be staged. A policy can be aspirational. A signed, chained receipt over the actual decision cannot be quietly rewritten.

Evidence is produced as a byproduct of execution — “attestation by construction”:

  1. A governance decision happens on the runtime path (enforce).
  2. The decision is signed (Ed25519 over RFC 8785 canonical bytes) and chained (RFC 6962 shape) — tampering becomes detectable.
  3. The receipt carries hashes and line-ranges, never your raw data — so proof can leave even when data can’t.
  4. Anyone can verify it offline, without trusting the issuer.

This is what the OVERT standard specifies and what OVERT-as-Code lets you declare.