Skip to main content

Regulation and Governance: FDA, Annex 22, and Validating a Model

📍 Where we are: Part VII · ML/AI in Industry Today — Chapter 27. The case-studies chapter graded who deployed what and found the top-right quadrant — independently verified, in commercial GMP — empty, with the Purolea warning letter sitting at the field's edge as a warning sign. This chapter turns from who deployed it to what is allowed and how you prove it: the rules, the documents that contain them, and a worked lifecycle that takes one model from intended use to a defensible, validated, monitored deployment.

The previous chapters built models and then asked how good the evidence was. This one asks the harder question that every real deployment eventually faces: not "does the model work?" but "are you allowed to use it, and can you prove it does what you claim, to a regulator who can shut your line down?" That is a different discipline from machine learning, and it is the one that decides whether a clever soft sensor ever touches a GMP (Good Manufacturing Practice — the legally binding quality rules a drug plant must follow; "cGMP" is the current version those rules require) batch. A soft sensor is a model that infers a hard-to-measure quantity from an easy-to-measure signal — here, a concentration read off a spectrum — standing in for a slow lab assay. The regulatory landscape for AI in drug manufacturing went from almost empty in 2022 to concrete in 2025–2026: a draft EU annex written specifically for AI, an ISPE validation playbook for it, an FDA risk-based credibility framework, and — the moment the abstractions became real — the first warning letter (the FDA's formal written citation of serious violations, demanding prompt correction and signalling possible enforcement if ignored) to cite AI. This chapter is the map of all of it, and it ends where the MLOps chapter left a thread hanging: a concrete, document-by-document validation of our running example's glucose soft sensor under that map.

The simple version

Think of a new bridge. Before anyone drives on it, an engineer must produce a dossier — calculations, materials certificates, load tests — and an independent authority signs that the bridge is fit for its stated purpose. The thicker the traffic the bridge will carry, the more evidence the authority demands. AI in a drug plant works the same way. You declare exactly what the model is for (its "intended use"), you judge how much harm a wrong answer would do (its "risk"), and you assemble evidence proportional to that risk showing the model is trustworthy for that purpose. Then you lock the model so it cannot quietly change, watch it for drift, and only ever change it on purpose with paperwork. The regulators' core message in 2026 is short: a model may advise, the more it influences a critical decision the more you must prove, and a human — not the model — makes the call and signs. The firm that let an AI sign instead got the first warning letter.

What this chapter covers​

  • FDA's 2023 discussion paper Artificial Intelligence in Drug Manufacturing and the broader 2025 AI-in-drug-development guidance, with the 7-step risk-based credibility framework that scales evidence to a model's "context of use."
  • The draft EU GMP Annex 22 in depth: locked (static, deterministic) versus adaptive models, the predetermined change control plan (PCCP), and the explicit line excluding generative, continuously-learning, and adaptive AI from critical GMP decisions.
  • The supporting regulatory frame: ICH and PIC/S posture, the ISPE GAMP AI Guide, Computer Software Assurance (CSA), and ALCOA+ data integrity — the four pillars a model-validation file actually stands on.
  • A worked validation lifecycle for an ML soft sensor under GMP, end to end: intended use → risk → data and credibility evidence → locking → monitoring → change control.
  • The Purolea cGMP warning letter (2 April 2026), the first to cite AI, as the enforcement anchor that makes every abstraction above concrete.

FDA: a discussion paper, a framework, and risk proportionality​

The FDA's posture on AI in manufacturing begins not with a rule but with a question. In 2023 the agency published a discussion paper, Artificial Intelligence in Drug Manufacturing — formally a Federal Register notice and request for information under docket FDA-2023-N-0487 (88 FR 12943, 1 March 2023, comment period reopened that September) — which is exactly what it says: a structured set of questions, not binding requirements [1]. It is the most important regulatory document for this field precisely because of what it does not do — it does not prescribe answers, it surfaces the issues a manufacturer must think through. Three of its themes run through everything else in this chapter. First, the GMP framework was not written with AI in mind, so applying it requires interpretation: an ML model is neither obviously "equipment" (21 CFR 211.63/211.68 — CFR is the US Code of Federal Regulations, the codified rulebook, and these are its equipment-design and -cleaning sections) nor obviously "a computerized system" (Annex 11 and Part 11, the EU and US rules respectively for computerized systems and their electronic records and signatures) nor obviously "an analytical method," yet it has properties of all three, and the paper asks under which umbrella each ML use falls. Second, managing the data that trains and feeds a model is itself a GMP concern — the paper raises provenance, representativeness, the risk that a training set silently fails to cover a future operating condition, and the integrity of the data labels themselves. Third, models change, and the agency asks directly how a manufacturer will validate and re-validate a model over its life, and how to tell continuous improvement apart from undetected drift. The paper is a regulator thinking out loud, and reading it is the single best way to understand what the FDA will eventually expect.

The structural idea underneath the FDA's thinking is risk proportionality, and it has a concrete form in the agency's broader work on computational models. FDA's January 2025 draft guidance, Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products (docket FDA-2024-D-4689), establishes a 7-step, risk-based credibility-assessment framework [2]. It is worth walking through each step, because the worked lifecycle later in this chapter is this framework applied to one model:

  1. Define the question of interest. State the specific decision or concern the model is meant to inform — not "use ML for the bioreactor" but "estimate in-process glucose between offline assays so the feed can be timed." A fuzzy question of interest is the root cause of an unfalsifiable validation file.
  2. Define the context of use (COU). Specify exactly how the model's output will be used and what it will and will not drive — the scope of the decision the output feeds, the role of any human in the loop, and the boundary conditions outside which the model is not qualified. The COU is the single most consequential statement in the file; everything downstream is sized from it.
  3. Assess the model risk. Model risk is the product of two factors: model influence (how much the decision relies on the model output versus other evidence) and decision consequence (the severity of harm to product quality or patient safety if the model is wrong). A high-influence input to a high-consequence decision is high risk; a low-influence input to a recoverable decision is low risk. This step sets the dial for everything that follows.
  4. Develop a credibility-assessment plan. Lay out in advance the studies, the data, and — critically — the pre-stated acceptance criteria whose rigor matches the risk judged in step 3. High risk demands held-out data, sensitivity analysis, uncertainty quantification, and independent review; low risk may need only a basic check. Writing the gate before seeing the result is what keeps the assessment honest.
  5. Execute the plan. Run the studies exactly as planned. Deviations are documented and justified, not quietly absorbed — a moved acceptance gate is a red flag to any reviewer.
  6. Document the credibility-assessment results. Record what the evidence actually showed against the pre-stated gate, including where the model is weak, the operating range it was qualified over, and residual behavior at the edges. The negative space — where the model is not credible — is part of the record.
  7. Determine model adequacy for the COU. Judge whether the evidence is sufficient for the specific context of use. If it falls short, the framework loops: tighten the COU, gather more evidence, or reduce the model's influence (add a human gate) until adequacy is reached for the narrowed use.

The genius of the framework is that the same seven steps govern a trivial spreadsheet and a CQA-defining (critical-quality-attribute-defining) neural network; what differs is the depth of evidence step 4 demands, set by the risk judged in step 3. A lot (or batch) is one discrete quantity of product made together, and to release a lot is the quality unit's formal decision that it meets its specifications and may ship — so a model that merely flags batches for human review needs less proof than one whose output releases a lot. This is the regulatory translation of the entire book's two-axis discipline: context of use is intended-use scope, and model risk is the multiplier on how much evidence you owe.

Crucially, the FDA documents are guidance and a discussion paper — authoritative and public, but explicitly not rules. They tell you how the agency will think, not what you must do. For a binding instrument that draws hard lines, you cross the Atlantic.

The draft EU GMP Annex 22: where the line gets drawn​

The EU drew the first manufacturing-specific AI line in regulation. The draft EU GMP Annex 22, "Artificial Intelligence," was released for public consultation on 7 July 2025 (comment period to 7 October 2025) as part of EudraLex Volume 4, alongside a revised Annex 11 and Chapter 4, and developed in cooperation with PIC/S — making it the first GMP text written specifically for AI [3]. Where the FDA asks questions, Annex 22 makes commitments — and they are sharp enough that every team deploying ML in a regulated plant must know them.

The annex's central distinction is between static (locked) models and dynamic (adaptive) models. A static model is frozen: its parameters do not change once deployed, so the same input yields the same output for the model's whole validated life. It is also deterministic — identical input produces identical output, every run, with no stochastic sampling at inference. A dynamic model continues to learn in production, updating itself on new data. Annex 22's headline rule follows directly: for critical GMP applications it permits only static, deterministic models, and it excludes from critical use the three categories that cannot offer that determinism — dynamic continuously-learning (online-learning) models, probabilistic models whose output is not reproducible run to run, and generative AI and large language models [3][4]. The reasoning is the one the MLOps chapter built toward: GMP validation rests on reproducibility, and a model that changes itself, or that answers differently on two runs, cannot be validated by a one-time test. So the annex does not ban these models — it confines them to non-critical uses with a qualified human in the loop, and reserves critical decisions for models that hold still.

"Critical" here carries its GMP weight: an application is critical when its output affects product quality, patient safety, or data integrity. Our glucose soft sensor advising a feed sits near that line; a model that released a lot on its own would be squarely over it. The annex pairs the static-model requirement with a set of expectations that read like a validation table of contents, and the careful reader should treat each as a section heading their file will need: a documented intended purpose; a risk assessment; data-governance controls over training and input data (representativeness, provenance, integrity); test-data independence — the data used to test a model must be genuinely held out, not seen in training, and the annex is explicit that overlapping test and training data invalidates the evidence; performance and acceptance criteria fixed before testing; explainability expectations, including logged feature attribution and confidence scores where the application warrants them; human oversight appropriate to the risk; and continuous monitoring after deployment. And it codifies the lifecycle mechanism: any change to a deployed model runs through change control, with the predetermined change control plan (PCCP) as the instrument that lets a planned retrain proceed without a fresh regulatory negotiation.

The PCCP is worth stating precisely because it is the bridge across the validation-versus-learning gap. A PCCP is a pre-approved, written specification of how a model may change in the future — which data it will be retrained on, which parts of the algorithm stay fixed, what acceptance criteria the new version must meet, and what the rollback plan is. The concept is borrowed from the FDA/CDRH device world, where a finalized PCCP framework lets a manufacturer pre-authorize a defined envelope of future modifications; Annex 22 imports the same logic into GMP manufacturing. With an approved PCCP, a retrain that stays inside the envelope the plan describes is a documented, planned event rather than an unforeseen change requiring a new submission. The model still cannot learn in place; learning happens between locked versions, each one a discrete validated object, and the PCCP pre-approves the shape of the path between them. This is the regulatory form of the locked-then-relearn pattern: lock a model, run it unchanged, detect drift, retrain off-line into a new candidate, validate it against the PCCP's criteria, and promote it through change control — never an in-place silent edit.

One honesty note the book keeps making: Annex 22 is a draft. Consultation ran through 2025, finalization is expected around mid-2026, and the specific exclusions are provisional — a point made even in the contemporaneous literature interpreting the draft. Cite it as a draft, and watch for the final text — but its direction is unambiguous, and it already governs how careful firms design AI today.

The supporting frame: ICH, PIC/S, GAMP, CSA, and ALCOA+​

Annex 22 and the FDA framework do not stand alone; they sit on a stack of established quality regulation that an AI deployment inherits whole. Four pieces of that stack do real work in a model-validation file.

ICH and PIC/S set the international backdrop. The product-quality lifecycle is already governed by the ICH (International Council for Harmonisation, the body whose guidelines drug regulators worldwide adopt) quality guidelines — Q8(R2) pharmaceutical development and the design space (the proven multidimensional range of inputs and process settings within which quality is assured), Q9(R1) quality risk management, Q10 the pharmaceutical quality system, Q11 drug-substance development, and Q12 lifecycle management — and an ML model that touches a critical process parameter (a setting that must be controlled to keep product quality on target) or a CQA (a critical quality attribute — a measurable property the product must meet) operates inside that design space, not outside it [5]. Q9's risk thinking is, in fact, the parent of the FDA credibility framework's risk dial, and Q12's lifecycle-management tools are what a PCCP plugs into. PIC/S, the inspectorate cooperation scheme, co-developed Annex 22 with the EU, which means the line the annex draws will be applied by inspectors across dozens of jurisdictions, not just the EU — a draft with unusually long reach.

The ISPE GAMP AI Guide is the practitioner's translation layer. Published in July 2025 alongside the established GAMP 5 (2nd edition, 2022) computerized-system-validation framework and its Appendix D11 on AI/ML, it extends GAMP's risk-based, lifecycle, V-model thinking to AI/ML, and introduces a structure often summarized as seven control layers for LLM-based and AI systems in GMP decision-making, spanning data, model, deployment, monitoring, and human oversight [6]. Where Annex 22 says what must hold, GAMP says how to demonstrate it: how to write the intended-use specification, how to scale testing to risk, how to document the supplier's contribution when the model or its framework comes from a vendor (the GAMP category question), and how to keep the V-model's left-leg specifications traceable to the right-leg tests for a thing that is statistical rather than deterministic in its construction.

Computer Software Assurance (CSA) is the methodological shift that makes any of this affordable. The FDA finalized its CSA guidance, Computer Software Assurance for Production and Quality System Software, on 24 September 2025 (docket FDA-2022-D-0795), superseding the validation section of the 2002 software-validation guidance, and its message is a deliberate course-correction away from documentation-for-its-own-sake toward critical thinking and risk-based testing: spend assurance effort where a failure would actually harm product or patient, and use the least burdensome evidence sufficient for the risk [7]. For ML this is liberating — it means you do not test every code path of scikit-learn or every layer of PyTorch; you test that your model, on your data, meets its stated acceptance criteria for its intended use, and you scale the rest to risk. CSA is the reason a model-validation file can be evidence-rich and paperwork-lean at once.

ALCOA+ is the data-integrity spine underneath the evidence. Codified by the MHRA, PIC/S (PI 041), and WHO, the principle holds that every datum that trains, tests, or feeds a model must be Attributable, Legible, Contemporaneous, Original, Accurate — plus the four "+" attributes Complete, Consistent, Enduring, and Available [8]. For ML this is not a side concern; it is foundational, because a model is only as trustworthy as the data behind it. A training set whose provenance cannot be attributed, or whose values were silently edited, poisons every downstream credibility claim — and Original and Contemporaneous are exactly what a dataset content-hash defends, since a hash binds the evidence to the unaltered bytes captured at validation time. The open-source book's ALCOA+ chapter shows how to build these properties into the data pipeline by construction; here they become the precondition that lets the credibility evidence mean anything at all.

A worked validation lifecycle: the glucose soft sensor under GMP​

Abstractions earn their keep only when applied. Take the running example's Raman soft sensor — soft_sensor_pls.py, a PLS (Partial Least Squares) model — a classic chemometric regression that compresses hundreds of correlated Raman (a laser-light scattering measurement that fingerprints what is dissolved in the culture) wavelengths into a few latent components — reading a concentration off a Raman spectrum so the culture can be steered without waiting for the slow bench assay — and walk it through the full lifecycle the documents above demand. A note on the worked target: the committed soft_sensor_pls.py demonstrates the identical pipeline on titer (the concentration of product antibody in the culture — the label with the cleanest reference assay, so the harness gate the reader sees reads Raman->titer R2 > 0.85), and glucose (the sugar the cells feed on) is the same-spectra co-target — a second quantity read from the same Raman scan by the same calibration — the downstream control application that frames the intended-use statement below. So the printed gate says titer while the intended-use narrative names glucose: same model, same spectra, the in-process control use-case in front. This is the chapter's spine: the same seven steps the FDA framework names, collapsed into the six operational stations a manufacturer actually executes, made concrete on one model. The model is fitted on the golden batch BATCH-2026-001.

1. Intended use (context of use). State exactly what the model is for, and — just as important — what it is not for. The model predicts in-process glucose concentration from a Raman spectrum, to advise the timing and size of a bolus feed during the production bioreactor phase. Its output is advisory: a human operator reviews it against the control strategy and decides the feed. It does not release material, does not define a CQA, and is not used outside the validated glucose range or for any product other than mAb-A. That single paragraph is the FDA framework's steps 1 and 2 — question of interest and context of use — in one breath, and it is the most consequential text in the file, because everything else scales from it. The validated glucose range in that last clause is not a slogan: it is the glucose window the calibration batch actually spanned (and, for a fed-batch, the controller's target band — illustratively a few g/L glucose for a CHO culture), and a prediction outside it is extrapolation, flagged at run time by the applicability-domain gate (Hotelling T² plus spectral residual SPE/Q) that soft_sensor_pls.py already computes. The boundary is falsifiable because the gate that enforces it is in the code.

