A study ends twice: once when data collection stops, and once when the dataset is declared final. The lock is that second ending. A locked database is the version of the study you analyze, publish, and defend — the answer to “which data did the results come from?” has to be “the locked dataset, unchanged since this date, by these people, for these reasons.” Everything on this page exists to make that sentence true.
Locking lives in the Lock tab of the Data management workspace. It is deliberately slow to engage and audited to release: every transition requires a stated reason and an electronic signature, and the consequential ones require two different signers.
The study lifecycle lock#
The lifecycle lock is the outer gate over the whole study. It moves through a small set of states:
| State | What it means |
|---|---|
| Unlocked | Normal operation. When all expected data is in, enter data cleaning to head for lock. |
| Data cleaning | Cleaning and QA in progress. Resolve every query, then soft-lock to freeze for final review. |
| Soft-locked | A reversible freeze: only data-management roles can edit while final QA completes. Taking or releasing a soft lock is a signed action. |
| Hard-locked | The final lock — all edit rights removed. Reads and exports keep working; late participant data is quarantined. The only way back is the two-signer audited unlock. |
| Unlocked for amendment | An exceptional signed reopening with an enumerated scope of permitted changes. Make only those changes, then relock — a report of what changed during the window is generated and countersigned. |
Once a study is locked, the dashboard refuses changes to it across the board. A handful of exceptions are deliberate: lock transitions themselves, exports, and closeout work all still function — analyzing and archiving the frozen data is the point of the lock, not a violation of it.
Two people, on the record#
The transitions that change what the final dataset is — hard lock, unlock for amendment, and relock — require two authorized signers. The first signer states the reason (and, for an unlock, exactly which records may change and nothing else) and signs. The request then waits for a different person to countersign; the countersignature executes the transition. Either party can cancel while it waits.
Every transition lands in the signed history: when it happened, the transition, the reason, and both signers. Anyone reviewing the study later can read exactly who locked the database, when, and why.
Unlocking is loud by design
Late-arriving data is quarantined#
Participants' phones do not know the database locked. A check-in completed offline on lock day may sync a week later. TrialPilot resolves this without either bad option — silently dropping the data, or silently changing a locked dataset:
- Data that arrives after the lock goes to a post-lock quarantine, preserved in full and never merged into the locked dataset.
- The quarantine queue in the Lock tab shows each item: the participant (by pseudonymous ID), the data type, when the device captured it, when the server received it, and the lock state at receipt.
- Merging quarantined data into the dataset requires the audited unlock, with the merge inside its enumerated scope. Until and unless that happens, the locked dataset stays exactly as signed.
Concurrent edits never silently overwrite#
Well before any lock, the dashboard protects records from a quieter hazard: two coordinators editing the same record at the same time. If both open a record and the first saves, the second save is rejected with a conflict message rather than silently overwriting the first person's change. The second editor reloads the current version and reapplies their edit deliberately. In a clinical dataset, an overwrite nobody noticed is worse than a save you have to redo.
The path to closeout#
Closeout is the orderly walk from “data collection is done” to “the study is archived.” The Closeout page keeps a checklist of what must be ready; archiving is blocked until every item is ready or explicitly waived with an audited reason, and some items are never waivable. The typical sequence:
- Complete safety obligations. Close out adverse events and reporting clocks in Safety operations and the regulatory workspace.
- Resolve queries and finish coding in Data management.
- Lock. Enter data cleaning, soft-lock for final QA, then take the two-signer hard lock.
- Export the final datasets from the lock — see Exports and CDISC — and store them with your study records.
- Mark the study Completed, then archive it. An archived study is read-only, and its downloadable archive package is rebuilt deterministically and verified against a hash, so the archive you download years later provably matches the original. Unarchiving is possible, audited, and requires a reason.
After closeout, the locked, exported, archived dataset is the study. Everything above — signatures, quarantine, conflict rejection, the audit trail — exists so that sentence holds up under scrutiny.