Data Integrity and ALCOA+

📍 Where we are: We have learned to move data between systems with structure and meaning; now we ask the harder question — can we trust the record once it arrives?

The previous chapter, Connectivity and Interoperability Standards, showed how biomanufacturing data flows between machines and partners — OPC UA, MTP, SiLA 2, AnIML and Allotrope, B2MML/ISA-95 — and drew a sharp line between moving bytes and preserving meaning. But there is a deeper line still. A record can arrive perfectly formatted, semantically rich, and completely untrustworthy. If a sensor reading was quietly edited, if a failing test was repeated until it passed, if two operators shared one login so nobody knows who did what — then the data is a polished lie. This chapter is about making data true, not just transmittable.

The simple version

Think of data integrity like the chain of custody for evidence in a courtroom. It is not enough that the evidence exists — you have to prove who handled it, when, that it was never tampered with, and that what the jury sees is the genuine article. A batch record is the evidence that a medicine was made correctly. Data integrity is the chain of custody that makes that evidence believable.

What this chapter covers

We will define data integrity and why regulators treat it as the foundation of product quality. We will unpack ALCOA+ — the nine attributes of trustworthy data — as nine design requirements and watch them collapse into the columns of a single audit-trail record. We will tour the common ways data integrity fails and how an ALCOA+ architecture defeats each one, the global wave of guidance that converged to address it, the idea of building integrity in by design rather than policing it after the fact, and the genuinely unsolved problem of holding integrity together across organizational boundaries in real time.

What data integrity means, and why it is the foundation

Data integrity is the degree to which data is complete, consistent, and accurate throughout its entire life — from the moment it is created, through processing and storage, to eventual archiving and retrieval [2]. That life cycle is the subject of its own chapter, The Life Cycle of a Data Point; here we ask not where a value travels but whether each stage of that journey leaves it trustworthy. Regulators do not treat this as a clerical nicety. They treat it as the bedrock of product quality, because the evidence that a medicine was made safely is, in the end, the data generated while making it. A patient cannot inspect an antibody. A regulator cannot re-run a year of manufacturing. Both must rely on the record. If the record cannot be trusted, then no claim about safety or efficacy can be trusted either [1].

The World Health Organization frames it plainly: assuring data integrity requires appropriate quality and risk management systems, and good documentation practices, applied across the whole data life cycle [4]. The European Medicines Agency goes further, calling data integrity a fundamental requirement of the pharmaceutical quality system that applies equally to paper and electronic records, and a responsibility of senior management and the organization's quality culture [5].

ALCOA and ALCOA+: the anatomy of trustworthy data

ALCOA+ as nine design requirements

It helps to read ALCOA+ not as nine adjectives to admire after the fact, but as nine design requirements a system must satisfy before it writes its first record. Each attribute below ends up as a concrete column, constraint, or control somewhere in a database — which is exactly how the open-source implementation in Building ALCOA+ Integrity in Code renders them: nine attributes become the columns of one audit-trail table. Read the list, then read the table.

The acronym ALCOA was coined inside the U.S. FDA in the 1990s by Stan Woollen, an official working on Good Laboratory Practice (the rules, under 21 CFR Part 58 — Title 21 of the U.S. Code of Federal Regulations — for non-clinical safety studies, the animal and laboratory studies done before a drug is tested in humans), as a personal mnemonic to organize his own presentations on what good data looks like — originally as a data-quality aid that later guidance adopted as the backbone of data integrity [8]. It stands for Attributable, Legible, Contemporaneous, Original, and Accurate. Later guidance added four more attributes — Complete, Consistent, Enduring, and Available — giving ALCOA+ [2]. Here is each one, grounded in a bioreactor — the controlled vessel in which living cells are grown to make the drug.

• Attributable — you can tell who did or recorded something, and when. When an operator adjusts the feed rate, the record must name that person. This is why shared logins are forbidden, and why an electronic signature — legally equivalent to a handwritten one when the required controls are met — has to show, in plain readable form, the signer's printed name, the date and time, and the meaning of the signature (such as reviewed, approved, or authored) [3]. The full machinery of binding electronic signatures — uniqueness, non-repudiation, and the signature manifest — is the subject of the next chapter; here it matters only as the human face of Attributable.
• Legible — the record is readable and permanent, and stays so for its whole retention period. A pencil entry that can be erased, or a file format no one can open in ten years, fails this test [7].
• Contemporaneous — the record is made at the time the work happens, not reconstructed from memory hours later. A pH reading logged when it was taken, not back-filled at end of shift [2].
• Original — the data is the first capture (or a verified "true copy" of it), not a transcription. The chromatography instrument's own raw data file is original; a number hand-copied into a notebook is not [1].
• Accurate — the data is correct, truthful, and free of errors, reflecting what actually happened [4].