2. Risk assessment. Judge model risk as influence × consequence (FDA step 3). The soft sensor influences a feed decision but a human gates it (moderate influence), and a wrong glucose reading would, at worst, mis-time a feed — recoverable, monitored, and not directly release-defining (moderate consequence). So this is a medium-risk, advisory application: more scrutiny than a dashboard, far less than an autonomous controller. Under Annex 22 it stays on the permitted side of the line because it is locked, deterministic, and human-gated; were it to close the loop on a CQA, it would cross into the territory the annex reserves for static models under the heaviest evidence — or excludes outright if it learned in production. Make the stakes concrete with the campaign's own failure: its sibling run BATCH-2026-004 is out-of-specification on host-cell protein, and the suite's MSPC monitor (mspc.py) flags exactly that batch and points its SPE contribution at the HCP signal. A model that merely flags such a batch for a human is the advisory side of the Annex 22 line; a model that released it autonomously would be over it.

3. Data and credibility evidence. Assemble proof proportional to the risk (FDA steps 4–6). The model is trained on a pinned, ALCOA+ dataset — the Raman spectra (raman_spectra.parquet) and the paired offline assays — with the dataset's sha256 recorded so "which data trained this?" is answerable forever. The acceptance criterion is fixed before testing: Raman→titer R² above 0.85. R² (the coefficient of determination) is the fraction of the concentration's variation the model explains, where 1.0 is a perfect fit and 0 is no better than guessing the average — so 0.85 is a deliberately demanding bar even for an advisory sensor. The credibility evidence is the held-out metric measured against that pre-stated gate, the operating range the model is qualified over, and the residual behavior at the edges. Be precise about what that held-out metric does and does not establish: soft_sensor_pls.py evaluates on a random hold-out of hourly spectra from the single golden batch, so its R² measures within-batch interpolation — tracking the concentration within one run — not forward extrapolation to a future batch. That is honest evidence for the advisory in-run use, but the cross-batch independence Annex 22 ultimately wants is demonstrated elsewhere in the suite (the calibration-transfer and drift modules), and a production calibration would span many batches before its file claimed generalization. The PLS, whose five components are chosen by an inner-CV one-standard-error rule, clears its gate comfortably (R² above 0.99), and a deep 1D-CNN matched but did not beat it at roughly eight times the parameter count (5,713 parameters against 702 PLS coefficients) — the kind of negative result that belongs in the file because it justifies choosing the simpler, more explainable model. The same module logs the feature attribution Annex 22 asks for — VIP scores naming the Raman bands the model leans on (VIP above 1 on the C–H/amide region around 1270 cm⁻¹) — and a per-prediction applicability-domain gate (Hotelling T² plus spectral residual SPE) that flags an out-of-domain spectrum before its estimate is trusted: the logged confidence score the annex wants for a critical-adjacent use. This is where the suite's harness does real work as a software-assurance analogue, below.

