Correction Events: Correcting Errors Without Overwriting History

A correction with a defined reference and effect

The term is used here as an umbrella for correcting a value, adding information, or reversing an earlier effect. Type, reason, and impact are specified separately.

This is a domain modeling principle, not a uniformly defined regulatory event class. What matters is an unambiguous reference to the original, justified new content, and the rules under which it takes effect. The following fictional example therefore separates correction of a measurement from its possible consequences for inventory.

Example: Correcting an incorrect dry weight

In a fictional example, an operator records a dry weight of 4,820 grams after a drying phase. The operation is linked to the batch, task, scale, unit, time, user identity, and work instruction. A plausibility check reveals that two digits were transposed when reading the value; the documented scale result is 4,280 grams.

The original measurement record is not changed. The authorized person starts a correction, selects “Correct measurement” as the operation type, gives “Transcription error” as the reason, references the measurement entry, and enters 4,280 grams as the corrected value. The documented reading is linked as supporting evidence. Because the value has already affected inventory, the process requires a second review.

After confirmation, the valid measurement is corrected to 4,280 grams. The difference from the earlier entry is minus 540 grams. Whether this entails an inventory correction of the same size must be checked against transactions already posted; the same difference must not be applied more than once. Dependent calculations are initially marked as requiring review. Only after reassessment is complete may they be considered reviewed. The history keeps the original capture, identified discrepancy, correction, and its review visible as separate operations.

An audit trail traces relevant changes in a controlled way. A correction event describes the narrower domain action through which a specific earlier record is corrected and its effect updated.

The correction needs an unambiguous reference

A correction is understandable only if the specific record it concerns remains identifiable. Simply stating “Value corrected” is insufficient when there are multiple measurements or transactions. The correction event should therefore contain a stable reference to the original entry.

Depending on the data model, it may refer to a single value, an entire operation, or a state derived from it. For a temperature measurement, for example, the specific measurement entry is referenced. For an erroneous release, by contrast, the correction may reverse the effect of an entire release operation.

Multiple corrections to the same entry must also remain ordered. The current view must not simply use “the latest value” if a correction has since been withdrawn, reviewed, or rejected. Event types and their permitted transitions determine which state applies in the operational context.

Distinguishing correction, addition, cancellation, and deletion

• Correction: An incorrect item is corrected with valid content supported by a traceable justification.
• Addition: Missing context is added without declaring the existing content incorrect.
• Cancellation: The operational effect of an operation is reversed; the operation itself remains identifiable in the history.
• Repetition: An activity or test is performed again and produces a new, independent result.
• Deletion: Data is removed or made inaccessible. Different technical, legal, and organizational rules apply.

These operations should not be represented through a universal “Edit” button. Different meanings require distinguishable event types, rules, and permissions. Only then can a later analysis identify what actually happened.

What information a correction event needs

The required content depends on the criticality of the affected data item. A reliable basic structure typically requires:

• its own event identifier to uniquely identify the correction;
• a reference to the original entry or the operation to be corrected;
• the previous and corrected content, insofar as needed for understanding;
• the correction type, such as correction, addition, cancellation, or reversal of an effect;
• a substantive reason in an understandable and verifiable form;
• the acting identity, including its role or system component;
• the time of correction and, where applicable, a different operational validity time or period;
• review or approval, if the process requires a second role;
• effects on dependent states, calculations, reports, or follow-up tasks.

Selection lists can support standardized reasons, but must not prevent a necessary explanation. Conversely, an unrestricted free-text field alone does not produce a consistent correction classification. A combination is often useful: a defined correction type, a structured reason, and an optional explanation.

What evidence supports the new value?

In the dry-weight case, the correction is based on the documented scale result. This is a different evidential basis from a later estimate or a new weighing. A repeated measurement may take place under changed conditions and must remain identifiable as a separate operation.

For data integrity, therefore, a completed correction form is not enough. The evidence must fit the affected operation, its provenance must be traceable, and it must actually support the change. If the cause remains unresolved, the description must not conceal that uncertainty behind an apparently precise standard reason.

Distinguishing recording time from operational validity

A correction is made at a particular time but may refer to earlier circumstances. These two times must not be conflated. The correction time establishes when the correction was actually recorded. The operational reference explains which operation or period the corrected content applies to.

A backdated overwrite would create the impression that the correct value had been known from the beginning. A separate correction event instead preserves the true chronology: first, information was recorded; later, its error was identified and corrected.

Late entries add a third perspective. The real operation may already have occurred before it is documented in the system. Event time, recording time, and, where applicable, correction time should then be kept separately. Only this allows sequence and delay to be assessed objectively.

Authorization, justification, and review remain separate controls

Not everyone should be allowed to correct every record. Permissions must fit the process and role. A person may, for example, correct their own input errors, while correcting a released test result requires an additional quality role.

