ALCOA++: Why “Traceable” is now explicitly part of Data Integrity

ALCOA++ is often encountered at the most inconvenient times: during an investigation, audit, or meeting when the question pops up that seems to be the simplest of all: “Who did this, and when?”

It is all straightforward at first. After all, these are the standard ALCOA checks. If the record is attributable and contemporaneous, then we should be able to identify a person, a date, and a record created at the appropriate time.

However, the conversation does not end here. After the initial ALCOA questions are satisfied, the subsequent ones are always more difficult. The discussion changes from the record itself to the history of the record:

• Was that the entire data set or just the final report?
• Was that data set repeated, aborted, injected with errors, or results excluded?
• Is that record consistent with other systems?
• Will that data set be available quickly next week... or next year?
• If changes were made, will we be able to reconstruct the changes and the reasons behind those changes?

This is the part of the process where the distinction between ALCOA, ALCOA+, and ALCOA++ is evident. Not as different “levels of compliance,” but as different concentric circles of expectation: from trustworthy capture to complete retention to re-constructible history through the data set's entire life cycle.

A historical parallel is aviation before and after “black boxes.” In the early days, investigations relied on signed maintenance logs, pilot reports, and paperwork—credible and attributable records (ALCOA), but often not enough to reconstruct the final minutes of a flight. Flight data and cockpit voice recorders added the “++” element: a time-sequenced, retrievable record of what changed, when, and in what order—available when needed and traceable across the event—turning plausible narratives into demonstrable timelines.

ALCOA, ALCOA+, ALCOA++: What really changes?

ALCOA: Can we trust the record at the time of creation?

ALCOA is focused on whether the original record is trustworthy at the time of its creation. During an investigation, ALCOA answers the basic questions:

• Can we identify who created this record and tie it to a real person (not a shared identity)?
• Can we see when it was created and was it created at the time of the activity or later?
• Can we read it, interpret it, and be assured it accurately reflects what happened?
• Do we have the original record or an acceptable true copy, not a reworked representation or summary?

In short, ALCOA is about establishing credibility of the record and its source. If you stop at ALCOA, you can demonstrate that a result was recorded accurately but not necessarily demonstrate that you have all the context about what was going on about that result.

ALCOA+: Is the record complete and durable, not simply credible?

ALCOA+ extends from “Is this record trustworthy?” to “Is this record set whole and defensible?”

This is where investigations start to delve into issues like:

• Completeness: Do we have all data related to this activity, including any repeats, failures, trials, and ancillary data?
• Consistency: Do dates, times, IDs, and versions match up across the chain (sample to instrument to LIMS to report)?
• Enduring: Will this record endure for its full retention period without being overwritten or lost during system migrations or upgrades?
• Available: Will it be retrievable or can it be accessed in practice, not simply stored?

ALCOA+ is where the more critical question begins to be asked:

“Are we looking at everything or simply what made it into the final report?”

This is also the point at which many organizations begin to feel the tension between the paper era and the digital era. Data is no longer just that line on the form. It is now scattered across the system, the interfaces, the exports, the PLC’s, the audit trails, and in some cases, the service providers. The ‘record’ is now a collection, and the ALCOA+ criteria address the question of whether that collection is complete, consistent, and durable.

ALCOA++: can we retrieve it when it matters, and reconstruct what happened?

ALCOA++ brings two ideas to the forefront because modern systems make these concepts impossible to treat as “implicit.”

Available becomes “available when needed.”

This is not just semantics. It is a practical requirement. Data that takes days to retrieve, depends on one person who knows where it lives, or requires vendor intervention every time it is needed is not “available” in the way an inspector or a deviation team means it.

Traceable becomes explicit.

Traceability is the point where you move from “we have the data” to “we can prove the data’s history.” It is the ability to reconstruct events across the lifecycle:

• what was done, in what order
• what changed, and when
• who changed it
• under what role/permissions
• and why (where justification is required)

ALCOA++ is where the discussion shifts from record-keeping to reconstructing reality in complex, electronic, distributed processes.

A routine lab day that becomes an ALCOA++ problem

Imagine a familiar Quality Control process. An analyst gets a sample, prepares it, runs it, and writes down the results. It was within specification. It was a typical day.

Weeks later, while trending the data, the out-of-range signal appears. QA asks for the raw data to understand what is going on. The analyst retrieves the report and provides the chromatograms. It looks good at first glance.

But the questions begin. First come the ALCOA questions. Who ran it, when, and is it attributable? That is easy.

Then come the ALCOA+ questions: Is it the entire data set, every injection, every repeat, every aborted run, the entire context necessary to understand the outcome? Is the identifier consistent between the instrument software and the reporting system? Can we prove the entire record set exists?

And then comes the moment that often marks the line between “we document well” and “we control data well”:

“Where is the electronic raw data?”

The answer might have been on the instrument’s PC, or it might have been on the instrument’s PC last week. The answer might be that the instrument’s software overwrote the older files. The answer might be that IT decided to reimage the instrument’s PC. The answer might be that the relevant folder was never backed up in the first place. The answer might be that the files exist, but access is restricted to a shared vendor account, and no one knows who the last person was to enter the password.

None of the above implies anything untoward. None of the above implies any lack of intent. None of the above implies any lack of documentation. What it implies is the gap that ALCOA++ is intended to identify: not the ability to generate a nice-looking report, but the ability to retrieve the underlying data.

When organizations realize the gap, it’s not because they didn’t understand ALCOA. It’s because they thought they had met the requirement, while in fact the risk was in the lifecycle.

Why “traceable” is no longer optional in digital processes

In the world of paper, traceability is somewhat obvious. When someone makes a correction, it’s obvious because you can see the original, the strike-through, the initials, the date, and the reason. The story should be on the page itself, right next to the original data.

In the world of digital processes, traceability is not obvious. It’s not automatic; it’s not inherent in the system. It’s dependent on the system, the process, the governance.

You can have traceability, but if nobody checks the audit trails, then you do not really have traceability. If the administrator has the ability to modify data without reason capture (or strong controls), you may create a record, but not a record that convincingly tells a story.

If changes to configuration are not under control and traceability, then the “data” may be preserved, but the “meaning” of the data is not.

This is why ALCOA++ includes traceability. Data integrity is now just as much about the data’s metadata and the system’s behavior as it is about the data entered into a field.

The shift: From “documentation” to “data lifecycle”

A way to keep all the acronyms straight is to realize where each tends to place the emphasis:

ALCOA places the emphasis on the point of data capture and the credibility of the source document.

ALCOA+ asks you to think about the record set—was it complete, consistent, durable, and retrievable?

ALCOA++ takes you on a journey along the time line—can the record be retrieved when needed, and can we reconstruct what happened?

Conclusion

ALCOA is the foundation: a good record made the correct way.

ALCOA+ is the extension: the record set must be complete, consistent, durable, and retrievable.

ALCOA++ is the stress test: can we retrieve the record when we need it and recreate what we did to make it?