4. Locking. Freeze the validated object. The weights, the preprocessing, the fitted scaler, the feature contract (the 701-wavenumber input vector), and the operating range are all version-pinned and unchangeable in place. The model does not learn on the fly and is deterministic at inference, satisfying Annex 22's two requirements at once. "Locked" is made literal: a model-version record binds the artifact to its dataset hash, its split and seed, and its frozen hyperparameters, so the deployed model is provably the exact one that was qualified.

5. Monitoring. Watch the locked model for drift, using the two detectors from the MLOps chapter: a label-free PSI on the input distribution (the leading indicator that fires when a new lot or a fouling probe moves the spectra) and an I-MR residual control chart against the sparse offline assay (the lagging, ground-truth indicator that proves the answers have gone wrong). The suite realizes exactly this in drift.py, whose residual control chart catches an injected probe-fouling drift on the golden batch. Monitoring is not optional polish; it is Annex 22's continuous-monitoring expectation and the operational half of "validated forever."

6. Change control. Govern every change through the PCCP. A retraining trigger — a sustained PSI breach and a residual out-of-control signal, plus a calendar backstop, plus automatic re-qualification on any hardware change (a probe swap, a resin-lot change, a scale move) — opens the change-control path. The retrain produces a new version, validated against the PCCP's pre-stated acceptance criteria, promoted only through a four-eyes gate (a second qualified person signs), with rollback to the last known-good version always one promotion away because old versions are never deleted. The suite's lifecycle_retrain.py is this station in code: after drift.py fires, a challenger version is retrained off-line, beats the champion on a held-out revalidation window, and is recorded as a governed PROMOTE under change control rather than a silent in-place edit.

