Database lock is a formal assertion, not an administrative milestone. Most locks that slip do so predictably, and the evidence is usually sitting in the metrics weeks beforehand. This is a working checklist for the final stretch: what lock actually claims, what has to be true before anyone signs, and where readiness quietly fails.
What lock actually asserts — and how it differs from a freeze. When a database locks, the organisation is making a specific claim: that the data are as complete as they are going to be, that every known issue has been resolved or formally dispositioned, and that nothing will change without a controlled, documented unlock. Lock does not assert that the data are perfect. It asserts that the remaining imperfections are known, reviewed and recorded. That distinct
Query closure: closed is not resolved. The most common false comfort before lock is a query count trending to zero. Closed and resolved are different states. A query is resolved when the underlying data issue has been dealt with: the value corrected, confirmed correct with evidence, or documented as unresolvable with a rationale that will survive inspection. A query can be closed without any of that happening — closed because the site
Coding, vendor data and SAE reconciliation. Medical coding sign-off means more than a completed batch run. All adverse event, medical history and concomitant medication terms coded; dictionary versions recorded and consistent with the statistical analysis plan; uncodable or ambiguous verbatims either resolved through query or documented with a coding decision; and an explicit approval from whoever owns medical review of coding. Late verbati