Use cases
Four questions, and what a record can honestly answer.
Each of these arrives long after the decision, from someone who was not there. What follows is what a signed record establishes, and what it does not.
We are pre-revenue and these are not customer stories. They are the questions themselves, drawn from the workflows we build for. Every claim below is checkable without contacting us, which is the point.
AI vendors selling into regulated buyers
“How do we verify what your system actually did in production?”
Asked by the customer’s security or model-risk reviewer, during procurement, while the deal sits in the queue.
Today
The answer is assembled by hand for every new customer: screenshots, an engineer’s explanation, a policy document, a log export. Each buyer asks in a different shape, so none of the work is reusable.
With Seal
The decision path runs through Seal. Each decision returns a signed record naming the policy that applied and what was decided, refusals as well as approvals. The pack goes to the reviewer once and is the same pack for the next buyer.
What a reviewer can establish
- Which policy version was in force when the call ran
- What was decided, including calls that were refused before reaching the model
- That the record has not been altered since it was signed
- That the reviewer can check all of this without an account and without contacting us
What it does not establish
- That the model reasoned well, or that the decision was correct
- That every decision in the period was recorded
Financial services
“Why was this application declined on the fourteenth of March?”
Asked eighteen months later by a regulator, an internal auditor, or the customer’s solicitor.
Today
The record that answers it was written by the organisation being asked. Cloud audit logs sit inside the operator’s own systems, in a format the operator controls.
With Seal
The customer’s own policy runs before the model call. The decision is signed at the moment it is made, and the evidence pack drops into the existing model-risk file rather than replacing it.
What a reviewer can establish
- The decision, the policy applied, and the moment it happened
- Per-decision evidence behind the AI entries in a DORA Article 28(3) Register of Information
- Chained export, so an insertion, deletion or edit is detectable by any reader
What it does not establish
- That the underwriting judgement was sound
- That the applicant was treated fairly, which is a separate question requiring separate evidence
Insurance
“Did each of these decisions clear under the policy that was in force when it ran?”
Asked by a chief risk officer or a governance committee, before an AI-assisted claims or underwriting workflow is approved to go live.
Today
Teams can build AI prototypes faster than governance, risk and operations can approve them. The approval rests on a description of the system rather than a record of it.
With Seal
The approved policy is the policy that executes, and each decision carries the version that applied. A reviewer opens a docket with one fixed question, set before the evidence is opened so it cannot be adjusted to fit the answer.
What a reviewer can establish
- Which rule applied to each decision in scope
- That approvals and refusals were both recorded, not only the outcomes that passed
- A named reviewer’s verdict, signed with a credential Aqta did not issue
What it does not establish
- That the pricing or claims judgement was right
- That the model is free of bias, which we do not measure and do not claim to
Healthcare
“What exactly did it decide, and can we show it?”
Asked by a clinical governance function months after a triage flag or an allocation decision.
Today
A dashboard is useful inside the organisation and carries no weight with a reviewer outside it. Most tools audit once the action has already run.
With Seal
PHI categories are masked or rewritten upstream, so the model runs on what it is cleared to see. Routes where the model should not decide alone require a human decision before anything executes, and the record names who cleared what.
What a reviewer can establish
- The model, the policy, the verdict, the time, and a one-way fingerprint of the prompt
- That a clinician signed off where sign-off was required
- That no content left the boundary: the record holds a hash, not the note
What it does not establish
- That the clinical decision was correct
- Any certification, accreditation or compliance opinion. Aqta issues records, not approvals
The limits are published on purpose.
A signature proves a record was not altered. It does not prove the computation ran as described, or that no decision was omitted. Those are open problems in our work and in everyone else’s, and we would rather be checked than believed.
For engineers: read the open ATTESTATION-v1 spec