Where the dossier's data claims become machine-checkable: the ontology underneath​

Three of the stations above lean on a quiet assumption worth making explicit, because it is what makes the dossier's data-governance attestations more than a signed promise. The "pinned ALCOA+ dataset" of station 3, the "feature contract" frozen in station 4, and the data-governance attestation in the dossier all describe the same training data — and the most defensible way to describe it is not a column name in a parquet file but an ontology (a shared, machine-readable vocabulary of what each thing is and how it relates) and the knowledge graph built over it. The companion Ontology book models exactly the campaign this chapter validates, and three of its constructs do real regulatory work here.

First, the training label is semantically grounded, not a fragile string. When soft_sensor_pls.py pairs a Raman spectrum with an offline assay, the target it learns is a typed, unit-bearing value — a monomerPct or a titer reading carried as a typed quantity with its unit attached, pulled by a stable IRI (a global identifier that means the same thing to every system) rather than by a column header that two LIMS exports can spell differently. A feature pulled by its ontology IRI cannot silently become a different measurement when a source system is re-mapped — the exact provenance and Original/Accurate guarantee ALCOA+ demands of every datum that feeds a model, made structural rather than asserted.

Second, the same SHACL release-gate shape that disposes a lot also admits a training row. The release gate and SHACL chapter builds a closed-world bp:ReleaseShape — every required CQA present, singular, typed, and in range — to decide whether a lot may ship. Pointed at a candidate training subgraph instead of a lot, that same shape refuses a row whose HMW result silently never loaded, before it reaches the learner. This matters because a model has no native notion of "complete": handed a lot with a missing label it will impute, average, or predict around the hole and report a confident number — the precise failure SHACL exists to forbid. The release-gate shape becomes the labeling contract for a release predictor: the closed-world rule that defines what a valid PASS/OOS label even is, checked in front of a reviewer rather than discovered after deployment.

