How would you design immutable audit trails in a LIMS?

Short answer

An effective LIMS audit trail is append-only from ordinary user workflows and records who did what, when, why and to which record, while preserving original values and linking corrections to approvals.

Why

Design domain events for sample creation, label changes, chain-of-custody updates, result edits and final release. Each event should capture a stable record ID, actor or service identity, reliable timestamp, action, old and new values where relevant, reason, application version and request or transaction correlation ID. Restrict administrative access and separate those who edit results from those who control audit infrastructure.

Make audit events tamper-evident with protected logging, backups, retention and controlled review. Avoid implying that a hash chain alone proves absolute immutability: privileged operators may still change storage unless organisational and infrastructure controls prevent or detect it. In regulated contexts, interpret retention, signature and audit trail obligations under the applicable predicate rules and 21 CFR Part 11 or EU GMP Annex 11 as relevant.

Test audit reconstruction with a deliberately corrected result.

Common mistakes

Mistaking a simple `updated_at` timestamp or user-editable change log for a complete audit trail

The interviewer might ask next

How would you detect and investigate an attempted administrator-level audit-trail deletion?