Seal
Seal by Aqta · aqta.ai
SIGNING IS PRODUCTION · THIS REVIEW FLOW IS A PROTOTYPE
Published FIDES use case

When an AI decision is challenged, who holds the evidence?

Digital identity proves who. Seal proves what happened.

Today: the organisation under review controls the record used to explain itself. Here, three independent parties each hold one piece, and no single party controls all three. The evidence is built to survive even if Aqta disappears.

Break a seal → Change one field in a real receipt and watch the signature die. No account, 30 seconds.

The three issuers

SEAL issues the receipt published Ed25519 key YIVI issues the credential held in the reviewer’s wallet REVIEWER issues the verdict bound to the evidence receipt.json credential signed verdict one evidence pack · three verification paths

Three independent parties. Three verification paths. No single party can create the complete evidence pack alone. Open receipt format, wallet-held credential, independently verifiable verdict: a reusable trust pattern, not a closed Aqta account workflow. The record formats have two independent reference implementations, TypeScript and Python, which agree on all 50 conformance vectors. One implementation defines a format. Two that agree make it interoperable.

How a review happens

AI decides operator’s stack Seal signs the receipt TRUST BOUNDARY · INDEPENDENT REVIEWER credential presented from their own wallet verdict countersigned credential bound in evidence pack exports

Each object verifies independently, without contacting Aqta.

Walk the full stack

This page is steps four and five of seven. The guided demo walks the whole chain: one API call becomes a signed receipt, a register entry, this docket, a verdict, and a pack you verify on your own machine.

Open the guided demo

01Evidence: the signed receipt

The receipt holds a hash of the request, never its text. No prompt, no response and no customer data is in the evidence, so there is nothing in it to leak. A genuine receipt from the production gateway. Verify it yourself with npx aqta-verify-receipt.

02Docket: the question being asked

The question is hashed into what you sign, so the verdict can never drift from what was actually asked.

03Review and countersign

The reviewer signs a verdict bound to the receipt and the fixed question, using a credential from their own wallet. The receipt itself is untouched: the verdict is a new artefact referencing 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. This review flow is a prototype, so disclose the sample email credential rather than anything you would not want stored in one. 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 is authorised to act for it, and pbdf.nuts.agb, which proves a registered healthcare provider. Neither is wired in here yet. We would rather test one with a reviewer who actually holds it than accept it untested.

04Export the evidence pack

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.

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
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
That no decision was left out. A decision never written down leaves no trace of not having been written down, 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
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 independent. 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].

The 33-second film

Recorded 18 Aug against this build. Every frame is a real artefact.

Next steps

  1. Verify a receipt. npx aqta-verify-receipt, or in the browser at app.aqta.ai/verify. Offline, no account.
  2. See a control that operated. The 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.
  3. Walk the full stack. app.aqta.ai/demo is the guided demo: seven steps from one API call to evidence you verify yourself. This page is steps four and five.
  4. Ask for an evidence pack. The pack a reviewer receives, built for your workflow: ask for one.
  5. Pilot one workflow. One decision path, thirty days. Map the workflow, seal the traffic, produce the first pack, review it with the person who would actually have to accept it: your safety board, model-risk committee or clinical governance function, not a placeholder reviewer. Tell us the workflow type, loan, claim or clinical decision, and we scope it. Apply.

Research, including what is unsolved: aqta.ai/research · [email protected]