Third — and most consequential for honest evaluation — the derivedFrom lineage is the grouping key the cross-batch claim needs. Station 3 is careful that the soft sensor's R² is within-batch interpolation, not cross-batch generalization, and Annex 22 ultimately wants the harder evidence. The reason a naive random split cannot supply it is structural: the genealogy spine records that DP-001, DP-002, and DP-004 all trace through one working cell bank, so they are not independent rows — a random fold leaks sibling information across the split and flatters the score. The transitive bp:derivedFrom edge that scopes a recall is exactly the key an honest grouped, leave-one-batch-out cross-validation splits on — hold out a whole lineage at a time — so the same edge that makes a recall a query makes a generalization claim defensible. And the upper-ontology split the graph rests on — BFO continuant versus occurrent — keeps a measurement (a value the batch bears) distinct from the run that produced it, so a feature row can never accidentally encode the vessel as if it were the product.

There is a fourth tie, to the generative copilot the next chapter examines: a GraphRAG assistant (a language model answering only from facts retrieved out of the graph, not from training memory) asked "was DP-004 released?" answers truthfully — no, it tripped bp:hmwPct at 2.41 % — only because the validated graph, not the model's fluency, is the ground truth it is grounded against. The same ontology that admits a training row is what keeps a fluent copilot from inventing a release status. None of this is a new model; it is the discipline that lets the dossier's data-governance field be audited, not merely trusted.

Hero diagram of the GMP model-validation lifecycle drawn as a closed loop in six labelled stations around a central locked-model node. Station one, intended use, an indigo card stating the soft sensor advises a feed and does not release a lot. Station two, risk assessment, an amber card scoring model risk as reliance times consequence and reading medium, advisory, human-gated. Station three, data and credibility evidence, a cyan card showing a pinned ALCOA-plus dataset with a sha256 hash, a held-out test split marked within-batch interpolation, and a pre-stated acceptance gate R-squared above 0.85. Station four, locking, a green card freezing weights, scaler, feature contract, and operating range into a version-pinned model. Station five, monitoring, two small monitor glyphs, a label-free PSI input-drift detector and an I-MR residual control chart fed by the sparse offline assay. Station six, change control, a rose card with a PCCP box, a four-eyes promotion gate, and a rollback arrow back to the previous locked version. A central node reads locked validated model, advisory only, with a human-decides badge. Around the rim a thin band names the governing documents, FDA credibility framework, draft Annex 22, ISPE GAMP AI, CSA, ALCOA-plus, and a footer notes the model is never edited in place. The critical-decision zone, where the model would release a lot, is drawn outside the loop behind a red Annex 22 boundary line and left empty. The model-validation lifecycle as a governed loop: intended use scopes it, risk sets how much evidence it owes, credibility evidence is measured against a pre-stated gate on a pinned ALCOA+ dataset, the validated model is locked, two drift detectors watch it, and every change runs through a PCCP and a four-eyes gate with rollback always available — the whole loop sitting inside the documents that govern it, with the critical-decision zone beyond the Annex 22 line deliberately empty. Original diagram by the authors, created with AI assistance.

That lifecycle is not a slide; it is a file you can run. The suite's run_all.py harness is the chapter's contribution, and it is deliberately not another model. It is the analogue, in code, of the FDA credibility framework and a CSA-style assurance check: a model is trustworthy not because it ran, but because evidence was produced and checked against a pre-stated acceptance criterion, on a pinned dataset, by a reproducible procedure. Most modules in the suite end with an assert over a held-out metric — the script-level equivalent of an acceptance criterion in a validation protocol — and the harness treats each module's exit code as the verdict: a clean exit is evidence the gate held; an AssertionError is documented evidence the model fails its own criterion and, under a PCCP, blocks deployment rather than being silently ignored. Where a held-out metric does not apply, the gate is a structural guarantee instead — the AVI shape contract, the curated frontier scorecards — but the principle is identical: a pre-stated criterion, checked, with the verdict recorded and the sha256 of the datasets it was fitted on pinned. Running python run_all.py prints a validation summary, not a benchmark:

model-credibility evidence harness — Book 5 suite
  dataset root: examples/datasets
  acceptance gate per model is the module's own assert

  PASS  soft_sensor_split_demo.py ch01  [raman_spectra.parquet:4d7f12c463eb]
        gate: random split inflates R2; the honest temporal split exposes the collapse
  PASS  developability.py        ch05  [(synthetic):(synthetic)]
        gate: germlining the N-G deamidation site lowers the liability score (3.0 -> 1.0)
  PASS  clone_rank.py            ch06  [(synthetic):(synthetic)]
        gate: manufacturability ranker AUROC > 0.70, beats titer-only
  PASS  bayesopt_doe.py          ch07  [(simulator):(simulator)]
        gate: BO reaches the grid optimum in fewer runs
  PASS  seed_ready.py            ch10  [(synthetic):(synthetic)]
        gate: inoculation-readiness AUROC > 0.70
  PASS  soft_sensor_pls.py       ch11  [raman_spectra.parquet:4d7f12c463eb]
        gate: Raman->titer R2 > 0.85 (within-batch interpolation)
  PASS  soft_sensor_deep.py      ch11  [raman_spectra.parquet:4d7f12c463eb]
        gate: deep soft sensor R2 > 0.85
  PASS  hybrid_model.py          ch11  [fedbatch_state.parquet:aba381af160e]
        gate: hybrid beats pure-ML extrapolation
  PASS  mpc_loop.py              ch11  [(simulator):(simulator)]
        gate: advisory MPC tracks glucose better than open-loop
  PASS  harvest_endpoint.py      ch12  [(simulated cohort):(simulated cohort)]
        gate: harvest-load model R2 > 0.70
  PASS  mspc.py                  ch18  [hplc_results.csv:e3d529ac583b, batches.csv:e3a78c7291c8]
        gate: MSPC flags ONLY the OOS batch; SPE points at HCP
  PASS  batch_mvda.py            ch18  [(simulator):(simulator)]
        gate: DTW+unfold+MPCA flags the stressed batches as trajectory outliers
  PASS  release_predict.py       ch18  [(simulated cohort):(simulated cohort)]
        gate: in-process features give AUROC > 0.70
  PASS  viral_lrv.py             ch14  [(synthetic):(synthetic)]
        gate: LRV recovers the spiking trend; 90% prediction interval covers ~90%
  PASS  vision_avi.py            ch17  [(synthetic):(synthetic)]
        gate: locked AVI head emits the per-vial 6-class shape contract
  PASS  drift.py                 ch22  [fedbatch_state.parquet:aba381af160e, offline_assays.csv:d5cae737bcad]
        gate: residual chart catches injected probe-fouling drift
  PASS  lifecycle_retrain.py     ch22  [fedbatch_state.parquet:aba381af160e, offline_assays.csv:d5cae737bcad]
        gate: challenger beats champion, back in control -> governed PROMOTE
  PASS  batch_outcome.py         ch23  [(synthetic):(synthetic)]
        gate: batch-failure AUROC > 0.80 and isotonic recalibration improves Brier
  PASS  integration_opcua.py     ch23  [(in-memory contract):(in-memory contract)]
        gate: non-GOOD writes raise MES exceptions; AD->UNCERTAIN, fault->BAD
  PASS  frontier_scorecard.py    ch28  [(curated):(curated)]
        gate: no 2024-2026 frontier capability clears all three gates for critical GMP (0/4)

