The evidence pack a regulator actually accepts

Ask a team to prove what their AI did last quarter and you usually get a folder: screenshots of a dashboard, a CSV exported from an internal tool, a PDF someone assembled the night before the audit. Each of these is a claim about what happened, written by the party with the most to gain from the claim being believed. An auditor knows this. The pack tells them what you say occurred; it gives them no way to check whether it did.

An evidence pack that survives scrutiny does a different job. It lets someone who does not trust you confirm, on their own machine, that a specific action was approved by a specific authority and executed as approved, without calling your servers and without taking your word for anything. That is a higher bar than "we kept records," and most of what gets handed over today does not clear it.

Why the usual handover is weak

Three problems recur, and they compound.

The first is authorship. A spreadsheet exported from your own system is self-authored. Nothing about the file distinguishes a faithful export from one edited after the fact, or from one generated to match the story you want to tell. The reviewer has no cryptographic reason to believe any row.

The second is integrity. Screenshots and PDFs carry no way to detect change. Alter a timestamp, delete an inconvenient line, and the artifact looks identical. There is nothing to recompute, so there is nothing to catch.

The third, and the one that matters most for agents, is binding. Even an honest log usually records that an action happened. It rarely proves that the action executed was the action approved. Between "the policy said X" and "the system did Y" sits the gap where real incidents live: an agent that acted outside its grant, a step that ran without the approval it claimed, a task performed on behalf of a principal who never authorized it. If your evidence cannot close that gap, it cannot answer the question a regulator is actually asking.

What a defensible pack contains

Athena produces evidence built around properties a skeptical reviewer can test, not assertions they have to accept.

• Integrity you can recompute. Each record is serialized to a canonical form using RFC 8785 (JSON Canonicalization Scheme), so the same content always produces the same bytes. Hash those bytes and you get a value anyone can reproduce. Change one field and the hash no longer matches. Nothing here depends on trusting Athena; the reviewer computes it themselves.
• Authorship you can check. Each record is signed with ML-DSA-65, the post-quantum digital signature standardized in FIPS 204. The signature verifies against a public key. It confirms the record was sealed by the holder of the corresponding private key and has not changed since. A reviewer verifies the signature offline, with no network call and no trusted service in the path.
• The approved-versus-executed binding. The record carries both the grant that authorized an action and the action that ran, bound together in one signed, canonical structure. The reviewer can see that what executed matches what was approved, or that it did not. This is the property the screenshot can never provide.
• The on-behalf-of. When an agent acts for a principal, the record names the principal and the authority under which it acted. Accountability points at a party, not at an anonymous process.
• Offline verifiability. The whole check runs on the reviewer's machine against the file in front of them. No live system to query, no endpoint that could return a different answer next week, no dependence on Athena being online or honest at review time.

Each record stands on its own proof. This is single-record verification, not a transparency log or an append-only ledger whose guarantees rest on the wider structure. You hand over the record and its signature; a reviewer confirms it in isolation.

Mapping evidence to obligations

A verifiable record is necessary but not sufficient. An auditor's question is rarely "is this file authentic" and usually "which of my obligations does this answer." A pile of sound records that nobody has mapped to controls still leaves that work on the reviewer's desk.

Athena carries a reusable crosswalk expressed in OSCAL, the Open Security Controls Assessment Language. The crosswalk ties each kind of evidence to the control it speaks to, so a record about an approval decision lands against the obligation that requires approvals, and one about a data access lands against the obligation that governs access. Author the crosswalk once and reuse it across frameworks that share underlying controls, whether the reviewer is working from DORA, NIS2, ISO 27001, ISO 42001, SOC 2, GDPR, or HIPAA. Because it is machine-readable, the mapping can be presented in structured formats a reviewer's tooling can ingest directly, in the spirit of xBRL-style structured reporting, rather than as prose someone has to transcribe.

The boundary we will not cross

What Athena produces is candidate evidence and a defensible record. That phrasing is deliberate. The record is tamper-evident, meaning change is detectable, not tamper-proof, meaning change is impossible. The two are not the same, and we will not blur them.

The acceptance decision is not ours to make. Whether a pack satisfies an obligation belongs to the auditor or the regulator reviewing it. Athena does not issue legal opinions, does not grant certification, and does not promise that any particular reviewer will accept any particular pack. What we give you is evidence that holds up when someone checks it, and a mapping that shows what it answers. The verdict stays with the people whose job it is to render one.

Before your next audit, take one action an agent performed and ask a simple question: can a reviewer who does not trust us confirm, offline, that this was approved and ran as approved. If the honest answer is a screenshot, you have an assertion with a border around it. Make it a record they can recompute, verify, and map to the obligation it answers, and you have handed them something they can actually work with.