AqtaAqta

ResearchWorking paper v0.1, June 2026

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

Aqta Research Team. Aqta Technologies, Dublin.

How to cite this work
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/}
}

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.

Comments and corrections to hello@aqta.ai. Page last updated 2026-08-26.

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.

The claim boundary, in its technical form: a Seal determination is reproducible wherever its inputs, rules and outputs are available to the verifier. Where a judgement depends on model reasoning the verifier cannot access, Seal records the determination and its evidence boundary, never a claim of correctness. A model-authored verdict could not be recomputed, so signing one would attest to a guess. A determination made elsewhere can still be carried: its signed output is hashed into request_hash and the issuer of that judgement is recorded, which is a different act from producing one.

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. Stating it is what makes the rest of the page checkable.

Verify the primitive yourself

100%of published conformance vectors pass on both implementations
751 µsmedian verification, 10k iterations, script published
Apr 2026signing in production since
0network calls during verification

Figures as of August 2026; vector count as of September 2026. The conformance suite grows whenever a new defect class earns a vector, which is why the count moves: it was 50 before an encoding defect found by our own differential fuzz added two, and 52 before an ordering divergence reported from outside added two more.

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-receipt.json -o receipt.json

$ 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("receipt.json")), trusted_public_key=key))
PY

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

This is a receipt the production gateway emitted and signed on 24 July 2026. 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 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.