credibility summary: 21/21 models cleared their acceptance gate on the pinned datasets
  every executed model produced evidence that cleared its stated gate.
  NOTE: passing the gate is necessary, not sufficient — GMP credibility
  also needs intended-use scope, change control, and human oversight.

Read that last NOTE the way an inspector would. The harness proves the evidence exists and the gate was cleared on pinned data — the necessary, machine-checkable core of step 3 of the lifecycle (FDA steps 4–6). But it ends by naming what code cannot supply: the intended-use scope, the change control, the human oversight. Those are properties of a validated system and procedure, not of a script — which is exactly the line CSA and Annex 22 draw, and exactly why a passing test suite is the beginning of a validation file, not the end of one.

Anatomy of a model-validation dossier (with its PCCP)​

The unit of governance in this chapter is not a prediction; it is the dossier — the document set that, taken together, makes a model deployable under GMP. Like every artifact in this series, its value is in what travels alongside the weights. Dissect one the way a quality reviewer or an inspector would, section by section.

Anatomy identity card of one GMP model-validation dossier for the glucose soft sensor, with seven stacked sections. An indigo header names the dossier, glucose_softsensor v4 validation file, and its status, approved for advisory use. A scope section holds the intended-use statement, advises a bolus feed, does not release a lot, mAb-A only, within the validated glucose range, with the context-of-use boundary drawn explicitly. A risk section holds the model-risk score as reliance times consequence reading medium, advisory, human-gated, mapped to the evidence depth it requires. A credibility-evidence section holds the pinned training dataset by sha256, the held-out split with its scope named honestly as a random hold-out for within-batch interpolation, the pre-stated acceptance gate R-squared above 0.85, and the measured held-out result against it of 0.9944, each marked frozen-before-testing. A controls section lists the ALCOA-plus data-governance attestation, the locked-model attestation freezing weights and scaler, and the human-oversight description. A PCCP section, drawn as a nested sub-card, holds the allowed-change envelope, the retraining trigger written as a rule, the new-version acceptance criteria, and the rollback plan, marked pre-approved. A governance section holds the four-eyes approval signatures with timestamps, the change-history log, and the next-revalidation date, all marked GxP-controlled with e-signatures under Part 11 and Annex 11. A violet relationships panel links the dossier governs the locked model version, bound-to the PCCP, evidenced-by the run_all harness output, monitored-by the PSI and residual detectors, and approved-by the quality unit. A caption notes the PCCP is the section that lets the model evolve along a path proven safe in advance. One model-validation dossier, fully unpacked: the intended-use scope that bounds everything, the risk score that sets the evidence depth, the credibility evidence measured against a gate frozen before testing on a pinned ALCOA+ dataset, the data-governance and locked-model controls, the nested PCCP that pre-approves how the model may change, and the GxP-controlled approval signatures and revalidation date — the difference between a model file and a deployable validated object. Original diagram by the authors, created with AI assistance.

Read the dossier top to bottom and the chapter is laid out as fields. The header carries the model version identity (glucose_softsensor v4) and a status — approved for advisory use — so a reviewer knows at a glance what is bound and what authority it carries. The scope field is the intended-use statement — the context of use — and it does the most work, because every other field's depth is set by it; an inspector reads this first and tests every later claim against its boundary. The risk field records model risk as influence × consequence and maps it to the evidence the file must carry; get this wrong and you either over-document a dashboard or under-prove a controller. The credibility-evidence field is the heart, and it has four sub-entries that must all be present: the training dataset pinned by sha256; the held-out split and its scope, named honestly (a random hold-out of hourly spectra here, which qualifies the model for within-batch interpolation — with the cross-batch independence Annex 22 ultimately wants carried by the calibration-transfer and drift evidence); the acceptance gate frozen before testing (R² above 0.85); and the measured result against it — the run_all.py evidence in formal dress, each entry stamped frozen-before-testing so no gate was moved after the fact. The controls field holds three attestations: the ALCOA+ data-governance attestation, the locked-model attestation (weights, scaler, feature contract, range), and the human-oversight description that names who reviews the output and decides. The PCCP is a nested sub-card precisely because it is the document's cleverest part: its four entries are the allowed-change envelope (which data and which fixed algorithm), the written retraining trigger expressed as a rule, the new-version acceptance criteria, and the rollback plan, all marked pre-approved so the model can evolve along a path proven safe in advance. And the governance field carries the four-eyes approval signatures with timestamps, the change-history log, and the next revalidation date — all GxP-controlled (GxP is the umbrella term for the Good-Practice quality regimes, GMP among them) with e-signatures under Part 11 and Annex 11, the core that makes the whole thing auditable and the human accountability unmistakable. A model file has weights; a dossier has all of these fields, which is why only the dossier can make a decision about a medicine.

