Data Integrity Is a Product Requirement: Designing for ALCOA+ Before QA Ever Asks

Designing for ALCOA+ before QA ever asks means treating attributable, legible, contemporaneous, original, and accurate data — plus complete, consistent, enduring, and available — as schema decisions made at spec time, not a checklist run at audit time. Build the audit trail and immutability logic into the data model itself, and compliance becomes a side effect of good design.

Quick answer: ALCOA+ isn't a QA review step — it's nine design constraints on your data model and UI. Map each letter to a concrete schema decision (who wrote it, when, in what original form, and what can never be silently changed) before a single ticket goes to engineering.

Why Data Integrity Breaks When It's Only QA's Job

Data integrity fails late because PMs treat it as a review gate, not a design constraint. By the time QA flags a gap — an editable result field, a client-side timestamp, a missing actor ID — the schema is built, the UI is shipped, and the fix means a migration and a slipped release.

The root cause is almost always sequencing. Teams write user stories about what the product does — capture a sample result, generate a report, route an approval — and leave who touched it, when, and in what original form as an implementation detail for engineering to sort out. That detail is precisely what regulators inspect.

ALCOA+ is the FDA and MHRA's shorthand for what "data integrity" means in practice: Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, and Available. The FDA's 2018 guidance Data Integrity and Compliance With Drug CGMP and MHRA's 'GXP' Data Integrity Guidance and Definitions both describe it not as paperwork hygiene but as an expectation baked into how systems record and preserve data across their entire lifecycle.

Industry reviews of FDA warning letters have repeatedly found data integrity citations running through a large share of them — often the majority in a given year — which tells you this isn't a rare finding reserved for bad actors. It's what inspectors find when a system was built to pass a demo, not to survive scrutiny of its raw records months or years later.

If you own a regulated data-capture product, this is the same terrain covered more broadly in our complete guide to biotech and pharma product management — data integrity is one specific, high-stakes slice of a much wider compliance surface a PM has to design for from day one.

The Cost of Treating It as a Patch

Retrofitting ALCOA+ after launch is expensive in a specific way: you're not adding a feature, you're changing the meaning of historical data. An audit trail bolted on after go-live can't reconstruct what happened before it existed, and a "who edited this" column added post-launch has null values for every record that matters to an inspector. That's why the fix belongs at the requirements stage, written as an acceptance criterion on the ticket, not filed as a bug against it later.

The Nine Letters of ALCOA+, Translated Into Schema Decisions

Each ALCOA+ letter maps to a specific, testable decision in your data model or workflow — not a policy statement. Below is that translation, letter by letter, framed the way an engineer would need it: as a field, a constraint, or a state-machine rule, not an abstraction.

Attributable, Legible, Contemporaneous

Attributable means every write is tied to a specific, authenticated actor — never a shared login, a service account masquerading as a person, or a freeform "entered by" text field. Model it as a foreign key to a users table with role and authentication method captured, not a string.

Legible means the record stays human-readable for the full retention period, which can run a decade or more for GxP data. Store structured values with units and controlled vocabularies rather than free-text blobs, and avoid proprietary formats that outlive the software that reads them.

Contemporaneous means the timestamp reflects when the action actually happened, captured server-side at the moment of the write — never a client-editable field the user can backdate. Separate event_time (what the user reports happened) from recorded_at (when the system captured it), and make the second one immutable.

Original, Accurate

Original means the first-captured value is preserved permanently, even after corrections. If an instrument outputs raw data, that raw file — not a transcribed summary — is the source of truth the system must retain and link to every downstream calculation.

Accurate means calculations are reproducible and verifiable: versioned formulas, calibration metadata attached to the record it applies to, and — for anything that matters — a second-person verification step modeled as a distinct workflow state, not a checkbox.

Complete, Consistent, Enduring, Available

The "+" letters extend ALCOA to the full data lifecycle, not just the moment of capture:

• Complete — nothing is deleted, including failed runs, invalidated results, and reprocessed data; all of it stays queryable, not archived into a black hole.
• Consistent — event sequencing in the audit trail matches the true order of events; formats (dates, units, decimal precision) don't drift across a record's lifetime.
• Enduring — the record survives format migrations, vendor changes, and software end-of-life for the entire retention period, which regulators may define in years, not release cycles.
• Available — the record and its full audit trail can be retrieved and reviewed by an inspector with reasonable notice, in a form a human can actually read, not a raw database dump.