The four "plus" attributes round out the picture, each grounded in the same bioreactor [2]:

• Complete — nothing deleted, including failed runs and repeats: the chromatography run that failed system-suitability is retained, not silently dropped.
• Consistent — events in true chronological order with synchronized clocks: a feed adjustment recorded after the pH excursion it answered, never before it.
• Enduring — recorded on durable media that outlast the moment: the batch record lives in a validated historian and database, not a sticky note or a local spreadsheet.
• Available — retrievable for review throughout its retention lifetime: any reviewer or inspector can pull the record years later, not just the analyst who created it.

These four are not afterthoughts — the later sections of this chapter land on them directly: the before-after pair is Complete, and the immutable sequence is Consistent.

Who, when, and why: the attribution triple

The mechanism that ties Attributable and Contemporaneous together — and protects the Original by logging every change to it — is the audit trail: a secure, computer-generated, time-stamped record of who did what, when, and (where relevant) why. It is protected so it cannot be switched off or quietly altered, and any change to it is itself recorded [3]. Concretely, a single audit-trail entry records the field changed, its old and new values, who made the change, the exact timestamp, and the reason — for example, on the campaign's lot BATCH-2026-001: glucose_g_l changed from 4.10 to 4.85, qc_flag from fail to pass, by app_user jdoe on 2026-06-13 14:07:22 UTC; reason: deviation DEV-2207 correction. An audit trail turns "trust me" into "check the log."

That timestamp is only as trustworthy as the clock behind it. The system synchronizes its clocks via NTP (the Network Time Protocol), with high-rate processes that need sub-second cross-device ordering using PTP (Precision Time Protocol, IEEE 1588); every timestamp is stored in UTC and sourced from the operating-system or database clock, not settable by the application account that writes the row. That is exactly what defeats the back-dating failure mode described later: the writer can supply a value and a reason, but it cannot supply the time.

The heart of every such entry is an attribution triple: who, when, and why. The who must be a single named human, never a shared account — and in practice it is split in two, because the database role that physically wrote the row (a service account — the machine identity the software runs under, not a person) is rarely the person who authorized the change. The when must come from a clock the writer cannot reset. The why is the column inspectors reach for first, because a value that changed without a documented reason is a value that invites the question regulators most want answered. These same three facts are where data is born and first attributed — see Where Data Is Born for the moment of capture that the audit trail then has to protect.

The before-after pair: preserving the original

Attribution tells you who and why; it does not, by itself, preserve what the value used to be. That is the job of the before-after pair — storing both the prior state and the new state of a changed record, not merely a note that it changed. A diff ("glucose: 4.10 → 4.85") is fragile and easy to misread; a full before-and-after image of the record is unambiguous and is what Original and Complete together demand. When a failing result is corrected, the failing value does not vanish — it is preserved as the "before," and the correction is the "after," each carrying its own reason. This is precisely why a deletion is itself a logged event: removing data is a change like any other, and the original must survive it.

The immutable sequence: order you cannot forge

The last guarantee an audit trail must give is order. If a determined insider can reorder rows, splice one in, or quietly drop a middle entry, then Consistent — events in true chronological order — fails even when every individual row looks perfect. Two design moves defend the sequence. First, the order of history is assigned by the database, not the writer: a monotonic sequence number (one that always increases and never repeats) the application cannot override. Second, each row is cryptographically linked to the one before it — a hash chain, in which a cryptographic hash (a short, fixed-length fingerprint computed from data, such that changing even one character of the input yields a completely different fingerprint; SHA-256 in the companion implementation) of the prior row's hash plus this row's payload and timestamp is folded into the current row — so that deleting, reordering, or relinking any row breaks the chain and a verifier can point at the first row where the links stop adding up. The open-source chapter implements exactly this with a prev_hash/row_hash pair and a verify_chain() function; the dissection below shows the record those columns live in.

This makes tampering detectable, not impossible. A privileged database superuser can still disable the trigger or rewrite the table outright, which is why off-box log shipping (copying the trail to storage the writer cannot reach), separation of duties, and restricted admin accounts — all procedural controls — must back the chain. The hash chain catches the ordinary insider; it does not, by itself, stop the one who owns the database.

Anatomy of an audit-trail row

