Research

Working paper v0.1, June 2026

Decision Receipts: A Verifiable Primitive for AI Evidence That Survives a Challenge

Aqta Research Team. Aqta Technologies, Dublin.

Summary

A cross-jurisdiction synthesis across seven regulatory frameworks (EU AI Act, EU DORA, NIST AI RMF, Federal Reserve SR 11-7 (superseded by SR 26-2 in April 2026; the synthesis is coded against the SR 11-7 text), UK FCA Consumer Duty, UK ICO under UK GDPR, Singapore PDPC Model AI Governance Framework + AI Verify) shows they converge on the same seven evidence properties. We propose ATTESTATION-v1 as an open specification for the underlying primitive, describe the reference gateway with a published verifying key, and test the primitive against a worked field deployment with full anti-survivorship-bias accounting. The bootstrap reports the W19 hit at p = 0.222; the paper's contribution is the primitive, not a claim of predictive capability.

Read the working paper · PDF, 56 pages. Comments and corrections to hello@aqta.ai.

Cite (plain text)
Aqta Research (2026). Decision Receipts: A Verifiable Primitive for AI Evidence That Survives a Challenge. Working paper v0.1, Aqta Technologies, Dublin. https://aqta.ai/research/working-paper/
Cite (BibTeX)
@techreport{aqtaresearch2026receipts,
  title       = {Decision Receipts: A Verifiable Primitive for AI Evidence That Survives a Challenge},
  author      = {{Aqta Research}},
  institution = {Aqta Technologies},
  address     = {Dublin, Ireland},
  year        = {2026},
  month       = {6},
  type        = {Working paper},
  number      = {v0.1},
  url         = {https://aqta.ai/research/working-paper/}
}

Page last updated 2026-08-12.

Our thesis

The core claim

AI made decisions cheap. Evidence is becoming expensive.

ATTESTATION-v1 is an open protocol; Seal is the reference implementation. Three pillars follow.

01·Cross-provider by construction

A bank or hospital does not run on a single AI cloud. Receipts produced by Seal verify identically whether the model behind the agent was OpenAI, Anthropic, Google, Bedrock, or an on-prem deployment. The audit layer cannot live inside any one vendor's surface.

02·Offline-verifiable against a published key

A regulator, customer, or auditor verifies any receipt against the Ed25519 key that was current when it was signed. The permanent key record at app.aqta.ai/security/issuer-keys.txt lists every issuer key with its validity window; keys rotate, receipts stay valid. The verifier runs offline. No call back to Aqta, no log fetched from any cloud.

03·Open spec, open verifiers

ATTESTATION-v1 is dual-licensed: code Apache 2.0, spec text CC BY 4.0. Reference verifiers ship at parity on PyPI and npm. Every third-party verifier strengthens the primitive instead of deepening dependency on us.

What a verified receipt proves, and against whom. A valid signature proves the receipt was produced by the holder of the issuer key and has not been altered since, and the key record tells you which key was the issuer's when. It does not prove the computation behind the decision ran as described: today the issuer is the root of trust, and Q1 below is the research programme to shrink that assumption. We state this here because pages like this one usually promise more.

Verify the primitive yourself

25/25conformance vectors, two implementations agreeing
751 µsmedian verification, 10k iterations, script published
Apr 2026signing in production since
0network calls during verification

Verify a receipt

Four commands, no account. Once the key and the pack are on disk, nothing calls back to us:

verify a receipt, offline
$ pip install aqta-verify-receipt

$ curl -sL https://app.aqta.ai/security/issuer-keys.txt -o keys.txt

$ curl -sL https://app.aqta.ai/samples/sample-evidence-pack.zip -o pack.zip
$ unzip -oq pack.zip -d pack

$ python <<'PY'
import json
from aqta_verify_receipt import verify_receipt
# The pack's receipt is from 24 Jul 2026: pin the key that was current then.
key = next(l.split()[1] for l in open("keys.txt") if "2026-04-21" in l)
print(verify_receipt(json.load(open("pack/receipt.json")), trusted_public_key=key))
PY

VerifyResult(valid=True, reason=None, key_source='pinned', envelope='ATTESTATION-v1')

The pack holds a receipt the production gateway emitted and signed on 24 July 2026, plus the policy text in force at that moment. The key it is pinned against is fetched separately from the issuer key record at app.aqta.ai/security/issuer-keys.txt, not read out of the zip. Keys rotate; receipts do not: the record lists every signing key with its validity window, permanently, so a receipt always verifies against the key that was current when it was signed. The cryptographic work is 751 µs at the median (signing 238 µs, roughly 4,200 receipts per second per core, measured over 10,000 iterations); the CLI takes about a second because a Python interpreter starts. The benchmark script is published, so the numbers are yours to reproduce or refute. Change one character in pack/receipt.json and the signature stops matching. To sign a receipt yourself in the browser, use aqta.ai/verify, which runs on a separate demo key rather than the production one.

SpecATTESTATION-v1.md · Apache 2.0 / CC BY 4.0 · Aqta-ai/attestation-spec
Internet-DraftThe receipt format is documented as an IETF Internet-Draft, draft-chueayen-attestation-receipts-02 (Informational, individual submission; not adopted by any working group and not a standard). It states what a verified receipt does not prove; the repository documents the relationship to SCITT (RFC 9943) and the neighbouring receipt drafts.
VerifiersPyPI · npm · pinned key required since v1.0.4
Vectors25 cases, both implementations agreeing on every one · test-vectors
Gatewayapi.aqta.ai · key record issuer-keys.txt
Demoapp.aqta.ai/demo · sign, chain-check, verify offline

Selective disclosure preview. BN254 Schnorr verification is live; a Groth16 verifier runs over a fixed demo circuit. Early research, not a shipped feature.

Selective disclosureResearch preview

Prove a property of a receipt without revealing its contents. The button below verifies a Groth16 zero-knowledge proof (BN254, depth-10 Merkle membership) over a fixed demo circuit. Per-request proving for production receipts is in preview.

Verifier live over a demo circuit. Per-request proving is in preview. Roadmap on the research page, section 8.

Where this sits

Neighbouring work

This is a crowded, fast-moving neighbourhood, and the honest map matters more than a category claim. IETF SCITT (RFC 9943, June 2026) defines receipts as proof of registration on a transparency log; ATTESTATION-v1 is a payload-level format for the decision itself, and the repository documents the relationship. C2PA signs provenance for media; sigstore signs artefacts, and since model-signing v1.0, ML model files. Hardware-attested inference has shipped commercially: TEE-based serving now issues per-response attestations, and the hyperscaler trajectory points the same way. Those systems attest the serving environment, and they relocate trust to the hardware vendor's attestation chain rather than removing it. Zero-knowledge proofs of full LLM inference exist in production at small-model scale, and the Hollow-LLM result (arXiv:2607.28884) shows why the binding problem stays open even there: proof of correct inference is not proof of which model did the work. Replication-based verification (TOPLOC, DiFR) binds computation but needs a re-executing verifier. At the IETF, other individual drafts describe signed receipts for machine decisions from different angles.

Our position on this map is deliberately narrow: an open payload format for the decision record, signed in-path before the action, with two independently implemented offline verifiers that agree on every conformance vector, running in production since April 2026. Q1 below is where this map's hardest open problem lives, and it is ours too.

Proof

The dated public artefact

2026-05-09Public git ledger Aqta-ai/aqtabio-research commits commitments/2026-W19.json: DR Congo Ebola at rank 4 of the Congo Basin tiles.
2026-05-17WHO declares a PHEIC for Bundibugyo Ebola in DR Congo and Uganda.
Lead8 days. Biome-correct, country rank 4.
Contextp = 0.222. One match; the bootstrap accounting is in the working paper.
VerifyRead the 2026-W19.json commit history against the WHO declaration date.

The same signing pipeline that produces Seal receipts demonstrates the mechanism on a dated prediction. The primitive does not care whether the decision is a policy call or a forecast.

The ladder

Five questions, in order of difficulty

Evidence about an AI decision is not one property but five, and they stack: each question is only worth asking once the one beneath it holds. Naming where we actually stand on the ladder is more useful than a claim to have solved evidence, so here it is.

IntegrityHas this record been changed? Ed25519 over canonical bytes, hash-chained in sequence, checkable offline. Solved, and demonstrable in the terminal above.
ProvenanceWho produced it, under which identity, under which policy? The receipt carries the issuer key and the policy in force at the moment of the decision; a reviewer arrives with a credential from an issuer Aqta does not control. Solved.
CorrectnessDoes the record correspond to the computation that actually ran? A valid signature does not prove which model executed. The issuer is the trust root today, and shrinking that assumption without paying enclave or proving overhead on every inference is open: it is Q1 below.
CompletenessIs anything missing? Receipts are entered in an append-only log built to RFC 6962, so a monitor can detect a record that was altered or withheld after entry. An operator who never issues a receipt defeats it, and no signature can detect a decision nobody recorded. Partly, and open.
ReviewWhat conclusion did an independent reviewer reach? The reviewer countersigns the verdict with a wallet credential Aqta neither issues nor holds, so the decision signer, the identity issuer and the reviewer are three separate parties. Working prototype, not production.

The order is the roadmap. We are not trying to solve trust in AI in one leap; we are answering progressively harder evidence questions, and saying out loud which ones are still open.

Open questions

Open research questions

If any of these resonate, email hello@aqta.ai with subject prefix [research].

Q1Provenance

Binding the record to the computation. A receipt records what the issuer asserted. Can it establish something meaningful about the computation that actually ran, without paying enclave overhead on every inference?

Q2Sufficiency

Minimum sufficient evidence. What is the smallest set of independently verifiable objects a third party needs to reach a defensible conclusion about a consequential AI decision? Receipt, reviewer credential and countersigned verdict is our current candidate answer.

Q3Protocol

Cross-provider aggregation. When agents run on three model clouds, how are receipts under different regimes aggregated and queried as one evidence corpus without breaking offline verifiability?

Q4Protocol

Post-quantum migration. The minimum-disruption path from a classical signature to a post-quantum one such that classical-regime receipts remain verifiable indefinitely. The signature is already a tagged field, not the format.

Q5Privacy

ZK receipts for sensitive prompts. Extend BN254 Schnorr + Groth16 so a receipt proves policy was evaluated over the committed prompt, without revealing prompt or output, while staying offline-verifiable. Proving which model ran is Q1's territory, and Q5 inherits that limit.

Q6Application

Regulator-readable export. The right export format for a multi-month receipt chain so a central-bank examiner can ingest, query and verify with off-the-shelf tools.

Q7Application

Audit-cost economics. The real cost of producing, storing and querying signed receipts at bank scale, and where the receipt layer pays for itself against one contested decision.

Q8Privacy

Receipts and differential privacy. When receipts aggregate across organisations under a DP budget, how do per-receipt guarantees and privacy guarantees compose without one eroding the other?

Support

Infrastructure

Auth0 is the identity vendor for enterprise SSO (SAML/OIDC). Selected for WeBuild Cohort 2 under the Shared Island Enterprise Scheme (programme selection, not institutional backing).