Two line charts of per-receipt cost against canonical payload size from about 400 to 780 bytes: Ed25519 signing at a median of roughly 240 microseconds, verification at a median of roughly 750 microseconds, both nearly flat.
Figure 1. Ed25519 signing and verification overhead for ATTESTATION-v1 receipts. Median and p95 per-receipt cost over 10,000 iterations per configuration; local Apple Silicon hardware.
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-03 (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
Vectors50 cases across two formats, both implementations agreeing on every one · test-vectors
July 2026An evaluation agent left its sandbox and reached a third party's production systems. The affected platform reconstructed about 17,600 of its actions, in about 6,280 clusters, from its own logs, spanning four days from 9 July. It disclosed on 16 July; the operator confirmed the agent was its own on 21 July, twelve days after the first action. A second lab then reviewed its own evaluation transcripts and found three intrusions; the two affected organisations it could reach had not detected them. The platform's own report names the gap: “no admission policy rejecting privileged or hostPath pods.” Nothing checked what the agent was allowed to do before it did it. Sources: technical timeline · disclosure · operator statement · second lab's review
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 separately written offline verifiers that agree on every published conformance vector, checked on every change rather than at release, running in production since April 2026. Q1 below is where this map's hardest open problem lives, and it is ours too.

Corrections

Claims we retired

In September 2026 we ran a prior-art sweep against our own physical-authority work, looking for the systems that would contradict it. They exist, several are decades old, and the honest record of what we stopped claiming is more useful to a reader than the claim would have been. Each line below is a sentence we removed, and the work that removed it.

Cryptographic gating of an actuator is newRetired. ESA PSS-04-151 (Issue 1, September 1993) specifies per-command authentication bound to the individual telecommand segment, verified inside the command decoder by a hardware block named the Final Authorisation Function, upstream of the onboard computer, with a strictly single-use counter that refuses replay. It reached flight silicon in the MA28140 in 2000.
Independent downstream enforcement does not existRetired. Functional safety builds exactly that: a safety-related control system at a required Performance Level, architecturally separable, able to force a safe state the ordinary controller cannot override. The hardware to refuse already exists and is already certified. What it evaluates is speed, position, presence and torque, never who authorised the action.
Industrial control never had per-action authorisationRetired, and the correction cuts both ways. DNP3 Secure Authentication v5 required outstations to treat every output operation as critical and to refuse it on authentication failure, and it was formally verified sound at ESORICS 2017. IEC 62351-5:2023 then removed the challenge-reply procedure and user management in favour of per-association security. The industry specified it, proved it, and standardised back to channel authentication.
No standard requires approval for a consequential actionRetired. IEC 62443-4-2:2019 CR 2.1 RE(4) requires components to support dual approval where an action can result in serious impact on the industrial process. It is role-based rather than bound to a described action, carries no artefact, and binds only at security level 4, but the requirement is normative and has been published since 2019.
Machinery standards do not address unauthorised commandsRetired. IEC 62745:2017, now a normative reference of ISO 10218-1:2025, carries clauses titled Prevention of unauthorised operation and Prevention of unintended commands. Read in full, the first names a key-operated switch or access code on the remote station and the second is addressing and error detection, with a Hamming distance requirement against radio noise. It is command integrity, and it is prior art for that.
Pre-execution authorisation for AI actions is unexploredRetired. Recent work sets out pre-effect authorisation and authorization-bound execution for AI agent tool calls, with signed authorisation, replay blocking and a receiver-signed effect receipt, reproduced by its author on edge hardware. It is a single-author preprint that disclaims independent reproduction and physical-actuation safety, and it is dated before this note.

What survives is narrower, and we state it as a research position rather than a novelty claim. Four properties are absent from every deployed system we examined, and none of them is a new mechanism: an authorisation bound to the semantic content of an action generated by an open-ended system rather than chosen from a fixed command table; a signature from a party that is not the one commanding; an asymmetric signature, so a third party can check it later without holding the issuer's secret; and a refusal that is signed as a first-class record rather than expressed as an action that simply did not happen. Remove any one and the prior art above reappears at scale.

The question we are actually working on is therefore not whether a machine can be made to refuse. It can, and it has been able to for decades. It is what evidence survives when an action generated by an autonomous system is challenged by someone who was not operating it.

Proof

The dated public artefact

  1. AqtaBio commits W19.jsonDR Congo Ebola, rank 4public commit timestamp
  2. WHO declares PHEICBundibugyo EbolaDR Congo + Uganda
Figure 2. W19 commitment to WHO PHEIC: eight-day externally verifiable lead time. The public GitHub commit on 2026-05-09 is dated independently of the WHO record on 2026-05-17; Ledger commits are not GPG-signed.
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 difficulty, not a schedule. We are not trying to solve trust in AI in one leap, and we say out loud which questions are still open rather than which we intend to answer next.

Open questions

Open research questions

Four of the seven rungs of evidence independence are held today and three are open: omission-detectable, counterparty-attested and physically enforced. The ladder, with what each rung would take, is at aqta.ai/independence.

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

Q1ProvenanceBinding 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?

Q2SufficiencyMinimum 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.

Q3ProtocolCross-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?

Q4ProtocolPost-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.

Q5PrivacyZK 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.

Q6ApplicationRegulator-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.

Q7ApplicationAudit-cost economics.

The real cost of producing, storing and querying signed receipts at bank scale, and where signed receipts pay for themselves against one contested decision.

Q8PrivacyReceipts 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?

Q10IntegrityDetecting what was never written down.

A dishonest issuer does not need to forge anything: it holds the key, so anything it signs verifies. We enumerate the six classes where that happens in the issuer-as-adversary model, and five of them have mechanisms in the gateway. The sixth, omission, is open and we do not claim it: a decision that was never recorded leaves no artefact to check, and the party that would have recorded it is the party under review. What would an outside observer have to hold, or have seen, to put a bound on how much history is missing?

Q9ApplicationEvidence for a resource constraint.

A policy can refuse a call whose modelled energy cost exceeds a declared ceiling, and Seal signs that refusal: shipped 18 August 2026 as the carbon_budget rule, documented at doc.aqta.ai. The receipt establishes that a declared constraint governed the decision. It does not establish a measured reduction, because the estimate is derived from a static model-energy profile and a regional intensity figure, neither of which is metered. The open question is what an avoided-compute figure would have to look like to survive recomputation by someone who did not produce it, which is a methodology problem rather than a signing one.

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).