Closing the AI Evidence Gap

Introduction

While The AI Evidence Gap focuses on why this gap exists, this article outlines a technical framework to close it.

As AI systems become increasingly involved in decisions with legal, financial, operational, and societal consequences, a fundamental question emerges:

How do we independently verify what happened?

Most AI systems today rely on provider-controlled logs, internal investigations, and post-hoc explanations. These mechanisms may be useful, but they share a common limitation: they depend on trusting the organisation that generated them.

This is the challenge described in The AI Evidence Gap.

The issue is not whether providers act in good faith.

The issue is whether independent verification is possible.

Mature industries have long recognised this distinction. Aviation uses flight recorders. Financial systems maintain tamper-evident transaction ledgers. Security teams rely on chain-of-custody records and forensic evidence.

AI systems increasingly influence important decisions, yet the AI Evidence Layer remains largely missing.

This article outlines the technical properties required for verifiable AI evidence and presents a minimal receipt-based architecture capable of satisfying those requirements.

The Requirements

Any evidence system intended to support AI accountability should provide five core properties.

Together, these properties transform an interaction record from a log into evidence.

Why Traditional Logs Are Not Enough

Many organisations already maintain audit logs.

The challenge is that traditional logs answer the question:

What was recorded?

Evidence systems answer a stronger question:

Can the record itself be independently trusted?

Traditional logs are typically controlled by the same organisation operating the system being audited.

They may be protected, archived, replicated, and monitored, but they remain fundamentally dependent on the operator.

A verifiable evidence architecture aims to reduce that dependency by making tampering evident and verification independent.

The goal is not to eliminate trust entirely.

The goal is to reduce the amount of trust required.

A Minimal Receipt-Based Architecture

One approach is to represent each AI interaction as a compact cryptographically signed receipt.

Each receipt records evidence about a specific interaction while allowing the underlying content to be stored separately.

A simplified example might look like:

{
  "version": 1,
  "timestamp": "2026-06-13T10:30:00Z",
  "agentId": "did:example:model",
  "tenantId": "did:example:org",
  "sessionId": "550e8400-e29b-41d4-a716-446655440000",
  "sequence": 7,
  "promptHash": "sha256:a1b2c3...",
  "responseHash": "sha256:d4e5f6...",
  "previousHash": "sha256:7g8h9i...",
  "principleScores": {
    "transparency": 0.94,
    "accountability": 0.97
  },
  "signature": "ed25519:base64-encoded-signature-bytes"
}

The same flow, in plain text:

Prompt
  │
  ▼
AI System
  │
  ▼
Response
  │
  ▼
Trust Receipt
  ├── Hashes
  ├── Signature
  ├── Metadata
  └── Timestamp
  │
  ▼
Independent Verification

Each field contributes a specific property of the evidence chain.

Prompt and Response Hashes

The prompt and response themselves may be large, sensitive, or subject to privacy requirements.

Instead of storing the content directly within the receipt, cryptographic hashes are recorded.

A hash acts as a unique fingerprint.

If even a single character changes, the resulting hash changes.

This creates a binding between the receipt and the original content while allowing the content itself to be stored separately.

Chain Continuity

The “previousHash” field references the preceding receipt.

In plain text:

Receipt 1
  hash:          H1
         │
         ▼
Receipt 2
  previousHash:  H1
  hash:          H2
         │
         ▼
Receipt 3
  previousHash:  H2
  hash:          H3

This creates a cryptographic chain linking interactions together.

Removing, inserting, modifying, or reordering records becomes immediately detectable because the chain no longer validates.

Identity

The “agentId” identifies the system, model, or agent responsible for generating the interaction.

This identifier can be linked to a public verification key, allowing third parties to verify origin without relying on a central authority.

Tenant and Principle Scores

The “tenantId” identifies the organisation or deployment context the agent was operating within — useful when a single provider runs the same underlying model on behalf of many customers.

The “principleScores” field records how the interaction scored against a defined set of governance principles — for example, transparency or accountability — at the moment the response was generated.

This is where a governance framework stops being a separate claim and becomes part of the evidence itself: not “we have a policy,” but a signed record of how this specific interaction measured against it.

Signatures

The receipt is digitally signed using a private key.

Anyone possessing the corresponding public key can verify that the receipt was produced by the expected party and has not been altered.

This provides authenticity and non-repudiation.

In the example above, the “ed25519:” prefix denotes the signature scheme; the remainder is the base64-encoded signature itself.

Key management follows standard cryptographic practice: private keys are held only by the signing entity, protected accordingly, and rotated according to policy.