A Worked Example: One Sample-Result Entity, Two Audit Outcomes

The clearest way to see ALCOA+ as a design decision, not a policy, is to look at the same entity built two ways. Below is a sample_result — the kind of thing a QC lab, a clinical data-capture tool, or a bioprocess monitoring app all need — designed naively versus designed for audit.

The naive version optimizes for the demo: enter a value, save it, edit it if someone made a typo. It works perfectly until an inspector asks, "show me what this value was on March 3rd, and who changed it, and why."

-- Fails an audit
CREATE TABLE sample_result (
  id INT PRIMARY KEY,
  sample_id INT,
  result_value NUMERIC,
  entered_by TEXT,        -- freeform, not FK'd to a user
  updated_at TIMESTAMP    -- client-supplied, editable
);

The audit-ready version treats the result as an append-only sequence of versions, each one attributable, timestamped server-side, and reasoned. Nothing is ever overwritten — a correction is a new version with a link back to the one it supersedes.

-- Survives an audit
CREATE TABLE sample_result_version (
  id INT PRIMARY KEY,
  sample_result_id INT NOT NULL,
  version_no INT NOT NULL,
  result_value NUMERIC NOT NULL,
  unit TEXT NOT NULL,
  entered_by_user_id INT NOT NULL REFERENCES users(id),
  recorded_at TIMESTAMPTZ NOT NULL DEFAULT now(),  -- server-generated, immutable
  reason_for_change TEXT,                          -- required when version_no > 1
  previous_version_id INT REFERENCES sample_result_version(id),
  signature_meaning TEXT CHECK (signature_meaning IN ('entered','reviewed','approved')),
  UNIQUE(sample_result_id, version_no)
);

Notice what the second table makes structurally impossible: you cannot silently overwrite a result, cannot attribute a write to nobody, and cannot backdate a record. Those aren't UI validations layered on top — they're constraints the database itself enforces.

Building the Workflow Layer: Audit Trails, E-Signatures, and the Silent-Overwrite Trap

A compliant schema is necessary but not sufficient — the workflow layer on top of it is where most products actually fail ALCOA+ in practice. Three patterns do the most damage: audit trails that are really just "last updated by," e-signatures that capture a click instead of a meaning, and edit flows that silently overwrite instead of version.

Audit trails need to be a separate, append-only ledger, not a single updated_by/updated_at pair on the row itself. A real audit trail records every state transition — old value, new value, actor, timestamp, and reason — as its own immutable row, so the full history survives even if the parent record is later corrected again.

E-signatures need to capture meaning, not just identity. Under 21 CFR Part 11, an electronic signature has to convey what the signer is attesting to — "reviewed," "approved," "rejected" — not merely confirm who clicked a button. That's a workflow-state design problem: model the signature as a transition with an explicit meaning field, tied to re-authentication, not a passive audit-log entry.

Silent overwrites are the single most common failure mode we see in first-draft data-capture products. An edit screen that lets a user change a submitted value in place — with no version history, no reason captured, no re-approval — violates Original, Contemporaneous, and Attributable simultaneously in one UI decision.

As MHRA's data integrity guidance puts it, the expectation is that data-generating processes are designed so that "the correct data is captured... in a manner which precludes the alteration or overwriting of original results." That's a design instruction aimed squarely at the product and engineering teams building the system, not just the people validating it afterward.

Because this workflow layer intersects directly with computer system validation and Part 11 controls, we've written a dedicated walkthrough of computer system validation and Part 11 for product managers that goes deeper into the validation lifecycle this sits inside.

None of this is unique to pharma, either. Agritech teams capturing field-trial yield data, residue testing, or chain-of-custody records for regulated inputs face nearly identical audit questions from their own regulators — a parallel we cover in our agritech product management guide.

The PM's ALCOA+ Acceptance-Criteria Checklist

The fastest way to make ALCOA+ a design-time requirement is to turn each letter into an acceptance criterion on the ticket, written in the same language as your other stories. Below is a working checklist mapping each principle to a data-model requirement and a testable UI/workflow criterion.