The four ideas above — attribution, contemporaneity, the before-after pair, and the immutable linked sequence — all land in a single record. The figure dissects one row of an append-only audit-trail table (one you can only add rows to, never edit or delete), the audit.change_log of the companion implementation, and maps its twelve columns onto the nine ALCOA+ attributes. Read it as ALCOA+ rendered in columns: the first seven say what, who, and when; the next three carry the before, after, and why; and the last two are the chain link that makes the whole sequence tamper-evident. This is the concrete SQL row that the abstract attributes become — the exact artifact taken apart field by field in Building ALCOA+ Integrity in Code.

One audit.change_log row as an identity card: twelve columns capture who changed what, when, and why, the full before-and-after image, and the hash-chain link (prev_hash then row_hash) that binds the row to the one before it — ALCOA+ made concrete. Original diagram by the authors, created with AI assistance.

The ALCOA+ life cycle: every event is captured, attributed, and reviewable — so the final record can be trusted. Original diagram by the authors, created with AI assistance.

A controlled cleanroom. Just as the physical environment is controlled to protect the product, data controls protect the integrity of the record that proves it. Cleanroom. Image by UCL Mathematical and Physical Sciences, CC BY 2.0, via Wikimedia Commons.

The same record, formally modeled: PROV-O, SHACL, and SPARQL

The attribution triple and the before-after pair are not just a good database schema; they are an instance of a standard, machine-readable model of provenance — the formal record of who or what produced a fact, from which activity, using which inputs. The W3C PROV-O vocabulary (the Web Ontology Language ontology for provenance) gives the attribution triple its exact terms: a prov:Agent is the named actor, an prov:Activity is the change event that happened in time, and the value the activity produced is prov:wasAttributedTo that agent, stamped with the moment it was made by prov:generatedAtTime and tied to the value it superseded by prov:wasDerivedFrom. The who, when, and why this chapter keeps returning to are, in PROV-O, prov:wasAttributedTo, prov:generatedAtTime, and an activity whose inputs (prov:used) are the prior values it acted on — the same shape, written so a machine in any other system can read it. Book 4 carries a real one for the running campaign: a curated reconciliation of two source systems modeled as a prov:Activity that prov:used two attributed claims, recorded so a stranger years later can see not only the fact but who asserted it — the discipline laid out in Conceptualization: Relations and Genealogy and exercised in Maintenance: Publication and FAIR. ALCOA+'s "attribute every change" is precisely PROV-O's job, applied to a manufacturing record.

If PROV-O is the vocabulary, a SHACL shape (Shapes Constraint Language — a language for stating, and automatically checking, that graph data has the required structure) is the gate that enforces ALCOA+ Complete and Consistent before a record is allowed to claim it is done. Where a SQL NOT NULL constraint enforces presence one column at a time, a SHACL shape closes the world over a whole record: it can say, in one declaration, that no change is valid unless it carries a named human and a reason — exactly "no change without a who and a why." A constraint like sh:minCount 1 on the app_user property and on the reason property is the Complete requirement made executable; a SPARQL-based constraint (sh:sparql, which lets a shape flag any row whose timestamp falls out of step with its database-assigned sequence number) is the Consistent requirement — events in their true order — turned into a rule the graph checks rather than a hope the reviewer remembers:

# A SHACL shape as the closed-world ALCOA+ gate: no change without a named person AND a reason.
ex:ChangeRecordShape a sh:NodeShape ;
    sh:targetClass ex:ChangeRecord ;
    sh:property [
        sh:path ex:app_user ;
        sh:minCount 1 ;
        sh:message "Complete: every change must name the human who authorized it." ] ;
    sh:property [
        sh:path ex:reason ;
        sh:minCount 1 ;
        sh:message "Complete: every change must carry a documented reason." ] .

The audit.change_log row mapped onto W3C PROV-O terms, with a SHACL NodeShape that requires sh:minCount 1 on both app_user and reason — ALCOA+ Complete as a closed-world gate, no change without a who and a why. Original diagram by the authors, created with AI assistance.

This is the same closed-world discipline Book 4 builds for the release decision: a missing required fact is treated as a failure now, not an open question — see Validation: The Release Gate and SHACL, where the same machinery refuses to release a lot whose record is incomplete or unsigned.

And once the audit trail is a graph rather than a table, the regulatory obligation to review it — developed below in Audit-trail review as a regulatory expectation — becomes an answerable competency question (a plain-English question the data must be able to answer, run as a query). "Who changed glucose_g_l on BATCH-2026-001, when, and why?" is no longer a reviewer leafing through a logbook; it is a SPARQL query (the standard query language for graph data, as SQL is for tables) that returns the exact rows, attributed and time-stamped:

