Assemble the inspection packet

The Inspection Readiness Packet is an evidence ZIP that, in a single action, assembles what the system can prove by itself: the audit trail with chain verification, anchors, an access snapshot and design versions. No need to collect evidence piece by piece.

Who and when

QA & inspection — the QA specialist or whoever prepares the study for an inspection or audit. You need all three permissions on the selected study: running exports (export.run), reading the audit trail (audit.read) and viewing access (access.read). The server re-checks them independently of the interface (default deny), so a packet cannot be assembled without the full set.

Assemble the packet before an inspection or a sponsor audit, and to archive a dated state of the study.

Before you start

• You hold all three permissions on this study.
• An inspection will also ask for procedures, training, the delegation log and the validation report — those belong to your organization, not to the product; prepare them separately.
• Have a place ready in your own WORM/eTMF storage for the downloaded ZIP.

Steps

1. Open the study → Exports → the Inspection packet tab.

2. Click Assemble inspection packet. Assembly runs in the background — a large packet is queued, and the screen shows its status (“Assembling…”).

3. When the packet is ready, click Download in Export history. Every build appears there with its time, author, status and the result’s Checksum (SHA-256).

4. Put the ZIP into your WORM/eTMF storage.

0:000:00

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

Retry a failed build

If a build failed, click Retry in its row in Export history.

Verify the packet offline

Unpack the ZIP and recompute the sha256 of every file — compare with manifest.json. A match means no file was substituted. How a recipient checks it is covered in Documents and certified copies.

What happens

• The packet is assembled in full, with no manual selection of files — contents under What goes into the packet.
• The build lands in the study’s export journal with its checksum; every download is recorded in the audit trail.
• Each build anchors the audit hash chain: it records the current chain head — an external point that later ties the proof of immutability together.
• Blinded values do not go into the packet — regardless of your permissions.

If it doesn’t work

• No tab or Assemble inspection packet button — you lack one of export.run, audit.read, access.read on this study.
• The build sits in the queue for long — a large packet waits its turn among background exports; wait, the status updates in the history. An unneeded queued build can be stopped with Cancel.
• The build failed — click Retry in the export history.
• No PDF/A casebooks in the packet — on a large study they are omitted; the manifest says so explicitly. Casebooks are exported separately.
• No unblinded values in the packet — by design: the packet is always blinded.

Next

Export the audit trailJust the trail — a filtered file, without the full packet.

Verify the audit chain integrityRecompute the hash chain right in the system.

Give an inspector accessUrgent view-only access for an inspector for the inspection period.

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

More detail

What goes into the packet

The packet’s contents are fixed and assembled in full:

Content	What it is
Audit trail	The study’s trail in CSV (a dynamic file with every hash-chain link field), JSON, XLSX and PDF — the trail in words, before/after, with the actor’s role and organization — plus full tenant hash-chain verification (also as an XLSX representation). The trail covers everything that happened in the study’s scope — including permission grants and revocations on it, and access denials. Tenant-level events (sign-ins, permissions outside the study) stay under Admin → Audit.
Subject records	Values in CSV and PDF/A casebooks — a certified copy available without waiting for database lock. On a large study casebooks are omitted and the manifest says so explicitly.
Signature register	Who signed, when and with what meaning, plus the coverage of each signature: what exactly it attests, and the checksum of the covered data.
Design definitions	Full version declarations: question texts, code lists, units, edit checks and derivations — so a value at an OID is readable without the live system. Each published version also contributes its CRF blank, annotated CRF (aCRF) and specification.
Design versions	The study’s design versions and the active version at each site — including an XLSX representation.
Chain anchors	The current chain head and the whole anchor history — to independently prove the audit was not rewritten.
Access snapshot	A “who-what-where” snapshot: principals, grants, roles at assembly time — including an XLSX representation.
Access history	The history of permission grants and revocations and role assignments across the study’s scope — who, what, to whom and when.
User events log	Sign-ins, sign-outs and access denials of the study’s users — what an inspection calls user logs.
Study metadata	Sites, subject counters, enabled modules.
manifest.json	A manifest with a sha256 of every file in the packet, the build date and the version of the release that built it — the basis of the offline check.

Always blinded, verifiable offline

The packet is meant for handing over to an external recipient who has no access to the system.

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.

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.

See also Blinding and privacy and Electronic signatures and Part 11 — part of the evidence base an inspection expects alongside the packet.