AI Decision Evidence

Cryptographic Evidence
for AI Decisions

The evidence layer for AI decisions. EVE Proof turns every governed AI decision into a signed, independently verifiable certificate. Not a log you have to trust — a cryptographic record an examiner can verify themselves, offline, years later, without ever calling us.

Ed25519 signatures · Offline verification · Merkle-anchored audit chains

Ed25519
Asymmetric signing in production
100%
Offline-verifiable certificates
Art. 12/15
EU AI Act record-keeping design
Replay
Decisions reproducible from evidence
Signed Decision Certificates

Every decision leaves a tamper-evident receipt

When the governance layer allows, blocks, or modifies an action, EVE Proof emits a Governed Decision Certificate — a structured, canonicalized record of the inputs, the policy that fired, the verdict, and a cryptographic signature over the whole payload.

📄

Structured & canonical

Each certificate is JCS-canonicalized (RFC 8785) so the exact bytes that were signed are reproducible. No ambiguity about what was attested.

🔑

Signed at issue

The verdict, policy id, request digest, and timestamp are signed the moment the decision is made — bound together so a single altered field breaks verification.

🔗

Hash-chained

Certificates link to the prior record by hash. Removing or reordering a decision is detectable: the chain no longer validates.

governed_decision_certificate.jsoneve.decision.certificate.v1
// A signed receipt for one governed decision
{
  "certificate_id": "gdc_8f31a0c4e9b7",
  "issued_at": "2026-06-20T14:08:21Z",
  "tenant_id": "org_acme",
  "policy_set": "lending_v1",
  "request_digest": "sha256:5c1f…a902",
  "decision": "BLOCKED",
  "reason_code": "ECOA.adverse_action.unexplained",
  "prev_hash": "sha256:0b77…1e4d",
  "signature": {
    "alg": "ed25519",
    "key_id": "eve-prod-2026",
    "value": "f3a1…b9c0"
  }
}
Anatomy of a Certificate

What each field proves — and what it deliberately omits

FieldWhat it isWhat it proves
certificate_idStable, unique id for this decision record.A durable handle an examiner can reference and re-request.
issued_atUTC timestamp, signed inline.When the decision was made — back-dating breaks the signature.
tenant_idThe organization the decision belongs to.Tenant isolation: evidence is scoped and cannot be cross-attributed.
policy_setThe named, versioned policy that evaluated the action.Exactly which rules were in force — the basis for replay.
request_digestSHA-256 digest of the request payload.Binds the decision to its inputs without storing raw or sensitive data.
decisionThe verdict: ALLOWED · BLOCKED · MODIFIED.The governed outcome that actually reached the world.
reason_codeStructured, citable reason for the verdict."Why," decided before the action — not a post-hoc rationalization.
prev_hashHash of the prior certificate in the chain.Tamper-evidence: removing or reordering a decision breaks the chain.
signatureEd25519 signature, algorithm, and key id.Authenticity and integrity, verifiable with the public key alone.
Logs vs. Dashboards vs. Cryptographic Evidence

Why "we keep logs" isn't proof

A log asks others to trust it. A dashboard shows you a claim. Only independently verifiable evidence answers the examiner's real question — without you in the loop.

The examiner asks…Audit logGovernance dashboardCryptographic evidence
"Was this record altered?"Trust the database.Trust the vendor's UI.Verify an Ed25519 signature — any change breaks it.
"Can you prove it without your help?"No — needs your systems and cooperation.No — needs your login.Yes — public key + stock crypto, offline.
"Why was this decision made?"Maybe a free-text note.A score or a status.A signed reason code + policy version, decided before the action.
"Will it survive your company?"Gone if the system is.Gone if the login is.Verifiable years later, with no vendor.
"Prove this exact decision is in the record."Hope nothing was deleted.Take the dashboard's word.A Merkle inclusion proof anyone can check.

The difference is who has to be trusted. With cryptographic evidence, the answer is: no one. See what a certificate contains →

Verification You Control

Verify it yourself — no trust required

Trust is not a feature. EVE Proof is built so the party reading the evidence never has to take our word for anything. Three independent properties make that real.

Ed25519

Asymmetric verification

Certificates, the audit bus, and Merkle roots are signed with Ed25519 in production. Anyone holding the public key can verify a signature — the private key never leaves the signer. Verification needs no secret and no live service.

Offline

Verifiable air-gapped

A certificate, the published public key, and a stock crypto library are all that is required. An auditor can confirm authenticity on a disconnected laptop — today or in seven years — with zero dependency on EVE infrastructure.

Replay

Replay-verifiable decisions

