Automated Compliance Evidence: How Evidence Is Created During Work

Evidence must support a specific statement

The running example uses material batch RM-318. It must be inspected according to work instruction WI-27, version 3.2, before it may be used in a subsequent process step.

During the inspection, a temperature reading of 6.4 °C is transferred from a connected measuring device. The responsible person also confirms that the packaging is undamaged. The role authorized to release the material then assesses the available information and releases RM-318 for use.

A collection of individual records still does not answer the later review question. The relevant evidentiary statement could be:

Material batch RM-318 was inspected according to WI-27 version 3.2; the transferred measurement was 6.4 °C, the packaging was confirmed as undamaged, and the batch was subsequently released for use by the designated authorized role.

The distinction matters. A measurement does not prove a release. A release without a link to the inspected object does not explain what the decision referred to. And a completed task does not by itself show which version of the governing instruction applied at that time.

Automated compliance evidence is therefore not simply an automatically generated PDF or a larger quantity of log data. The decisive question is whether actual execution produces a technically and operationally meaningful statement whose components remain connected.

From executed work to an evidentiary statement

For RM-318, the required information is not created in the same way. The object reference is already known because the task was opened for that batch. The applicable work instruction is assigned to the execution step. The measurement can be transferred technically. The packaging condition requires a human confirmation. The final release, in turn, is a separate decision by a designated role.

For evidence purposes, these elements are not captured again in a parallel documentation layer. They are combined into the statement that the real process is meant to support:

• RM-318 is the object of the inspection;
• WI-27 version 3.2 is the version used for the step;
• 6.4 °C and “packaging undamaged” are the documented inspection results;
• the release is the controlled decision that follows;
• the timestamp and assigned identity or role connect the statement to its actual execution.

These elements matter not because a record should contain as many fields as possible, but because omitting any one of them would create a different or weaker statement. If the applicable instruction version is missing, it may later be impossible to show which requirement governed the inspection. If the release can no longer be linked to RM-318, the object of the decision remains uncertain.

Individual actions are recorded as process events with their respective context. For evidence creation, these pieces of information must be combinable into a statement describing the specific review-relevant operation.

An Electronic Batch Record brings together the complete electronic record of an executed batch. An individual evidentiary statement may draw on parts of that record, but does not replace the complete batch record.

Regulations require timely records and a complete context

The extent to which this type of evidence creation is required depends on the regulated market and the specific process. In pharmaceutical GMP environments, however, several primary sources express a common design principle: records should not be reconstructed later from memory or temporary intermediate states.

EU GMP Chapter 4 states in section 4.8 that records should be made or completed at the time each action is taken and that significant manufacturing activities should remain traceable.^[1] From a system-design perspective, this does not mean that every work step should generate the maximum possible amount of data. It means that the record required to support the later statement should be created where the action actually takes place.

The FDA’s Data Integrity guidance explicitly addresses when electronic data becomes a CGMP record. Data generated to satisfy a CGMP requirement becomes a CGMP record and must be documented or saved at the time of performance. The FDA gives, as one possible technical example, a system that automatically saves after each entry.^[2] This is directly relevant to evidence creation: a later summary does not automatically replace the record that should already have been created at the time of the action.

The MHRA addresses the same design issue from the system side: records should be available where activities take place so that informal recording followed by later transcription does not occur. For critical steps in computerized systems, execution should be recorded contemporaneously, and multiple unit operations should not be unnecessarily combined into one transaction that is only saved later. ^[4] For evidence design, this does not require maximum logging depth; it requires the necessary record to be created as part of the work step itself.

PIC/S PI 041-1 also addresses hybrid systems in which manual and electronic components work together. Section 9.10 requires review procedures to describe, among other things, how electronic and paper-based data are correlated to form a complete record.^[3] This reflects the other side of the same task: even if every individual item exists, it must remain clear how those items belong to the complete process.

These sources do not mandate a specific software architecture. They do, however, explain why later reconstruction from separate information silos is weaker than a design in which the relevant context is preserved during execution.

Data capture can be automated — not every substantive assessment

For RM-318, the object reference, timestamp, applicable version and measurement can enter the process largely without repeated manual entry. A status change can also be triggered technically once the intended decision has been made.