The unsolved part: keeping a learning model "in validation"​

Be honest about the contradiction the documents manage but do not dissolve. GMP validation means prove the system does what it should, lock it, and prove again before any change. Machine learning means improve by changing in response to new data. A model that keeps learning is, by definition, a system that keeps changing — the one thing validation forbids without re-qualification. The PCCP is the best instrument the field has, and it is genuinely clever: it pre-approves the shape of allowed change so a retrain is a planned event, not a new negotiation. But it does not make a continuously-learning model validatable; it makes a sequence of locked models governable. Learning still happens between versions, never within one, and the draft Annex 22 codifies exactly that limit by excluding adaptive models from critical use.

There is a second, quieter limit that a careful reader should see. A PCCP can only pre-approve change inside an envelope someone imagined in advance. The drifts that actually break a validated soft sensor — a probe-fouling regime no historical batch contained, a raw-material lot outside the training distribution, a scale move that shifts the spectral baseline — are frequently the ones outside the envelope, and an out-of-envelope change is precisely what the PCCP cannot bless without a fresh validation negotiation. So the instrument is strongest against the changes you expected and weakest against the ones that actually surprise you, which is an uncomfortable inversion of where you most want protection.

The deeper unsolved residue is the one the MLOps chapter named and this chapter inherits: the only true ground-truth drift detector is lagging by construction, because the offline reference that would expose a model's error arrives once or twice a day. Between the moment concept drift begins and the moment enough sparse assays accumulate to prove it, a validated model that has started to mislead looks identical to one that is working. The PSI input-drift detector buys lead time by watching the spectra rather than the answers, but a PSI shift is only a hypothesis that the answers may have moved — it cannot confirm error without the slow truth. The PCCP tells you what to do when you detect drift; it cannot shorten the time to detect it. So a model "in validation" under GMP is really a model held in a disciplined suspicion — locked, monitored, periodically reconciled against slow truth, and assumed wrong until the data proves otherwise. The validation paradox is managed by paperwork and lifecycle, not resolved by them, and a regulator who understands this will ask not "is your model perfect?" but "what is your evidence, what is your trigger, and who signs?" The honest state of the art is that those three questions have good answers and the question behind them — how to trust a learning system unattended — does not yet.

What this chapter adds to the model suite​

This chapter's contribution is examples/platform/ml/run_all.py, the suite's governance artifact rather than another model — the code analogue of the FDA credibility framework and a CSA-style assurance check, with the subprocess-and-sha256 mechanism already detailed two paragraphs above. What is distinctive about it here is its place in the larger map: it coordinates with, and does not duplicate, the case-studies ledger (which grades external deployments by maturity and evidence tier) and the drift detectors (which monitor a deployed model). The harness sits at validation time, asserting that credibility evidence was produced against a pre-stated gate on pinned data — the necessary, checkable core of the lifecycle's evidence step — and its closing NOTE is the chapter's thesis in code: passing the gate is necessary, not sufficient; GMP credibility also needs intended-use scope, change control, and human oversight, none of which a script can supply. The harness makes the evidence auditable; the dossier and the human make it deployable.

Why it matters​

Every model in this book is a liability until it is governed. A soft sensor that drifts and mis-feeds a culture, an MSPC monitor that waves through a batch it should flag, a generative copilot that fabricates a root cause — each is a real risk to product and patient, and the only thing that converts a clever model into a defensible deployment is the discipline this chapter maps: a scoped intended use, evidence proportional to risk, a locked validated object, monitoring that never expires, and a human at every critical gate. That discipline is not bureaucratic friction layered on top of good engineering; under CSA and Annex 22 it is good engineering, focused exactly where a wrong answer would do harm. The firms that internalize it can deploy AI in GMP with confidence; the firm that did not — that let an AI generate the records governing how a batch is made and released, with no quality unit reading them — drew the first AI warning letter. The gap between those two outcomes is not the quality of the model. It is the presence or absence of the dossier, the lock, the monitor, and the signature.

In the real world​

The regulatory frame went from sparse to concrete in two years, and in 2026 it is genuinely usable. On the guidance side: the FDA's 2023 discussion paper Artificial Intelligence in Drug Manufacturing frames the questions, its 2025 AI-in-drug-development draft supplies the 7-step risk-based credibility framework, the ISPE GAMP AI Guide (July 2025) translates it into a validation playbook with its seven control layers spanning data, model, deployment, monitoring, and human oversight, and the finalized Computer Software Assurance guidance (24 September 2025) makes the whole effort risk-based and least-burdensome rather than documentation-heavy [1][2][6][7]. On the binding side: the draft EU GMP Annex 22, in EU/PIC/S consultation through 2025 with finalization expected around mid-2026, is the first manufacturing-specific AI rule — permitting only static, deterministic models for critical GMP and excluding adaptive, probabilistic, and generative AI from critical use, with the PCCP as the change-control instrument [3][4]. Underneath both, ICH Q8–Q12 and ALCOA+ are the inherited quality and data-integrity spine an AI deployment cannot opt out of [5][8]. And the enforcement anchor is now real, not hypothetical: on 2 April 2026 the FDA issued its first AI-citing cGMP warning letter (WL 320-26-58, following an October 2025 inspection), to Purolea, a firm that used AI agents to generate drug-product specifications, SOPs, and master production and control records without quality-unit review — the AI omitted a process-validation requirement and the quality unit did not catch it [9][10]. The agency cited 21 CFR 211.22(c) (quality-unit oversight) and 211.100 (production and process controls); the violation was not "you used AI" — it was that an AI produced GMP-controlling documents and no human quality unit reviewed them, the exact missing four-eyes gate this chapter's whole lifecycle is built to supply. Read the guidance, the draft rule, and the one enforcement action together and the message is one sentence: a model may advise, the evidence must match the risk, and a qualified human decides and signs.