The certificate captures the deterministic inputs and the policy version. Feed them back into the same policy pack and the same verdict and reason code reproduce, every time — proof the recorded outcome is exactly what the engine would decide again.

1

Receive the certificate

From the API response, an exported evidence pack, or your own retained store. It is self-contained.

2

Fetch the published public key

Available at a stable endpoint and pinnable. Key ids are embedded in every certificate so rotation never orphans old evidence.

3

Verify the signature locally

Canonicalize the payload, check the Ed25519 signature against the public key. Valid means the bytes are exactly what was signed at decision time.

4

Walk the chain (optional)

Confirm prev_hash linkage and the Merkle inclusion proof to prove the decision sits, unaltered, in the published audit history.

Try It Live

Verify a real certificate in your browser

Real Ed25519 verification, fully client-side. Press Tamper and watch one altered byte break the signature.

Full-page verifier at eveproof.com/verify · or run the offline Python verifier / open-source eve-verify CLI.

Trust Model

What you have to trust — and what you don't

"No trust required" has a precise meaning. The trusted computing base is small, public, and standard — and we state exactly where it ends.

You trust
  • The authenticity of the published Ed25519 public key (pinnable, key-id bound)
  • Standard cryptography: Ed25519 (RFC 8032) and SHA-256
  • The deterministic policy pack version named in the certificate
You do not trust
  • EVE servers, network, or availability — verification is fully offline
  • Our word, dashboards, or screenshots — the math is checkable
  • Our continued existence — old evidence verifies years later

Scope, stated plainly: a certificate proves a decision was recorded exactly as shown, under a named policy version. It does not, by itself, assert that the policy was correct — that is a separate governance question EVE Governance and your own controls address.

Audit Evidence Packs

One export. The whole story.

An evidence pack bundles every certificate for a window, the hash-chain linkage, the Merkle roots, and the public keys needed to verify them — into a single portable artifact you can hand to an auditor, regulator, or counterparty.

  • Date-ranged or case-scoped certificate bundles
  • Signed Merkle roots with inclusion proofs per decision
  • Embedded public keys + key-rotation lineage
  • Deterministic manifest — verify the pack itself is intact
  • Portable: no EVE service needed to open or check it

Real Ed25519 signatures over RFC 8785 payloads — verify them yourself with the included script (python verify_sample.py). Demo key; identical procedure to production.

Source
Decisions
Signed certificates
Aggregate
Merkle Tree
Batched + rooted
Publish
Signed Root
Ed25519 anchor

An evidence pack carries the leaves, the proofs, and the signed roots — everything an examiner needs to reconstruct trust independently.

Compliance & Examiner Workflows

Built for the person who has to prove it

Examiners, model-risk teams, and auditors don't want a dashboard screenshot. They want records they can independently verify and reproduce. EVE Proof is designed for exactly that conversation.

EU AI Act · Art. 12 & 15

Record-keeping by design

Automatic, tamper-evident logging of high-risk AI decisions with the integrity properties Article 12 anticipates and the accuracy/robustness traceability of Article 15.

SR 11-7 · Model Risk

Independent verification

Model-risk review can confirm what the control did, when, and under which policy version — without relying on the first line's attestations.

Examiner Handoff

Self-service evidence

Hand over an evidence pack and a public key. The examiner verifies on their own machines, on their own timeline. No vendor in the loop.

Who Relies On It

Three teams, one artifact

🔍

Model risk & audit

Confirm what a control did, when, and under which policy version — independently, without relying on the first line's attestations.

Compliance & legal

Hand a regulator or counterparty a self-verifying evidence pack instead of a screenshot. Answer "prove it" with a signature, not a deck.

🔧

Platform & ML engineering

Evidence is emitted inline with the decision — one API call, no separate logging path to build, secure, or remember.

"Show me" should be answerable with math, not marketing. EVE Proof exists so the answer to "how do I know this decision happened the way you say?" is a signature anyone can check.
— The EVE Proof design principle
API & SDK

Issue and verify in a few lines

Evidence is produced inline with the decision — no separate logging step to forget. Verification is a stock-crypto operation you can run anywhere.

issue — HTTPPOST /v1/decisions/evaluate
# Every governed decision returns a signed audit record
curl -X POST https://eveaicore.com/v1/decisions/evaluate \
  -H "Authorization: Bearer eve_…" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "req-001",
    "tenant_id": "org_acme",
    "proposed_action": {"type": "loan_approval", "amount": 50000},
    "policy_set": "lending_v1"
  }'

