Three issuers, three verification paths
No single party can create the complete evidence pack alone.
Seal
Issues the receipt
Against a published Ed25519 key
receipt.jsonYivi
Issues the credential
Held in the reviewer’s own wallet
credentialReviewer
Issues the verdict
Bound to the evidence
signed verdictOne evidence pack, three verification paths. Each object verifies without contacting Aqta.
An open receipt format, a wallet-held credential and a verdict anyone can check without Aqta: a reusable pattern, not a closed Aqta account workflow. The record formats have two separately written reference implementations, TypeScript and Python, which agree on all 67 conformance vectors. One implementation defines a format. Two that agree make it interoperable.
- AI decidesIn the operator’s stack
- Seal signsThe receipt
- Credential presentedFrom the reviewer’s own wallet
- Verdict countersignedCredential bound in, pack exports
Across the trust boundary: the outside reviewer’s side.
Review a signed record
Four steps, in order. Each one unlocks the next. This is steps four and five of the guided demo.
Evidence: the signed receipt
A genuine receipt from the production gateway. It holds a hash of the request,
never its text: no prompt, no response, no customer data. Verify it yourself with
npx aqta-verify-receipt.
a hash of the request, never its text
Docket: the question being askedAfter step 1
The question is hashed into what you sign, so the verdict can never drift from what was asked.
fixed before anyone signs
Review and countersignAfter step 2
You sign a verdict bound to the receipt and the fixed question, using a credential from your own wallet. The receipt is untouched: the verdict is a new artefact that references it.
The disclosed credential proves
- ✓ control of a verified email address
- ✗ not an employer
- ✗ not reviewer authority
The attribute you disclose is stored with your verdict, and anyone holding the docket link can read it without an account. That is deliberate: an anonymous verdict proves nothing. While countersigning is in pilot, disclose the sample email credential rather than anything you would not want stored. What we keep and how to have it erased.
Which credential establishes authority is the open question, and this wallet’s own
production scheme already carries two answers: pbdf.signicat.kvkTradeRegister,
which discloses an organisation, its KVK number, a job title and whether the holder may act
for it, and pbdf.nuts.agb, which proves a registered healthcare provider. Neither
is wired in yet. We would rather test one with a reviewer who holds it than accept it untested.
View the canonical binding text
your wallet, your signature
Export the evidence packAfter step 3
The evidence pack: one file, three trust domains, verifiable without Aqta.
Verification is asymmetric today, and worth saying plainly. The receipt
verifies in any browser, or offline with npx aqta-verify-receipt. The
attribute-based signature verifies with irmago (CLI or server-side), because no browser
implementation of Idemix signature verification exists yet. Different tools, same property:
neither needs Aqta.
three files, none of them needs us
What this proves, and what it does not
- Proves
- Seal signed the stated record, its signed fields have not changed, and a party holding a credential Aqta did not issue reviewed it and signed a verdict, at a time attested by the Yivi timestamp service, a clock Aqta does not run.
- Does not prove
- That the record matches the computation that actually ran. A signature is an assertion by a key holder, not evidence of execution fidelity, so a countersigned review certifies a review of the artefact. Closing that is open research.
- Does not prove
- That no decision was left out. A decision never written down leaves no trace, so a reviewer sees what they were shown and cannot conclude the rest was irrelevant. Completeness is the hardest of these and we do not claim it.
- Does not prove
- That the decision was correct, fair or free of discrimination. None of that is in the artefact. This establishes what was decided and under which rules, which is what lets someone competent argue about whether it should have been.
- Credential
- A verified email is a placeholder: it shows a reviewer is identifiable, not qualified or free of conflict. Which credential establishes authority is the open question, and we would rather work on it with people who issue credentials than guess. Professional accreditation, an organisational role attestation, something EUDI-issued once it exists: all plausible, none settled. If you work on credential schemes, [email protected].
Break a seal, live
Change one field in a real receipt and the signature fails. Load it here, or open it full page.
Next steps
- Pilot one workflowStart with a free 30-minute evidence review, then a short proof on one agreed workflow, reviewed with the person who would actually have to accept it: your model-risk committee, safety board or clinical governance function, not a placeholder reviewer. Book an evidence review.
- Verify a receipt
npx aqta-verify-receipt, or in the browser at app.aqta.ai/verify. Offline, no account. - See a control that operatedThe Refusal Ledger holds real production refusals, actions agents were not permitted to take, each signed before execution and verifiable with the same command. A prevented action is evidence too.
- Walk the full stackThe guided demo goes from one API call to evidence you verify on your own machine, in seven steps. This page is steps four and five.
Research, including what is unsolved: aqta.ai/research · [email protected]