Inspection Readiness Packet

The Inspection Readiness Packet is an evidence ZIP that, in a single action, assembles everything a regulatory inspection asks for: the audit trail with chain verification, anchors, an access snapshot, and design versions. It lives under Admin → Inspection (/admin/inspection) and is meant to be self-service — no assembling evidence by hand, piece by piece.

0:000:00

Assembling the inspection packet in one action — with sha256 in the manifest

What goes into the packet

Content	What it is
Audit trail	The full trail in CSV and JSON with full hash-chain verification — chain integrity is confirmed in the packet.
Chain anchors	The current chain head and the whole anchor history — to independently prove the audit was not rewritten.
Design versions	The study’s design versions and the active version at each site.
Access snapshot	A “who-what-where” snapshot: principals, grants, roles at assembly time.
Study metadata	Sites, subject counters, enabled modules.
manifest.json	A manifest with a sha256 of every file in the packet — the basis of the offline check.

How to assemble the packet

1. Open Admin → Inspection and select the study you are assembling the packet for.

2. Click Assemble inspection packet. Assembly runs in the background — a large packet is queued, and the screen shows its status.

3. When the packet is ready, download the ZIP from the packet history. Every build appears in the history with its time, author, status, and a short sha256 of the result; every download is audited.

4. A failed build can be retried right from the history.

Permissions on this study are required

The assemble button is available only with the export.run, audit.read, and access.read permissions on the selected study. The server re-checks them independently of the interface (default deny), so a packet cannot be assembled without the full set.

Always blinded, verifiable offline

The packet never unblinds

The Inspection Readiness Packet is always blinded: it never reveals blinded data — like any delivery channel without an explicit unblinding gesture. The data.unblinded.read permission has no effect on packet assembly — there will be no unblinding in it.

The packet is self-verifiable without access to the system: inside the ZIP is a manifest.json with a sha256 of every file, and the audit trail comes with hash-chain verification. An inspector (or you) can recompute the checksums offline and confirm that no file was substituted. Additionally, each build anchors the audit hash-chain — an external point that later ties the proof of immutability together.

Keep the packet in your own WORM/eTMF

The system assembles and hands over the packet but does not replace your archival storage. Put the downloaded ZIP into your own WORM/eTMF storage — that leaves you with dated, immutable evidence of the study’s state at the time of the inspection.

Audit trailThe immutable trail and hash chain the packet bundles and verifies.

Blinding & privacyWhy the packet is always blinded and how blinded data is masked.

Electronic signatures & Part 11Part of the evidence base an inspection expects alongside the packet.

GlossaryThe 'Inspection Readiness Packet' term and related compliance concepts.