Why the Unit Is a Package, Not a Portal

An evidence request from a market-surveillance authority is a document-shaped event: a scope (this system, this period), a deadline, and an expectation of something the authority can file, share internally, and cite. The wrong answer is "here are read-only credentials to our dashboard" — for all the reasons we covered in the Decision Record walk-through, portal access pushes verification cost onto the reviewer and disappears when the contract does.

The right answer is a self-contained archive, generated on demand: evidence-package-<agent>-<date>.zip. At its root sit three orientation files — a README describing the package, a metadata file with checksums and generation info, and the failure manifest we will get to. Below them, the folders follow the regulation's own structure, because the person opening the archive thinks in articles, not in your database schema. The pipeline that fills those folders is the five-station flow; this post is about what lands where.

The Per-Article Folders

Folder by folder, top to bottom of the archive:

The Transparency Folder: Pairs, Not Piles

The transparency folder embodies the package's core design decision. Every sampled decision appears as a pair: packet_001.json — the signed machine packet with the deliberation, alternatives and evidence references — and packet_001.pdf — its per-decision Decision Record, the human-readable account with the embedded packet and verification result.

Why pairs matter: an audit team is never one person. The compliance lead reads the PDFs; the technical assessor verifies the JSON signatures; a legal reviewer may quote the narrative. Because both halves derive from the same sealed record — the PDF literally embeds the packet, as covered in the packet deep-dive — the three of them can never be reading diverging accounts. Explanation and evidence, per decision, in one place.

RENDER-FAILURES.txt: Honesty as a Feature

At the root of every package sits a plain-text file most vendors would never ship: RENDER-FAILURES.txt. If any artifact in the package failed to render — a PDF that errored, an export that timed out — it is listed there, by name. Nothing is silently dropped.

The naive view is that this file is an embarrassment. The reviewer's view is the opposite. An archive with no failure manifest offers no way to distinguish "complete" from "quietly incomplete" — and auditors are professionally obligated to assume the worst about silence. A manifest converts unknown unknowns into known, bounded, re-requestable items. In the best case it is empty, and the empty file is itself evidence: the generation process checks, and reports, its own completeness.

This is the same honesty discipline that runs through the whole cluster — the draft flag on the Record's narrative, the readiness score that can say not ready in the ISO/IEC 42001 walkthrough. Artifacts that admit their limits are artifacts whose positive claims can be believed.

"How Long Does It Take to Put One Together?"

The question assumes assembly — a team collecting screenshots and exporting logs into folders for a fortnight. That model is exactly what the package exists to replace: it is generated, not authored. Every artifact inside derives from records that already exist because the agents produced them while deciding — sealed traces, signed packets, oversight events.

That inversion has a sharp consequence for readiness: the package is only as good as the records underneath it. Generate one before you need it — for one agent, one month — and read it the way a stranger would. Empty folders tell you precisely which station of the compliance flow is not yet emitting records. A thin oversight folder in a dry run costs you an afternoon; in a real audit it costs considerably more.

Diagnostic question: if you generated an evidence package for your highest-risk agent today, which folder would be empty — and would anything in your current stack even tell you?

The Dry-Run Technique

Sources & Further Reading