Record the event with its context
Electronic records can reduce transcription and make review more efficient. They also create dependencies on configuration, identity management, interfaces and long-term readability. The goal is not simply to replace paper with a screen. It is to preserve trustworthy evidence across the lifecycle of a batch and the systems that support it. That requires attention to the original data as well as the report assembled from it.
- CaptureIdentify the event and its source.
- ConnectRetain batch, user and equipment context.
- ReviewEvaluate exceptions and changes.
- PreserveMaintain access and meaning over time.
01 / Identity
Make attribution meaningful
People should act through appropriately assigned identities with permissions aligned to their responsibilities. Shared accounts undermine attribution because the record cannot reliably distinguish who performed an action. Privileged administration also needs control: the ability to configure a system or alter access can affect the reliability of every record it produces.
Electronic signatures should have a defined meaning, such as performed, checked or approved. A signature must remain associated with the relevant record. An image of a handwritten signature is not, by itself, a complete electronic-signature control. Training and procedural expectations are necessary alongside technical mechanisms.
02 / Integrity
Retain the complete evidence
ALCOA describes data that are attributable, legible, contemporaneous, original and accurate. The commonly used ALCOA+ formulation adds completeness, consistency, endurance and availability. These principles help teams ask practical questions: Was an event recorded when it occurred? Can the original context be recovered? Are failed attempts or excluded results still visible where relevant?
A PDF report may be useful, but it may omit metadata, processing settings or the ability to examine dynamic data. Record design should determine what constitutes the complete record for the activity. The answer depends on the system and intended use, not on a universal preference for one file format.
03 / History
Make changes reviewable
An audit trail records relevant actions and changes, commonly including who acted, what changed and when. Where required, the reason for a change should also be captured. An audit trail is only useful when its scope, protection and review process are appropriate. Merely enabling a feature does not demonstrate that all critical changes are covered.
Reviewers need access to understandable information and a procedure for assessing exceptions. Time synchronization and clear handling of time zones help reconstruct event order across systems. Clock discrepancies can create misleading sequences even when each individual application appears to work normally.
04 / Interfaces
Preserve meaning across boundaries
A batch identifier moving from MES to LIMS should retain its intended relationship to materials, samples and tests. Interface design should account for units, precision, status values and versioning. A successful transmission only confirms that a message moved; it does not prove that the receiving system interpreted it correctly.
Reconciliation checks can identify missing or duplicate transactions. Teams should also define what happens when a system is unavailable, how temporary records are controlled and how recovery avoids silent duplication. Manual intervention may be necessary, but it should remain attributable, authorized and visible in the final account.
05 / Review
Understand review by exception
Review by exception can focus attention on predefined departures instead of asking a reviewer to inspect every routine entry in the same way. Its usefulness depends on the completeness of the rules and the reliability of the underlying controls. If an important event cannot generate an exception, the absence of an exception says little about that event.
The review strategy therefore needs a justified scope, tested configuration and oversight when processes change. It should retain access to the underlying record. Automated checks can assist review, but they do not make an unexplained discrepancy acceptable or transfer accountability away from designated reviewers.
06 / Preservation
Plan beyond the working system
Backup supports recovery after loss or disruption. Archiving supports controlled preservation and retrieval over the required retention period. These purposes overlap, but they are not identical. A backup that has never been restored provides limited assurance, and an archive that cannot render its records may fail its practical purpose.
Migration and retirement planning should address data, metadata, signature relationships and audit trails. Retention requirements depend on the record category and applicable rules. Periodic retrieval checks help show that evidence remains usable. The end of a software contract is not the end of the obligation to retain required manufacturing records.
Terminology: audit trail versus event log
An event log may record technical activity. An audit trail supports the history of relevant record actions and changes. A system can contain both; their purpose, content and protection should be assessed rather than assumed from the label.
Terminology: original record versus true copy
An original record is the first or source capture of information in its relevant context. A true copy is verified to retain the required content and meaning. A simple export is not automatically a verified true copy.