# Audit-trail review as a competency question: who changed glucose_g_l on this batch, when, and why?
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX ex:   <https://example.org/audit#>
SELECT ?who ?when ?reason WHERE {
  ?change a ex:ChangeRecord ;
          ex:batch         ex:BATCH-2026-001 ;
          ex:field         "glucose_g_l" ;
          prov:wasAttributedTo ?who ;
          prov:generatedAtTime ?when ;
          ex:reason        ?reason .
} ORDER BY ?when

The point is not that every plant must adopt RDF — most enforce these same guarantees in a relational database, as the companion implementation does — but that ALCOA+'s who/when/why and its complete/consistent are not loose prose. They map cleanly onto a settled semantic standard, which is why the audit trail and the release gate Book 4 models are the same idea expressed in two layers: PROV-O says what kind of thing each fact is, and the SHACL shape enforces that it is present and well-formed before the record is trusted.

When a change becomes an investigation: the deviation record

A single corrected value is a row in the audit trail. But when something departs from the approved process — a feed pump that ran out of spec, an out-of-specification (OOS) assay result (an assay being a laboratory test that measures a property of the product), a clean-room excursion — that change is the start of a formal record of its own: the deviation record (and, when the fix is a permanent process change, the corrective and preventive action, or CAPA, that follows from it). This is where the chapter's recurring promise — that a good data architecture turns an investigation from weeks into minutes — is actually paid off, because the deviation record is only fast to assemble if every fact it needs is already attributed, time-stamped, and linked.

Read the deviation record as another anatomy card. Like the audit-trail row, it has fixed fields, and like that row its value comes from what it links to rather than what it stores in isolation:

• Deviation ID (DEV-2207) — the human-facing handle that the audit-trail reason column points back to, so a reviewer can pivot from "why did this value change?" to the full investigation in one hop.
• Batch ID (BATCH-2026-001) — binds the deviation to the campaign lot, and through the lot's genealogy to every upstream material and downstream result the event could have touched. A deviation with no batch is an orphan.
• What happened, when, and who detected it — the same attribution triple the audit trail carries, now at the level of an event rather than a field: a contemporaneous description, a UTC timestamp, and a named human, never a shared account.
• Linked records — the audit-trail rows, raw instrument files, and analytical results that are the evidence. The investigation does not re-key these facts; it references them, so the original capture is what gets reviewed, satisfying Original.
• Root cause, impact, and disposition — the analytical conclusion: what failed, what product it affected, and whether the batch is released, reworked, or rejected.
• CAPA reference — the forward link to the corrective and preventive action, closing the loop so the same deviation cannot recur unnoticed.

The discipline that ties this to ALCOA+ most directly is the handling of an OOS result. When an assay returns a failing number, that failing number is data — it is Original, it is Complete, and it cannot simply be retested away. A confirmed-or-overturned OOS investigation keeps the failing result on the record alongside any valid retest, each with its own reason, exactly as the before-after pair keeps a corrected value's "before." This is the generalization of "testing into compliance" stated positively: the failing result is data too, and a trustworthy record is the one that kept it.

So far the running examples have been upstream — a feed rate, a pH reading, a glucose correction in the bioreactor. But integrity-critical records live across the whole process, and the downstream purification train carries some of the sharpest cases. Consider the viral-filtration filter-integrity test on BATCH-2026-001's drug-substance lot. Viral filtration is a size-based removal step (a small-pore membrane that physically retains virus particles), and its claimed viral clearance is only valid if the membrane was intact — so a post-use integrity test (typically a gas-pressure-decay or bubble-point measurement) is run on every filter, and the result is a record on which the lot's viral-safety claim depends. That test result is exactly the kind of value an operator must never be able to repeat-until-pass: a filter that failed its integrity test cannot be retested into a pass any more than a failing assay can, because a marginal or failed integrity result is the signal that the clearance the batch is counting on may not be real. The same is true at the cation-exchange (CEX) polishing step, where a charge-variant main-peak result outside its release window — a sign the antibody's post-translational modifications have drifted — opens an OOS investigation, and at UF/DF (ultrafiltration/diafiltration, the concentrate-and-buffer-exchange step), where a final protein-concentration reading sets the dose per vial. Each of these is a single value, captured once, that the release decision leans on; each must carry its attribution triple, survive as the "before" if it is ever corrected, and stay on the record if it fails. The audit-trail architecture does not care whether the value came from a bioreactor probe or a filter-integrity tester — the Original and Complete guarantees are the same all the way down the train.