# → { "decision": { "status": "BLOCKED" },
#     "risk":     { "level": "HIGH" },
#     "audit":    { "signature": "ed25519:f3a1…b9c0",
#                   "decision_trace": [ … ] } }
verify — Pythonoffline, public key only
# pip install eve-governance      # or use stock cryptography directly
from eve_governance import canonicalize
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public key + certificate are all you need — no network
vk = Ed25519PublicKey.from_public_bytes(bytes.fromhex(PUBLIC_KEY_HEX))
payload = canonicalize({k: v for k, v in cert.items() if k != "signature"})

vk.verify(bytes.fromhex(cert["signature"]["value"]), payload)
# raises InvalidSignature if anything was altered
print("✓ certificate is authentic and intact")
replay — Pythonsame inputs → same verdict
import hashlib, json, requests

# 1. the inputs you retained hash to the digest in the certificate
canon = json.dumps(saved_inputs, sort_keys=True, separators=(",", ":")).encode()
assert "sha256:" + hashlib.sha256(canon).hexdigest() == cert["request_digest"]

# 2. re-evaluate under the SAME policy version
r = requests.post("https://eveaicore.com/v1/decisions/evaluate",
                  headers={"Authorization": "Bearer eve_…"},
                  json={**saved_inputs, "policy_set": cert["policy_set"]}).json()

# 3. the verdict reproduces, deterministically
assert r["decision"]["status"] == cert["decision"]
print("✓ same inputs, same policy → same verdict:", cert["decision"])
verify — CLIzero EVE dependency
# Download the sample pack from this page, then:
pip install cryptography
python verify_sample.py eve-proof-sample-certificate.json
# → ✓ gdc_8f31a0c4e9b7: signature is authentic and the payload is intact.

# Tamper test — change one byte and re-run:
# → ✗ BadSignatureError — the payload does not match the signed bytes.
Architecture

Where the evidence comes from

EVE Proof is the evidence plane of the EVE control-plane stack. It sits downstream of enforcement — it cannot change a verdict, only witness and attest it.

Plane 01
Control
Deterministic governance evaluates the action
Plane 02
Enforcement
EVE CoreGuard allows / blocks / modifies
Plane 03
Evidence
EVE Proof signs + chains the certificate
Output
Signed, replay-verifiable, offline-checkable record
Aggregated into Merkle-anchored evidence packs for examiners
FAQ

The questions auditors actually ask

Straight answers to what model-risk, security, and compliance reviewers raise first.

What exactly is signed in an EVE Proof certificate?
The signature covers a canonicalized (RFC 8785) payload that binds together the decision verdict, reason code, policy set and version, a SHA-256 digest of the request, the issuing timestamp, the prior certificate hash, and the signing key id. Altering any one of those fields invalidates the signature.
Can I verify a certificate if EVE NeuroSystems is offline or no longer exists?
Yes. Verification needs only the certificate, the published Ed25519 public key, and a standard crypto library. There is no callback to EVE infrastructure, so an auditor can confirm authenticity on a disconnected machine today or years from now.
What happens to old certificates when signing keys rotate?
Every certificate embeds the key id used to sign it, and evidence packs carry the full key-rotation lineage and historical public keys. Rotating a key never orphans prior evidence — old certificates remain verifiable against the public key that signed them.
Is personal or sensitive data stored in the certificate?
The certificate stores a SHA-256 digest of the request, not the raw payload, plus structured metadata such as the verdict, reason code, and policy version. It is designed to prove what was decided and under which policy without embedding the underlying sensitive data.
Which algorithms and standards does EVE Proof use?
Signatures use Ed25519 (RFC 8032). Payloads are canonicalized with the JSON Canonicalization Scheme (RFC 8785) and digested with SHA-256. Certificates are hash-chained and aggregated into Merkle trees with signed roots.
Can a certificate be forged, back-dated, or altered without detection?
Not without the private signing key, which never leaves the signer. Any change to the payload — including the timestamp — breaks the Ed25519 signature, and removing or reordering a decision breaks the hash chain and Merkle inclusion proof.
What do I actually have to trust?
You trust the authenticity of the published public key and the Ed25519 and SHA-256 primitives — not EVE's servers, network, or word. EVE Proof attests that a decision was recorded exactly as shown; it does not assert that the underlying policy was correct, which is a separate governance question.
How does replay verification differ from signature verification?
Signature verification proves the recorded certificate has not been altered. Replay verification re-runs the certificate's deterministic inputs through the same policy version and confirms the engine returns the same verdict and reason code — proving the recorded outcome is what the engine would decide again.

See a real certificate verify

Issue a live decision certificate and check its signature in your browser — or hand the evidence to your own auditor and watch them verify it without us.

The EVE Control-Plane Stack

One stack. Three properties.