Verifiable AI evidence

Verifiable evidence for AI decisions.

Trust Standard Protocol gives AI systems a standard way to produce tamper-evident, portable evidence of what happened — so teams, auditors, customers, and regulators can verify the record without trusting the vendor.

A live decision receipt. It verifies with real Ed25519 in your browser; break one byte and the seal fails.
Decision receipt
typecredit.application
issued2026-03-11
issuernorthbank#k2
digestsha256:9c1d…sha256 · mismatch
sig · ed25519: 3kQ2x…a7f0

Verified — the seal holds Failed — one byte changed, the seal broke

offline · real Ed25519

A regulatory stress testDeclarations → evidence

When AI decisions matter, the record has to stand on its own.

AI governance is moving from policy statements to evidence. TSP gives teams a standard way to preserve what happened, bind it cryptographically, and make it independently checkable later.

  • EU AI Act
  • ISO/IEC 42001
  • NIST AI RMF

For teams working with the EU AI Act, DORA, internal controls, procurement reviews, and incident response, the question is no longer only whether a system performs. It is whether the record can be examined, challenged, retained, and trusted after the fact.

The durable advantage is not only capability. It is provability.

See the full regulatory stress test →

The problem · The fix

AI decisions are becoming easier to produce — and harder to prove.

Today

Most evidence stays inside vendor-controlled systems.

Logs, dashboards, and internal audit trails may be useful operationally, but they are difficult for an outside party to verify independently once a dispute, review, or regulatory question appears.

  • Records can be changed, filtered, or reconstructed after the fact.
  • Review depends on internal access, screenshots, or vendor explanation.
  • Counterparties cannot easily reproduce the same integrity result themselves.
With TSP

Runtime events become signed, portable evidence.

TSP turns AI-mediated events into tamper-evident receipts that can be checked independently and offline — giving teams a portable evidence layer for auditability, oversight, investigations, and trust.

  • Tamper-evident: one changed byte breaks the verification result.
  • Portable: the evidence can travel beyond the issuing system.
  • Independently checkable: anyone with the receipt and key can re-run the math.

If an AI system made or supported a decision, the record should be independently verifiable.

How it works

Three steps. Clear boundary. Repeatable verification.

The event is sealed

A TrustEnvelope records the event in canonical form and seals it cryptographically so later changes are detectable.

The record can be anchored

Receipts can be chained and, where needed, independently anchored to strengthen evidentiary posture beyond a self-attested local record.

Anyone verifies

The cryptography can be re-run offline, producing the same integrity result for every verifier.

What you get

Tamper-evident

If the signed record changes, verification fails. Quiet edits do not survive inspection.

Portable

Evidence can move across teams, customers, auditors, and regulators without depending on the issuing vendor's dashboard.

Independently checkable

Verification does not require trust in us or in the issuer — only the published rules, keys, and cryptography.

Why TSP

Four properties that make evidence useful under scrutiny.

Signed receipts

Each event is sealed as a TrustEnvelope — canonical JSON, hashed with SHA-256, signed at the point of issuance.

Portable verification

Anyone can re-run the Ed25519 verification offline. The evidence is not trapped behind an API, account, or vendor workflow.

Reviewable records

The trail stays legible to the people who must assess it — engineering, compliance, audit, procurement, and oversight.

Governed status

Official status is governed separately from technical verification. Payment never grants it, and verification alone does not confer it.

The systems-level view

Three futures for AI evidence.

Every AI deployment is moving toward one of these models. Only one produces portable, independently verifiable records.

Future 01

No proof

Outputs matter, but the evidence trail is incomplete, fragile, or absent.

  • Slow audits
  • Weak buyer trust
  • Difficult incident reconstruction
  • Limited external assurance
  • Higher regulatory exposure
Future 02

Private proof

Each organization builds its own evidence workflow, but verification remains local and non-portable.

  • Better than nothing
  • Fragmented across vendors
  • Hard for outsiders to verify
  • Repetitive audit work
  • Weak interoperability
Future 03 · With TSP

Standardized proof

Outputs carry portable, cryptographically verifiable evidence that different parties can inspect independently.

  • Buyers can verify
  • Auditors can inspect
  • Teams can prove what happened
  • Evidence moves across ecosystems
  • One record, many reviews

The honest boundary

What verification means — and what it does not.

See it for yourself

Watch a receipt break in real time.

This verifier runs entirely in your browser against the issuer's Ed25519 public key. Nothing is uploaded. Change one byte and the verification result fails.

receipt.json — verifyoffline · real Ed25519
Verifying…

Real Ed25519 + SHA-256 · offline verification · no hidden trust in the issuer

The honest line

Soon, AI vendors will not compete only on capability. They will compete on provability.

TSP does not replace legal, governance, or compliance programs. It gives those functions something they often lack: a portable technical evidence layer at the point where outputs are created and reviewed.

And one boundary keeps the system defensible: verification is not truth. A receipt can prove what a system recorded, signed, and declared at a moment in time — not whether the underlying decision was substantively correct or legally justified.

Logs are not proof.
Dashboards are not proof.
Vendor assertions are not proof.
TSP turns AI outputs into verifiable evidence.

Narrow honesty

What TSP covers — and what it doesn't.

Useful systems define their boundary precisely. TSP covers the technical evidence layer; it does not claim to perform the legal, organisational, or adjudicative parts around it.

Covers — the evidence layer

  • Tamper-evident records of outputs, declared sources, and process context.
  • Ed25519 signatures resolving to a published manifest — including key state and verification context.
  • Independent, offline verification with shared rules and conformance fixtures.
  • Technical support for logging, oversight, disclosure, audit, and retention workflows.

Doesn't — by design

  • Make a system legally compliant by itself.
  • Determine whether an output was correct, fair, or lawful.
  • Replace conformity assessment, DPIA, FRIA, or governance programs.
  • Grant official status through payment or self-declaration.

Who uses it

For builders, reviewers, and counterparties who need the record to travel.

Developers

Add a verifiable evidence layer to AI workflows without making verification depend on your own platform.

Compliance

Work from evidence that can be retained, reviewed, and challenged with a clear technical boundary.

Auditors

Inspect a decision trail independently, without relying on screenshots, vendor claims, or internal dashboard access.

Partners

Exchange AI records across organizational boundaries with a shared verification method.

Build for the review that happens after deployment.

Make AI evidence verifiable before a regulator, customer, auditor, or counterparty asks for it. The reference verifier is open and runs offline.