Inspector access

A regulatory inspector or auditor needs access to data and the audit trail — but strictly read-only and for a limited term. X7 Insight solves this without any special “inspector mode” in the code: an inspector is an ordinary principal with time-limited read-only grants. The same access rules that apply to everyone are in effect: default deny and “a deny always wins.”

0:000:00

What matters most for an inspector: reading the audit trail and verifying the hash-chain

How to grant inspector access

1. Create (or connect via SSO) an inspector principal in Admin → Users.

2. In Admin → Access, assign a copy of the Inspector role to the relevant study, setting a term (“from — to”) — this is the key point: access must expire on its own.

3. Make sure the permission set is read-only: study.read, subject.read, data.read, query.read, audit.read, and audit.verify (independent hash-chain verification). No *.update, no export, no unblinding.

A dedicated work section

For inspection, the administration area has a separate “Inspection” section (Inspection Readiness Packet) — assembling the inspection package in a single action: the audit trail with full chain verification, a snapshot of access “who-what-where,” design versions, study metadata, and a manifest.json with the sha256 of each file. The package is always blinded and verifiable offline. It is assembled by the administrator or the data manager, not the inspector themselves.

What the inspector sees

On sign-in, the inspector lands in the workspace in an explicit read-only mode (a banner with the access term). Navigation is like an ordinary user’s, but without a single write action.

• Study data — subjects’ casebooks, forms, values. In read mode, without the ability to change anything.
• The history of every value — all versions of a field: what it was, what it became, who changed it and when, with the stated Reason for Change (RfC).
• The audit trail — the full chain of events with filters by subject, form, period, and actor; for each event you can see “before/after” and the causal link.
• Independent integrity verification — the inspector can click “Verify trail integrity” for a selected period: the system recomputes the cryptographic audit chain and returns a verdict of “chain is intact” or “chain is BROKEN at record …”.

Why chain verification matters

Hash-chain verification is a direct answer to inspection’s main question: “how will you prove the audit trail was not edited?” The proof is reproducible on the spot: the inspector does not have to take anyone’s word — they verify integrity themselves. If a break is found, it is a critical incident, and the system does not silently “fix” it.

What the inspector cannot do

The restrictions are not UI cosmetics: they follow from the fact that the corresponding permissions simply were not granted to the inspector. Even bypassing the interface directly will hit a server denial.

Action	Why it is unavailable
Any editing of data, statuses, or queries	no *.update permissions — read-only access
Exporting data	no export.run permission; there is no button, and a direct call is denied
Unblinding	no data.unblinded.read permission; blinded values are masked (•••) everywhere, including the audit
Extending one’s own access	the term is changed only by a new grant; backdating is not allowed

The term expires automatically

Inspector access ends on its own when the term expires: the next request simply stops passing the permission check. An already-open screen remains readable, but new data will not load — the system shows “the inspection access term has expired.” Extension is always a new grant, not an edit of the old one: the grant history is immutable.

If inspection needs unblinding or export

These are separate, deliberate sponsor decisions, not a default. Unblinded access requires a separate auditable data.unblinded.read grant. Handing over inspection materials is usually prepared by the data manager via export or the inspection package — with an auditable record of the release. See Data export and Audit trail.