1. Write the criterion before the story is estimated, not after a bug is filed — engineering should size "append-only versioning" as part of the feature, not as rework.
2. Name the actor model explicitly in every data-capture story: who can write, who can approve, and whether those can be the same person.
3. Ask "what happens on correction?" for every editable field before it ships — if the answer is "we overwrite it," that's a finding waiting to happen.
4. Treat the audit trail as a first-class entity, reviewed in design like any other table, not an afterthought bolted onto existing rows.

Getting this prioritized against a roadmap full of feature requests is as much a negotiation as it is a technical decision — Quality and Regulatory rarely sit in your reporting line, which is exactly the terrain our guide to stakeholder politics is built for. And treating data integrity as a proactive design requirement rather than a QA gate is, ultimately, a leadership stance a PM has to model for the team, something we unpack further in our PM leadership guide.

Where Design Tooling Can Help You Get There Earlier

This is exactly the kind of pressure-testing that's easy to describe and hard to do consistently by hand across dozens of entities. Prodinja's Data Modelling studio turns entities you sketch into concrete SQL DDL — real CREATE TABLE statements with foreign keys and constraints, not just a diagram — so the audit fields, immutability rules, and versioning tables in the examples above can get designed in before an engineer opens an IDE.

The studio's evals-style rigor framing is built to walk you through pressure-testing each field against a rubric like ALCOA+ as you model it — asking who the actor is, what's immutable, and where the timestamp comes from — while it's still cheap to change. It's a prototype experience aimed at catching exactly the gaps this article walks through, before they reach QA.

It's worth revisiting your own product's entities against this lens periodically, not just once at launch — the kind of deliberate, recurring practice we describe in our piece on PM craft and reflection.

Key Takeaways

• ALCOA+ is a design constraint, not a QA checklist — attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available data all trace back to schema and workflow decisions made before a line of code ships.
• Retrofitting is expensive in a specific way: you can't reconstruct historical attribution or timestamps for records created before the audit trail existed.
• The silent-overwrite trap is the most common failure: any edit path that mutates a submitted value in place violates Original, Contemporaneous, and Attributable at once.
• Audit trails belong in their own append-only table, not as an updated_by column on the row itself.
• E-signatures must capture meaning ("approved," "reviewed"), not just identity or a timestamp of a click.
• Turn each ALCOA+ letter into an acceptance criterion on the ticket, sized and estimated alongside the feature it protects — not filed as a bug afterward.
• This isn't pharma-only — any regulated data-capture product, from agritech field trials to clinical systems, faces the same nine questions.

Frequently Asked Questions

What does ALCOA+ stand for in data integrity?

ALCOA+ stands for Attributable, Legible, Contemporaneous, Original, and Accurate — the original five principles — plus Complete, Consistent, Enduring, and Available. The FDA and MHRA both use it as the working definition of what "data integrity" means for GxP-regulated records across their full lifecycle, from capture through retention.

Is ALCOA+ a formal regulatory requirement, or just best practice?

ALCOA+ itself isn't a single regulation you can cite by number, but it's the FDA's and MHRA's own explanation of what regulations like 21 CFR Part 11 and the CGMP predicate rules require in practice. Treat it as directly enforceable: inspectors cite specific ALCOA+ failures — like an editable timestamp or a shared login — as findings against existing regulations, not as optional guidance.

How do you build an audit trail that satisfies 21 CFR Part 11?

A Part 11-ready audit trail is a separate, append-only, system-generated log — never an editable field on the record itself — that captures the actor, the old and new values, the timestamp, and (for changes to existing data) the reason. It also needs to remain available and human-readable for the full retention period, which is why the workflow layer, not just the database schema, matters.

What's the difference between data integrity and data quality?

Data quality asks whether a value is correct — the right unit, a plausible range, no typos. Data integrity asks whether you can trust the record's history — who entered it, when, whether it's the original, and whether anyone could have altered it undetected. A product can have perfect data quality and still fail an audit on data integrity if edits are silent and unattributed.

Can e-signatures alone satisfy the "Attributable" requirement?

Not by themselves. An e-signature satisfies Attributable only when it's tied to a uniquely authenticated individual, captures the meaning of the action (approved, reviewed, rejected), and is bound to the specific record version it applies to. A signature that's just a timestamped click, decoupled from re-authentication and meaning, doesn't meet the bar regulators actually inspect against.