PIC/S distinguishes between manual and automated data capture. For automated capture, the interfaces between the originating system, data acquisition and the recording system should be validated; captured data should be stored in a protected form and checked for completeness, including relevant metadata. ^[3] Automation can therefore avoid repeated entry, but it does not perform the substantive assignment of the measurement to RM-318 or the subsequent release decision.

The system cannot thereby automatically determine whether damaged packaging is technically acceptable or how a contradictory piece of evidence should be assessed. Likewise, release remains a substantive decision where the process assigns responsibility to a human role.

Automated evidence creation should support and document that decision, not silently replace it with data capture. With Human in the Loop, the reviewer must actually be able to intervene at this decision point; merely recording their confirmation is not enough.

Completeness depends on the statement, not on the amount of logging

A system may store thousands of technical events and still fail to answer a simple operational question. For RM-318, additional system messages about page views, internal API calls or background jobs are relevant to the evidence only if they actually matter to the statement being supported. A statement about batch traceability, in turn, requires the actual material uses connecting input and output batches; release of RM-318 alone does not establish those subsequent relationships.

Conversely, a seemingly small missing relationship can be decisive. If the 6.4 °C reading exists but can no longer be reliably assigned to batch RM-318, the release statement cannot be repaired by adding more unrelated log data. The same applies if it is no longer clear which version of the work instruction governed the inspection step.

Completeness therefore does not mean “store everything.” It means that the specific evidentiary statement is supported without speculative intermediate steps. Whether the underlying data remain complete, consistent, accurate and available across their lifecycle is the broader task of data integrity.

Corrections must extend the evidentiary statement

Assume that after release it is discovered that an incorrect container number within the same batch was confirmed by mistake. The correction must not replace the original process as though it had never occurred.

Instead, the evidentiary statement is extended: what was originally confirmed, what was later corrected, why the correction was necessary, and whether it affected the release decision already made.

Correction Event keeps original and corrected information in context.

The Audit Trail makes relevant changes and their review traceable.

For automated evidence creation, the consequence is sufficient here: evidence remains understandable only if relevant corrections and their effects can become part of the statement rather than making the earlier state disappear.

External verification is an additional evidence layer

A substantively complete evidentiary statement can additionally be made technically verifiable against an independent reference point. This can, for example, show whether a data sequence presented later still corresponds to a reference value secured earlier.

This additional verifiability does not change the substantive statement itself. A technically unchanged dataset may still be incomplete, incorrectly assigned or unsuitable for the intended purpose. Conversely, a fully traceable process may, depending on the applicable requirement, be properly documented without an external anchor.

An independent reference point can add technical verifiability through external data verification. For automated compliance evidence, the two levels remain distinct: substantive completeness emerges from the process; technical verification can complement later review.

Where automated evidence creation reaches its limits

Automation shifts error sources; it does not eliminate them. If a measuring device is assigned incorrectly, an automatically transferred reading can still be attributed to the wrong object. If an outdated work instruction is configured as the applicable version, automated version capture will document the wrong version very reliably. And if an identity is shared or a role has been assigned incorrectly, a precise timestamp does not automatically make responsibility correct.

Determining what is relevant to the evidence in the first place also remains a matter of domain design. A process can only capture in structured form what was considered in its modelling. Unexpected situations, contradictory information or qualitative observations may require additional assessment and documentation.

Finally, automation must not result in an interface that shows only a finished evidentiary statement while hiding its basis from the responsible person. Anyone who releases a batch or assesses a deviation must be able to review the relevant information in an appropriate form.

A generated evidentiary statement is therefore not self-validating. For GxP data, the MHRA calls for a risk-based, documented review that includes relevant metadata; the review record should state whether issues were found, when the review was performed, and who confirmed it. ^[4] PIC/S likewise requires defined review procedures for critical electronic data and places review of relevant audit-trail information within routine data review before the data are relied upon for a critical decision such as batch release. ^[3]

Automated evidence creation is therefore strongest when it reduces routine data capture and preserves context without obscuring domain responsibility.

A simple review question for evidence design

For RM-318, it should later be possible to answer the following without manual reconstruction:

What happened to which object, under which version applicable at that time, with what result, by which person or role — and what controlled decision followed?

If the system can answer this question only after data from several sources have been manually collected, chronologically ordered and connected in substance, the evidence is largely being created only at the time of review.

If the statement can instead be traced directly from the actual work process, evidence creation has become part of process execution.