The acting person's identity answers who acted. The reason explains why the correction was made. A review assesses whether it is substantively permissible and sufficiently supported by evidence. These three pieces of information must not be merged into a single status.

EU GMP Annex 11 requires changes to and deletions of GMP-relevant data to be recorded and their reasons documented; access rights should also be restricted to authorized individuals.^[4] This does not establish a single approval logic for every data type. That logic must be defined on a risk basis within the respective procedure.

Draft, confirmed record, and released state

Not every correction must follow the same formal workflow. Whether an entry may be edited directly also depends on whether a record subject to retention requirements has already been created. In the FDA CGMP context, data generated to satisfy a CGMP requirement becomes a corresponding record when it is generated. Calling it a “draft” does not remove these requirements.^[3] Editable preliminary stages must therefore be distinguished from records that already require preservation; necessary changes remain traceable.

Confirmation changes the situation. The record may already have affected material inventory, a batch state, a test result, or a follow-up task. A later change should then not be treated like correcting a typing error in a form that is still open. It needs its own operation and a defined effect.

Released data is particularly sensitive. If, for example, a value that formed the basis of a release is corrected, the original decision cannot automatically be assumed to remain valid. The correction should identify the affected state and trigger the prescribed assessment path. Depending on the risk, this may involve another substantive review, a temporary hold, or a new release decision.

Draft, confirmation, and release describe processing states. The correction controls required also depend on the type and purpose of the record, its previous use, and applicable requirements. Even a record that has not yet been released may already require preservation in full.

A correction must define its operational effect

Storing a new entry is insufficient if its effect on the current state remains unclear. The system needs rules determining whether the corrected value replaces the previous one, posts a difference, cancels an operation, or triggers another review.

For quantities, posting a difference is often useful: rather than setting an overall value again, the correction event describes the change. For text, a new version may apply. For decisions, a formal revocation followed by reassessment may be needed instead of a “new value.”

Event sourcing uses compensating events for this purpose. Microsoft describes them as new events that reverse or correct the effect of earlier events while the original events remain in the stream.^[5] A correction event can follow this pattern without the entire application using event sourcing.

Downstream effects must not remain hidden

A corrected input value may already have been used in calculations, reports, inventory states, or decisions. Correcting the source does not automatically update these results correctly in substance. First, it must become clear which dependent objects may be affected.

The system can create follow-up tasks, rerun calculations, or flag results for review. Whether another release is required is determined by the defined process. Automatic recalculation must not silently and retrospectively change a human decision already made.

External systems must also be included. If the original value has already been transferred, the interface needs an unambiguous correction operation or an agreed new version. Otherwise, source and target systems show different versions of the truth even though the local history has been extended correctly.

Why overwriting obscures the past

If an existing value is directly replaced, the record subsequently shows only the new state. Without additional history, it is no longer possible to establish that a different value existed before, when it was changed, or who made the change. This can remove a decisive part of the process history, particularly for measurements, material transactions, test results, and releases.

For relevant electronic changes, the MHRA and PIC/S require traceable preservation of original information and attribution of the change, time, and person.^[1][2] The FDA accordingly describes audit trails as secure, computer-generated, time-stamped electronic records that allow the creation, modification, or deletion of data to be reconstructed.^[3]

A correction event does not automatically meet these requirements. It initially provides a clear data structure in which the original and correction remain separate. Whether the record is sufficient also depends on the process, risk, permissions, justification, review, and applicable regulatory framework.

Correction events are themselves analyzable process data

An individual correction may be a normal human activity. If corrections accumulate for the same task, input type, or work instruction, they become a process signal in their own right. The events should therefore remain structured not only for reconstructing an individual case, but also for broader analysis.

Useful metrics may include correction frequency, time to detection, recurring reasons, affected data types, and required follow-up reviews. These values do not by themselves prove poor work. They initially help identify where input guidance, training, equipment integration, or process design should be reviewed.

The effectiveness of an improvement can also be observed. If manual transcription is replaced by a scale interface, for example, the subsequent trend in corresponding transcription errors can be compared. The correction history thus becomes material for learning without prematurely treating individual corrections as personal misconduct.

When a correction remains open

A new value may have been reviewed while its effect on an exported report remains unresolved. Conversely, a technical interface message may have been delivered without the receiving party having reassessed its decision. A single overall status would conceal these distinctions.

Completion should therefore show what has already been done, which consequences were reviewed, and which uncertainties remain. Setting a completion flag cannot rule out unknown dependencies. Deletion and retention also have their own procedures; a correction operation does not replace them.

From a corrected value to a completed operation

In the example, the difference of minus 540 grams answers only how much the recorded measurement changes. It does not yet establish which inventory needs adjustment or which decision must be reconsidered.

A traceable correction keeps these steps separate: an evidenced original, justified new content, an approved effect, and addressed consequences. Only then can a later review determine whether merely a value was replaced or the error and its actual effects were dealt with.