The Decision Record: a Self-Verifying PDF for AI Decisions
The Decision Record is a per-decision PDF/A-3B archival document produced by AIAgentree for any sealed AI decision. It contains a human-readable account of the decision, the result of tamper-evidence verification run at export time, an Ed25519 signature block, and the signed machine-readable decision packet embedded as an attachment inside the PDF. A reader verifies it in three steps: open the embedded attachment, check the packet signature against the public JWKS at /.well-known/jwks.json, and read the hash-chain verification result printed in the document. The regulatory narrative text in the Record is a draft pending legal sign-off; the underlying data, signatures and verification are production. A self-verifying file requires no portal login and no trust in the vendor's storage, which is why it serves auditors, courts, and affected persons exercising their EU AI Act Article 86 right to an explanation.
One decision, one file. The Decision Record is a PDF/A-3B document that explains the decision in plain language and proves the explanation matches the sealed trace — without you logging into anything.
- •Human-readable account — what was decided, the reasoning for and against, oversight status.
- •Live tamper-evidence result — the outcome of chain verification at export time, printed in the document.
- •Signature block — the embedded packet verifies against a published public key, offline.
- •Machine packet inside — human narrative and machine evidence travel as one file.
- •Honest flag — the regulatory narrative prose is a draft pending legal sign-off; data and verification are production.
Traceability tells you what an agent did. This cluster is about the next step: records that stand up — under the EU AI Act, NIST AI RMF and ISO/IEC 42001.
- 1.Defensible AI Decisions: The Complete Guide to Records an Auditor Can Act On
- 2.They Made Agents Traceable. We Make Their Decisions Defensible.
- 3.The Decision Record: the PDF an Auditor Actually OpensYou are here
- 4.Inside the Signed Decision Packet (the JSON)
- 5.Inside an EU AI Act Evidence Package (Folder by Folder)
- 6.Human Oversight You Can Prove (Because Machines Can't Hold the Permission)
- 7.Article 86: What Affected Persons Can Demand From Your AI
- 8.From First Trace to Evidence Package: an EU AI Act Flow Walk-Through
- 9.A NIST AI RMF Self-Assessment You Can Actually Finish
- 10.ISO/IEC 42001 Readiness: 38 Controls, One Honest Score
- 11.Agent-Native Onboarding: Tracing in 10 Lines (and Agents Can Sign Themselves Up)
Every vendor demo of an audit feature ends the same way: "…and the auditor can log into the dashboard."
Auditors do not log into your dashboard. They work with documents — files they can save, forward, annotate, and cite in a report.
So the artifact that matters is not the dashboard. It is the file. Here is what ours looks like, page by page.
Disclaimer: Informational content, not legal advice. The Decision Record's regulatory narrative text is currently a draft pending legal review — never treat it as legally signed-off prose. AIAgentree supports compliance work; it does not by itself make an organization compliant.
Why a Self-Verifying File Beats a Portal Login
Think about what a portal-based audit actually asks of the auditor: create an account on the vendor's system, trust the vendor's access controls, trust that what the dashboard renders today is what the system recorded then — and accept that the evidence disappears when the contract does. Every one of those is a dependency an audit report has to caveat.
A self-verifying document inverts all four. The Decision Record is a PDF/A-3B file — the long-term archival profile of PDF — so it opens in any reader, today and in ten years. The evidence is inside the file. And its integrity is checked against published cryptographic keys, not against our word. The file is the record; we are not in the trust path.
That property is what makes the Record usable beyond audits: it can be handed to an affected person exercising their Article 86 right to an explanation, attached to a court filing, or archived in your own document-management system — unchanged in each case.
Page by Page: What the Reader Sees
Export a Record for any sealed decision and open it. The structure is deliberately boring — auditors like boring:
| Part | What it contains | Why it is there |
|---|---|---|
| The decision account | Plain-language statement of what was decided, when, in what context; the deliberation with arguments for and against; alternatives considered; the rationale | The Article 13-shaped interpretation surface — a reader with no access to your systems understands the decision |
| Oversight status | Whether human approval was required, and the oversight events on the trail | The Article 14 question, answered per decision |
| Tamper-evidence result | The outcome of hash-chain verification run at export time, printed in the document | States, in the file itself, whether the decision's history verified as intact |
| Signature block | The packet's Ed25519 signature and the pointer to the public verification keys | Lets a third party verify authenticity offline — without trusting us |
| The embedded packet | The signed, machine-readable decision packet, attached inside the PDF (visible in any reader's attachment panel) | Human narrative and machine evidence travel as one file — no 'the JSON is in another system' |
One flag we print rather than hide: the regulatory narrative prose — the sections that address the record to specific EU AI Act articles — is currently draft pending legal sign-off. The data, the signatures and the verification underneath it are production. An artifact that labels its own maturity honestly is more credible than one that doesn't, and auditors notice.
How a Skeptical Reader Verifies It (Three Steps)
The Record is built for a reader whose job is not to believe you. Verification takes three steps and no special tooling:
Open the embedded attachment
In any PDF reader's attachment panel, extract the machine-readable decision packet from inside the document.
Check the signature against the public keys
Verify the packet's signature against the public JWKS published at /.well-known/jwks.json. A valid signature proves the packet is authentic and unmodified — verified offline, without trusting our storage.
Read the tamper-evidence result
The document prints the hash-chain verification outcome computed at export time — whether the decision's event history verified as intact.
If verification succeeds, the reader knows two things at once: the explanation they just read matches the sealed record, and the record has not been altered since sealing. That combination — explanation plus integrity proof, in one file — is what we mean by a decision being defensible rather than merely traceable. The machine half of the story continues in Inside the Signed Decision Packet.
"A PDF? In 2026?"
The objection is fair — PDF sounds like a step backwards from APIs and dashboards. But look at who consumes the artifact. Regulators, courts, DPOs, complainants' lawyers: their working medium is documents. The archival PDF profile exists precisely because institutions need files that render identically decades later.
And the Record is not a PDF instead of machine-readable evidence — it is both at once. The embedded packet means an engineer can extract structured JSON from the same file the lawyer is reading. One artifact, two audiences, zero divergence between them. The alternative — a human report generated separately from the machine evidence — is exactly how explanation and record drift apart.
Diagnostic question: if your compliance team had to answer an explanation request tomorrow, would the human-readable answer and the machine evidence come from the same artifact — or from two systems that have never been reconciled?
Where Decision Records Show Up
Records are not a special export you remember to make. They appear at three points of the compliance flow:
- ✓On demand, per decision — one export call for any sealed decision, from the first one you ever trace.
- ✓Inside every evidence package — each sampled decision ships with its Record beside its machine packet, so the regulator gets evidence and explanation together. See the evidence-package tour.
- ✓In answer to Article 86 requests — explanation access is not an admin privilege; every role that can read the PDF can read the explanation.
The concept underneath all three is the audit trail as a first-class object — the subject of What Is an AI Audit Trail? and, one level up, the defensible-decisions guide.
Sources & Further Reading
- •Regulation (EU) 2024/1689 (EU AI Act) — Articles 13, 14, 86 — EUR-Lex (2024)
- •ISO 19005-3 (PDF/A-3) — archival PDF with embedded files, ISO (2012)
- •RFC 7517 — JSON Web Key (JWK) — the JWKS format used for public verification keys, IETF (2015)
Frequently Asked Questions
What is a Decision Record?
A Decision Record is a self-verifying PDF/A-3B document produced for one sealed AI decision. It contains a human-readable account of the decision, the tamper-evidence verification result computed at export time, a signature block, and the signed machine-readable decision packet embedded inside the PDF. It is the artifact you hand to an auditor, a court, or an affected person.
How do I verify a Decision Record is authentic?
Three steps: open the embedded attachment in any PDF reader to extract the machine packet; verify the packet's signature against the public JWKS published at /.well-known/jwks.json (offline, without trusting the vendor's storage); and read the hash-chain verification result printed in the document. A valid signature plus an intact chain means the explanation matches the sealed, unaltered record.
Why PDF/A-3 instead of a dashboard or API export?
Because the artifact's consumers — regulators, courts, lawyers, affected persons — work with documents, and archival PDF is built to render identically for decades. PDF/A-3 specifically allows embedded files, so the same document carries both the human-readable explanation and the machine-readable signed packet. Engineers extract structured JSON from the same file lawyers read.
Is the Decision Record's explanation legally approved text?
The regulatory narrative prose in the Record is currently a draft pending legal sign-off, and we say so plainly. The underlying decision data, the signatures, and the verification machinery are production. Treat the narrative as a strong starting draft for your legal team, not as sign-off-ready language.
Does the Decision Record satisfy EU AI Act Article 86?
It is designed to serve Article 86 requests: a clear, meaningful, per-decision explanation of the role the AI system played, portable enough to hand to the affected person directly. Whether a given explanation satisfies the obligation in a specific case depends on the decision and the deployment context — the Record supports the obligation; it does not discharge it automatically.
Can I generate a Decision Record for past decisions?
For any decision that was traced and sealed, yes — Records are exports over data that already exists, from the first sealed trace onward. For decisions made before tracing was in place there is no sealed record to export, which is itself the strongest argument for starting to trace now.
Related Topics
Related Articles
Defensible AI Decisions: The Complete Guide
The hub for this cluster: every artifact, every framework, and where to go deeper.
Inside the Signed Decision Packet (the JSON)
The machine half of the Record: top-level sections, why it is signed, how third parties verify it offline.
Article 86: What Affected Persons Can Demand From Your AI
The least-covered EU AI Act article — and the request the Record was built to answer.
AIAgentree Team
AI Compliance
The AIAgentree team is building decision tracing infrastructure for AI agents. Our mission is to make AI reasoning visible, auditable, and improvable.
Open a real Decision Record.
Book a 30-minute session and we'll export a Record from a demo decision in front of you — attachment, signature check, and chain result included.
See a Record Live