Key terms​

  • GMP / cGMP — Good Manufacturing Practice (the "c" is current); the legally binding quality rules a drug plant must follow. A step is critical GMP when it affects product quality, patient safety, or data integrity.
  • Soft sensor — a model that infers a hard-to-measure quantity (here a concentration) from an easy-to-measure signal, standing in for a slow lab assay; the chapter's running example.
  • PLS / R² — PLS (Partial Least Squares) is the chemometric regression at the heart of the soft sensor, compressing hundreds of correlated Raman wavelengths into a few latent components; R² (coefficient of determination) scores its fit, where 1.0 is perfect and the chapter's gate is 0.85.
  • AUROC — area under the ROC curve, a 0.5-to-1.0 score of how well a classifier ranks positives above negatives; 0.5 is chance and 1.0 is perfect, so the harness's 0.70–0.80 gates are minimum useful-discrimination bars.
  • Lot / batch release — a lot (or batch) is one discrete quantity of product made together; release is the quality unit's formal decision that the lot meets its specifications and may ship. A model that "releases a lot" is making that decision — the highest-consequence use.
  • Intended use / context of use — the precise statement of what a model's output will and will not be used for; the scope from which every other validation requirement is sized (FDA framework step 2).
  • Model risk — model influence × decision consequence; the risk score that sets how much credibility evidence a model owes (FDA 7-step framework, step 3).
  • Credibility-assessment framework (FDA 7-step) — question of interest → context of use → model risk → credibility-assessment plan → execution → results → adequacy; the risk-proportionate structure that governs trivial and high-stakes models alike, looping back to tighten the context of use if evidence falls short.
  • Static (locked) model — a model frozen after validation so the same input yields the same output for its whole life; deterministic at inference, and the only kind Annex 22 permits for critical GMP use.
  • Dynamic / adaptive model — a model that continues to learn (online) in production; excluded from critical GMP use under draft Annex 22 because it cannot be validated by a one-time test.
  • Draft Annex 22 — the draft EU/PIC/S GMP annex on AI (consultation July–October 2025): permits only static, deterministic models for critical use, excludes adaptive, probabilistic, and generative AI, and requires intended purpose, risk assessment, data governance, test-data independence, human oversight, acceptance criteria fixed before testing, and continuous monitoring.
  • Predetermined change control plan (PCCP) — a pre-approved written specification of how a model may change (allowed-change envelope, frozen algorithm, acceptance criteria, rollback), so a retrain inside the envelope is a planned event rather than a new regulatory negotiation; borrowed from the FDA device framework.
  • Locked-then-relearn — the only pattern permitted for critical applications: lock a model, run it, detect drift, retrain off-line into a new validated version, promote through change control; learning happens between versions, never within one.
  • ISPE GAMP AI Guide — the July 2025 practitioner playbook extending GAMP 5 (2nd edition)'s risk-based, lifecycle, V-model validation thinking to AI/ML, with its seven control layers spanning data, model, deployment, monitoring, and human oversight.
  • Computer Software Assurance (CSA) — the FDA's risk-based, critical-thinking approach to software assurance (finalized September 2025): least-burdensome evidence focused where a failure would harm product or patient.
  • ALCOA+ — Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring, Available; the data-integrity properties every datum that trains, tests, or feeds a model must hold, defended in part by a dataset content-hash.
  • Test-data independence — Annex 22's requirement that test data be genuinely held out from training (for time series, split by time, not shuffled); overlapping test and training data invalidates a model's credibility evidence.
  • Semantically-grounded feature / label — a model input or target pulled by its stable ontology IRI and carried as a typed, unit-bearing value, so it cannot silently become a different measurement when a source system is re-mapped; the structural form of ALCOA+ Original and Accurate for training data (identifiers and units).
  • SHACL admission gate — running the same closed-world bp:ReleaseShape (every required CQA present, singular, typed, in range) over a candidate training subgraph before it becomes a row, so a hollow or mislabeled record is caught in front of a reviewer; the labeling contract for a PASS/OOS release predictor (the release gate and SHACL).
  • Lineage grouping key (derivedFrom) — the transitive genealogy edge that ties sibling lots to one working cell bank; the grouping key an honest leave-one-batch-out cross-validation splits on, so a cross-batch generalization score is not flattered by sibling leakage (relations and genealogy).
  • Four-eyes gate — the requirement that a second qualified person review and sign the promotion of a model version or the AI-generated record; the control whose absence drew the Purolea warning letter.
  • Purolea warning letter — the FDA's first AI-citing cGMP warning letter (WL 320-26-58, 2 April 2026), against a firm that used AI to generate GMP records without quality-unit review; cited under 21 CFR 211.22(c) and 211.100; the enforcement anchor.

Where this leads​

The rules are mapped, the lifecycle is worked, and the one enforcement action shows exactly where the line falls: a model advises, a human decides, and the evidence must match the risk. That is the governed present. The final substantive chapter, The Frontier: Foundation Models, Autonomous Labs, and Agentic AI, looks the other way — at the self-driving bioreactors, federated learning, bioprocess foundation models, and agentic AI that promise to move the line, and asks honestly how far each has actually traveled from a controlled demonstration toward routine commercial GMP use. The governance chapter tells you the conditions under which a real deployment becomes defensible; the frontier chapter tells you which of tomorrow's capabilities can meet those conditions, and which are, for now, on the wrong side of both the evidence and the rule.