Verification Without Trusting the Operator

The most important characteristic of a receipt-based architecture is that verification does not require trusting the operator's account of what happened.

To verify a receipt, a third party requires only:

1. The receipt itself
2. The original content (if hash validation is required)
3. The associated public verification key

Verification then becomes a straightforward process:

1. Recompute the prompt and response hashes from the content.
2. Confirm they match the values recorded in the receipt.
3. Validate chain continuity using the previous hash.
4. Verify the digital signature using the public key.

If all checks succeed, the interaction can be independently validated.

No special access is required.

No provider approval is required.

No internal investigation is required.

Verification becomes a property of the evidence itself.

Two forms of trust remain, and naming them matters.

The first is trust in key custody. If a private key is compromised, an attacker could produce signatures that appear authentic.

The second is trust in completeness. A hash chain proves that no recorded receipt has been altered or reordered. It cannot, on its own, prove that no receipt was ever omitted.

Independent timestamping, covered below, addresses completeness by anchoring each receipt's existence to a public record at the time it is created.

This architecture does not eliminate trust. It narrows it to two specific, addressable points — and makes everything else independently verifiable.

Multi-Party Verification

The value of this architecture becomes more apparent when multiple parties are involved.

Consider a dispute involving:

• A model provider
• A customer
• A regulator

Each party may hold different information.

The customer possesses the original prompt.

The provider possesses system metadata.

The regulator possesses compliance requirements.

Today, these parties often rely on separate records and competing interpretations.

A receipt-based architecture allows all participants to independently validate the same interaction without requiring any single party to become the source of truth.

The evidence becomes portable.

Verification becomes shared.

Optional: Independent Timestamping

Hash chains establish ordering, but they do not independently establish absolute time.

For situations involving legal deadlines, regulatory reporting, or evidentiary requirements, additional timestamp assurance may be desirable.

One approach is decentralised timestamping.

A receipt hash can be anchored into a public blockchain using systems such as OpenTimestamps.

The process is simple:

1. Compute the receipt hash.
2. Submit the hash for timestamp anchoring.
3. Receive a proof linked to a publicly verifiable blockchain record.

This creates evidence that the receipt existed no later than the timestamp represented by the blockchain entry.

Importantly, the content itself never needs to be published.

Only the cryptographic proof is anchored.

Privacy Considerations

A common concern is that AI interactions may contain sensitive information.

Receipt-based architectures address this by separating evidence from content.

The receipt contains only metadata and cryptographic fingerprints.

The actual content can remain:

• Encrypted
• Stored on-premises
• Retained under existing governance controls
• Deleted according to policy requirements

Verification occurs when both the content and receipt are available.

This allows organisations to maintain privacy while preserving evidentiary integrity.

Performance and Cost

The cryptographic operations involved are lightweight.

Hashing and signature generation typically require milliseconds.

Receipt records are small — typically around 1–5 KB, depending on schema version, telemetry, and content mode.

For large-scale systems, receipts can be batched or anchored periodically rather than individually.

As a result, the cost of establishing verifiable evidence is generally negligible compared with the operational cost of modern AI systems.

Relationship to Governance Frameworks

Receipt-based evidence systems are not replacements for governance frameworks.

They complement them.

Governance frameworks define responsibilities, controls, oversight processes, and risk management expectations.

Evidence systems help demonstrate that those controls operated as intended.

The integrity, provenance, auditability, and accountability objectives commonly found in frameworks such as ISO 27001, ISO 42001, NIST guidance, and emerging AI regulations are strengthened when supported by independently verifiable evidence.

Controls reduce risk.

Evidence helps prove what happened.

Both are necessary.

From Governance to Accountability

Much of today's AI governance conversation focuses on prevention.

Policies. Reviews. Testing. Monitoring. Human oversight.

These mechanisms matter.

But every mature industry eventually discovers that prevention alone is insufficient.

Failures occur.

Disputes arise.

Investigations happen.

When they do, evidence becomes essential.

The future of AI accountability will require more than assurances that controls exist.

It will increasingly require evidence that those controls were applied.

The technical building blocks already exist.

Cryptographic signatures. Hash chains. Independent verification. Decentralised timestamping.

The challenge is no longer whether verifiable AI evidence is technically possible.

The challenge is whether organisations choose to adopt it.

Those that do will not need to ask counterparties to trust their systems.

They will be able to prove what happened.

The transition from logs to evidence may prove as important for AI as the transition from paper records to digital ledgers was for finance.