A deviation and CAPA record as an anatomy card: its fields are mostly links — to the batch and its genealogy, to the audit-trail rows, to the raw files, and to the OOS result — which is why a well-linked architecture turns a weeks-long investigation into a minutes-long query. Original diagram by the authors, created with AI assistance.

How data integrity fails

Knowing the rules makes the failure modes easier to spot. Regulatory guidance and years of inspection findings point to a recurring cast of problems [1][3]:

• Shared logins. When several people use one account, attribution collapses — you cannot tell who made an entry, defeating Attributable [1].
• Disabled or unreviewed audit trails. If the audit trail is turned off, or switched on but never examined, changes go unseen — which is why guidance now expects audit trails to be reviewed, a point developed below in Audit-trail review as a regulatory expectation [1].
• "Testing into compliance." Repeating a test until a passing result appears, then reporting only that result and discarding the failures. FDA explicitly prohibits this; deleting the failing runs violates Complete and Original [1].
• Uncontrolled spreadsheets and hybrid records. A result lives in an Excel file or a printout with no audit trail, so the official record and the working record diverge and no one can tell which number is authoritative — defeating Original and Complete [1][2].
• Unofficial or aborted injections. On a chromatography data system (the software that runs a lab instrument which separates and measures a sample's components), running a trial injection — one analysis of a sample — to preview a result and then deleting or not saving it, or reprocessing a sequence (a queued batch of injections) without the audit trail capturing it — defeating Original, Complete, and Contemporaneous [1][2].
• Orphaned data. Results recorded under no batch, no sample, or no clear owner — data with no home that cannot be reconciled with the official record [3].
• Clock manipulation. Changing a system clock to back-date an entry, or running unsynchronized clocks so the true order of events is unknowable, attacks Contemporaneous and Consistent [3].

caution

Many of these failures are not dramatic fraud. They start as shortcuts under deadline pressure — one shared password "just for tonight," one re-run "because the column was equilibrating." A healthy data-integrity culture makes the honest path the easy path, so the shortcut is never tempting [7].

How shared logins, disabled audits, and back-dating fail by design

The failure modes above are not independent curiosities; each is the exact attack that one of the design requirements is built to defeat. Put the naive system and the ALCOA+ architecture side by side and the pattern is clear: the shortcut that silently succeeds when integrity is left to goodwill is prevented or made tamper-evident when integrity is built into the database. A shared login cannot write a nameless row when every account is a unique identity stamped onto the record. A failing run cannot be deleted away when the log is append-only and the failing value lives on in the before-image. A back-dated entry cannot forge the timeline when order is fixed by a database-assigned sequence and a hash chain that breaks on any reorder.

The same three shortcuts, left to goodwill versus built into the system: the database, not the operator's discipline, decides what can be written and in what order. Original diagram by the authors, created with AI assistance.

The guidance wave that reshaped the industry

In the 2010s, a string of high-profile data-integrity findings prompted regulators worldwide to publish convergent guidance. The result is a remarkably consistent global expectation [6]:

Guidance	Body	Year
Questions and Answers: GMP — Data Integrity [5]	EMA (EU)	2016
Data Integrity and Compliance with Drug CGMP: Q&A [1]	FDA (US)	2018
'GXP' Data Integrity Guidance and Definitions [2]	MHRA (UK)	2018
Guideline on Data Integrity (TRS 1033, Annex 4) [4]	WHO	2021
Good Practices for Data Management and Integrity (PI 041-1) [3]	PIC/S	2021

These guidance documents do not stand alone — they interpret and reinforce the binding regulations beneath them. In the United States, electronic records and electronic signatures are governed by 21 CFR Part 11; in the European Union, computerized systems used in manufacturing fall under EU GMP Annex 11. The data-integrity guidance explains how to satisfy those rules in practice, which is why the two are usually read together (the next chapter takes up Part 11 and Annex 11 directly).

note

Although these documents come from different agencies, they say strikingly similar things: define ALCOA+, govern data across its full life cycle, apply controls commensurate with risk (more rigor for data that affects patient safety), and treat integrity as a quality-culture responsibility led from the top [3][4]. A company that satisfies one is largely aligned with all.

Integrity by design

Building integrity in: technical vs behavioral controls

The most important shift in modern thinking is that integrity should be built in, not inspected in [6]. The guidance distinguishes two layers of control. Technical (system) controls are enforced by the computer itself: unique user accounts, role-based access, synchronized system clocks (time sync), audit trails that cannot be switched off, and routine audit-trail review [2]. Behavioral (procedural) controls are enforced by people: training, good documentation practices, and an open culture where staff feel safe reporting errors rather than hiding them [7]. Technical controls are stronger because they do not depend on willpower — but neither layer alone is enough [3].

The reason both layers are needed is that they fail differently. A technical control turns a policy into a property the system cannot violate — an append-only table simply has no DELETE path for the application to take. But a technical control can be misconfigured, bypassed by a privileged insider, or quietly disabled, which is why a behavioral control — someone whose job is to review whether the technical controls are doing their job — has to sit on top of it. The strongest designs make the technical layer the default and the behavioral layer the check, not the other way around.

Underneath both layers sits a third that is easy to take for granted: security. Attributable is only as strong as the authentication that proves a login belongs to the person it names; Original is only as strong as the access control and tamper-resistance that stop anyone from quietly rewriting the stored record. Strip away the security layer and the rest of ALCOA+ becomes theater — a perfect audit trail attributed to a password everyone shares, or an append-only table on a server anyone can log into as the database owner, proves nothing. This is why data integrity and information security are written together in modern guidance: an attacker who can impersonate a user defeats Attributable, and one who can reach the storage defeats Original, no matter how elegant the schema. Security is not a neighbor of integrity; it is one of its load-bearing walls.

Audit-trail review as a regulatory expectation: the QA query

Building an unbreakable audit trail is only half the obligation; guidance now expects that audit trail to be reviewed, with the same rigor applied to the data itself, as part of routine batch review and release [1][3]. In a paper world this was a reviewer leafing through a logbook. In a database world it becomes a query a quality reviewer runs: show me every change to this batch's records, who made each one, when, and why — and, where a hash chain exists, confirm the chain is unbroken. A reviewable audit trail that no one ever queries is a control that exists only on paper. The companion implementation makes both halves concrete: the audit.change_log rows answer the "who changed what, when, why" query, and the verify_chain() function answers the "is it unbroken" query in one call — see Building ALCOA+ Integrity in Code. This review is also what closes the loop at QC and release, where the reviewed record is what actually authorizes a batch to ship.

Why it matters

For data management, ALCOA+ is not philosophy but an inherited spec: every historian (the time-series database that archives process data), LIMS (laboratory information management system), and database in the regulated world is born owing these guarantees, and an architecture that bolts them on later guarantees expensive rework — or a record that cannot be defended when a regulator asks, "How do you know this is true?" [6]

ALCOA+ is the integrity counterpart to the FAIR thread that runs through this book: where FAIR asks whether data can be found, accessed, made interoperable, and reused, ALCOA+ asks whether it can be trusted once you have it — and Available is where the two ideas touch.

Integrity is the substrate for trustworthy machine learning

ALCOA+ matters not only to the human reviewer but to every model trained on the record. A learning model is a function fit to past data; if that data is not Original and Complete, the model learns the wrong lesson with quiet confidence. The clearest case is "testing into compliance": a model trained on a dataset from which the failing runs were silently deleted learns survivorship bias — it sees only the survivors and concludes the process never fails, because the deleted failures are exactly the signal it needed. A model that never saw an out-of-spec aggregate result cannot warn you about one. This is why Book 5's machine-learning suite treats data integrity as the first pillar of a credible model, before any discussion of algorithms — see Data, the Fuel: a soft sensor trained on a hybrid paper-and-digital dataset with no attributable provenance is not merely lower-quality, it is inadmissible for a GMP decision no matter how good its fit score looks.

The attribution triple itself reappears, applied to model artifacts rather than to a glucose reading. Model lineage (also called model provenance) is the record of which dataset version, which code, and which hyperparameters produced which model, and which model produced which prediction — the ALCOA+ who/when/why extended to a learned object, recorded by MLOps tooling (a model registry that pins the training dataset by its content hash, the random seed, and the fitted preprocessing alongside the weights). A model whose training data cannot be named is exactly an unattributed record: you cannot reconstruct it, defend it, or roll it back. Book 5 makes this concrete by pinning every model to the SHA-256 of the exact dataset it learned from — the same content-hash discipline this chapter's hash chain uses, applied to the model's inputs — and by promoting a retrained model only through a four-eyes gate that logs the change, the model-artifact analogue of an attributed, reasoned audit-trail entry (see MLOps and Lifecycle and Models and Validation).

Finally, the integrity idea has a runtime analogue at prediction time. A quality flag on a sensor reading says "do not trust this value"; the ML equivalent is an applicability-domain flag — a check of whether a new input resembles the data the model was trained on, raised when the input falls outside the training envelope. A prediction made on an out-of-distribution input is as untrustworthy as an unattributed record: structurally plausible, confidently wrong, and not safe to act on. An applicability-domain gate is to a prediction what the audit trail is to a record — the mechanism that distinguishes a value you may rely on from one you may not — which is why Book 5's release and soft-sensor models refuse to vouch for a prediction whose input has left the qualified range.

In the real world

This is why interoperability and integrity must be designed together. A standard like AnIML or Allotrope can carry an instrument's raw data and its full context, helping satisfy Original and Complete — but only if the pipeline never silently transforms or drops fields along the way [6]. Real-time lab-data integration work — streaming live instrument data against a shared ontology — faces exactly this tension: pulling data live from many instruments and partners while preserving attribution, time order, and the unbroken audit trail that ALCOA+ demands. Real-time data is only an asset if it is real-time trustworthy data.

In practice, ALCOA+ is rarely something a team writes from scratch — it arrives as a configurable, validated feature of the systems already on the floor, which is where the abstractions in this chapter become buttons and checkboxes someone has to set correctly. On the process side, the AVEVA PI System carries time-series audit trails and uses event frames to bracket a batch or excursion so the trustworthy record has boundaries. In the lab, the chromatography data systems Waters Empower and Thermo Chromeleon are the canonical ALCOA+ enforcers: per-action audit trails, electronic signatures, and a mandatory reason for change on every edit — exactly the attribution triple and before-after pair this chapter dissects, shipped as product. And at the orchestration layer, LIMS and MES (manufacturing execution system) e-signature workflows (LabVantage and Thermo SampleManager LIMS, Siemens Opcenter Execution MES) route a record through named reviewers and approvers, turning Attributable and the audit-trail review obligation into a configured business process. The hard part is no longer building these controls; it is validating that they are switched on, scoped correctly, and never quietly relaxed.

Because the audit-trail and electronic-records capability is a configured feature of a commercial product rather than bespoke code, it is, in GAMP 5 terms (the industry's risk-based validation playbook), typically Category 4 — a configured product, qualified by a risk-based IQ/OQ/PQ (Installation, Operational, and Performance Qualification) that proves the audit trail was installed, operates, and performs as intended. The depth of that proof is set not by exhausting every screen but by patient-safety risk: under Computer Software Assurance (CSA) — the FDA's risk-based reframing of validation, critical thinking over exhaustive scripting — the integrity-bearing functions (the audit trail cannot be disabled, the reason for change is mandatory, the timestamp is not user-settable) earn rigorous scripted proof, while a cosmetic field gets a lighter check. Validating ALCOA+ controls is exactly the place CSA's "scale effort to risk" rule earns its keep, because integrity functions sit at the top of the risk scale; the mechanics are the subject of Validating Computerized Systems: GAMP 5 and the Move to CSA. And these expectations travel: when a process is transferred to a new site or a CDMO, audit-trail review is part of batch disposition there as it was at the originating plant, and the integrity controls must be re-qualified on the receiving site's systems — the integrity obligations move with the process, not with the building it was first validated in.

The unsolved challenge: multi-party audit-trail integrity at scale

The architecture in this chapter — unique attribution, append-only logs, a hash chain a single database verifies — works cleanly inside one system, under one operator's control. Modern biomanufacturing increasingly is not that. A continuous or intensified process can stream live data across a contract development and manufacturing organization (CDMO), a cloud lab running assays for hire, and the sponsor's own quality system — three organizations, three clocks, three audit trails, no shared root of trust (no single authority all three agree to rely on to vouch for identities and timestamps). FDA's data-integrity guidance treats this as the "open system" problem and asks for additional controls when records leave the originating organization's control [1]; the EU is moving the same direction. What began as an EMA concept paper in 2022 [9] is now a concrete revision: the revised draft of EU GMP Annex 11 — published for consultation on 7 July 2025 alongside a revised Chapter 4, with consultation closed in October 2025 and finalization expected mid-2026 — explicitly extends audit-trail and data-integrity expectations to networked, cloud, and multi-system environments and formalizes ALCOA+ [10].

What remains genuinely hard is this: there is no converged, vendor-neutral standard for distributing and verifying an unbroken, time-synchronized audit trail across organizational boundaries in real time. Each party can keep its own honest chain, but stitching those chains into one provably-ordered record is unsolved. Three things are missing at once: synchronized clocks across the wire; agreed attribution semantics when the human at the cloud lab is unknown to the sponsor's identity system; and a verifier any regulator can run against the whole multi-party record. A single-database hash chain answers "was this log tampered with"; it does not yet answer "did these three independent logs, taken together, capture every event in its true order." Until that converges, real-time multi-party integrity is enforced by contracts and audits — behavioral controls — rather than by a technical guarantee, which is exactly the weaker layer this chapter warns against relying on alone. Closing that gap is one of the open frontiers between this chapter and the legal machinery of the next, Records, Signatures, and the Law: 21 CFR Part 11 and EU Annex 11, where the question of what a closed versus an open system owes is taken up directly.

The same tension reaches all the way back to the manufacturing floor and forward to the regulator's desk: every attributed, immutable record this chapter describes ultimately feeds the quality, regulatory, and data backbone that a sponsor must defend in an inspection. Integrity is not a feature of one database; it is a property the whole digital thread has to hold end to end.

Key terms

• Data integrity — the degree to which data is complete, consistent, and accurate throughout its entire life cycle.
• ALCOA — Attributable, Legible, Contemporaneous, Original, Accurate; the original five attributes of good data.
• ALCOA+ — ALCOA plus Complete, Consistent, Enduring, and Available.
• Audit trail — a secure, time-stamped, computer-generated log of who did what, when, and why, protected so it cannot be switched off or quietly altered.
• Electronic signature — a computer entry, legally equivalent to a handwritten signature, that shows the signer's printed name, the date and time, and the meaning of the signing (reviewed, approved, or authored).
• Good Documentation Practices — the behavioral rules for recording data correctly and contemporaneously.
• Technical controls — integrity safeguards enforced by the system (unique logins, time sync, audit trails).
• Behavioral controls — integrity safeguards enforced by people (training, culture, procedures).
• Testing into compliance — the prohibited practice of repeating a test until it passes and reporting only the pass.
• Risk-commensurate controls — applying more rigorous controls to data of greater impact on patient safety.
• Attribution triple — the who, when, and why that every audit-trail entry must carry, with who split into the database role and the authorized human.
• Before-after pair — storing both the prior and new state of a changed record (old_row/new_row), not merely a diff, so the original survives every correction.
• Hash chain — a tamper-evident sequence in which each audit-trail row stores a cryptographic hash (SHA-256 in the companion implementation) of the row before it, so any deletion, reordering, or relinking breaks a verifiable chain.
• Deviation record / CAPA — the formal investigation record opened when a process departs from approved limits, linking back to the batch, its genealogy, and the audit-trail rows that are its evidence; the corrective and preventive action (CAPA) is the permanent fix that follows.
• Out-of-specification (OOS) result — a failing analytical result, which is data in its own right: it stays on the record alongside any valid retest, never deleted, which is "testing into compliance" stated positively.
• Security as an integrity pillar — access control, authentication, and tamper-resistance are the load-bearing wall under ALCOA+: impersonation defeats Attributable and reaching the storage defeats Original, no matter how good the schema.
• PROV-O — the W3C standard provenance vocabulary; the attribution triple is prov:wasAttributedTo (who), prov:generatedAtTime (when), and a prov:Activity whose inputs (prov:used) and prov:wasDerivedFrom capture the before-after derivation (why/what-from).
• SHACL shape / gate — a Shapes Constraint Language declaration that closes the world over a record, enforcing ALCOA+ Complete and Consistent (e.g. sh:minCount 1 on the named person and the reason) as a rule the graph checks, not a hope the reviewer remembers.
• Competency question (SPARQL) — audit-trail review made into an answerable graph query: "who changed glucose_g_l on BATCH-2026-001, when, and why?" returns the attributed, time-stamped rows directly.
• Model lineage / provenance — the ALCOA+ attribution triple applied to a learned model: which dataset version, code, and hyperparameters produced which model produced which prediction, pinned by content hash in MLOps tooling; an unattributable model is an unattributed record.
• Applicability domain — a check of whether a prediction's input resembles the model's training data; a prediction outside that envelope is as untrustworthy as an unattributed record, the ML analogue of a quality flag on a reading.
• Computer Software Assurance (CSA) — the FDA's risk-based reframing of validation (critical thinking over exhaustive scripting); the audit-trail/e-records capability is a GAMP 5 Category 4 configured feature whose IQ/OQ/PQ depth scales with patient-safety risk, so integrity functions earn the heaviest proof.

Where this leads

Audit trails, originals, and attributed signatures only carry weight if the law treats an electronic record as equal to a signed piece of paper. The next chapter, Records, Signatures, and the Law: 21 CFR Part 11 and EU Annex 11, turns ALCOA+ from good practice into legal obligation — explaining what makes an electronic record and an electronic signature trustworthy and legally equivalent to ink on paper, and how closed and open systems, audit trails, copies, retention, and validation make that equivalence hold.