A January 2026 AAPS PharmSciTech paper proposes normalising every residue result to a percentage of its own specification limit, so that cleaning data from different products can finally be pooled, analysed non-parametrically and monitored as a Stage 3 capability index. The statistical argument is the substance; the AI framing is thinner than the title suggests.
What happened
On 26 January 2026, AAPS PharmSciTech published an open-access research article by Xiande Yang, Wendy Lou and Mohamed Chan: Specification Limit Normalization for Nonparametric Process Capability Analysis and Its Application in Cleaning Validation with AI-Enabled Monitoring Models (AAPS PharmSciTech 27, article 87; DOI 10.1208/s12249-025-03267-5). It addresses three familiar obstacles: multiple upper specification limits (USLs) from product-specific HBELs on shared equipment, frequent non-detect residues, and small, discontinuously collected samples driven by selective swab testing after product changeovers.
The remedy is a transformation, not a new test. Each residue value is expressed as a percentage of its own USL — DAR_Pct = (DAR/USL)×100, likewise for cleaning agent residue (CAR) and microbial bioburden (Mic) — so all limits collapse onto USL_Pct = 100 and heterogeneous datasets can be pooled on one relative risk scale. Capability is then estimated non-parametrically: kernel density estimation (Silverman bandwidth 1.06, Gaussian kernel) supplies the P0.5 and P0.99865 percentiles, giving Ppu = (100 − P0.5)/(P0.99865 − P0.5) under the algorithm the authors call KDEDPonUSLND. Two new aggregation strategies for process-level Ppu are proposed — CQA-wise worst case (CQAWWC) and CQA-wise pooling (CQAWP) — replacing the traditional subgroup-wise worst case (SWWC).
The authors report process Ppu of 2.159 by SWWC, 2.568 by CQAWWC and 2.699 by CQAWP; subgroup values differ by more than an order of magnitude across USLs — the effect normalisation makes interpretable.
For Stage 3 monitoring, a bootstrap-assisted variant (BAKDEDPonUSLND) derives a 95% confidence interval lower limit (CIL) from 1,000 iterations, refined to 10,000 if needed, and that CIL becomes the monitoring threshold. Training gave Ppu = 2.528 with CIL = 2.304; monitoring Ppu was 2.568. Retraining uses a rolling window of recent in-control events, with confirmed OOS events removed. The authors state the model runs in production in Apotex's CV-SARWAS system on Azure Databricks, fed from LIMS and QMS sources, with R Quarto reports enriched by narrative summaries from functions or an LLM via API. Model code is public on GitHub; other code and configuration are proprietary.
Why it matters
The status quo described will be familiar to anyone who has audited cleaning statistics. Practitioners run parametric Ppu on non-normal data, apply a non-parametric worst-case method to samples too small to support it, or — worse for data integrity — pick one intermediate USL and apply it to all measurements.
The normalisation argument is easy to defend: the analytical population is not the bare residue value but the pair (residue, USL), because the programme is about control relative to an allowable limit, not absolute magnitude. It preserves outliers and OOS results within each subgroup, highlights the highest-risk events in pooled data and — importantly for reviewers — leaves Ppu, Ppl and Ppk invariant within a subgroup. For a single-USL dataset the authors show their indices match the ISO 22514-4 non-parametric values: an extension of accepted practice, not a departure from it.
What is particularly interesting
First, the paper is candid about its own acronyms: parametric least-USL and parametric SWWC methods are "strongly discouraged", non-parametric SWWC becomes unreliable at small sample size, and the intermediate-USL practice is described as a direct data integrity violation. Unusually direct language for a journal article — and the sentence most worth reading aloud to a sceptical quality unit.
Second, the statistical case comes before any mention of AI, and it is the stronger half of the paper. The AI element has two parts: bootstrap-assisted percentile estimation in a train/monitor/retrain lifecycle, and LLM-generated narrative summaries in automated reports. No supervised machine learning model is trained on historical cleaning data here. "AI-enabled" means automation and uncertainty quantification around a non-parametric estimator, not a learned predictor replacing the statistician.
Third, the governance observations are concrete. Because KDE output depends on bandwidth and computational environment, the authors require all users in a group to run identical cluster runtimes (Databricks 16.1 versus 16.4 can shift decimal precision) and that this be documented in the SOP. The system was validated under GAMP 5 with URS, SDS, risk assessment and IQ/OQ/PQ; reports are reproducible and not user-editable, and authorship sits with the human who submits them.
Limitations the authors acknowledge
Left-censored data is not solved. Non-detect results were replaced with LOD or LOQ values; the authors recommend applying Walsh et al.'s methods for CV non-detect data before running KDEDPonUSLND. Non-parametric estimators also remain sensitive to bandwidth choice, though kernel selection matters little.
The evidence base is one cleaning process on one piece of equipment: DAR from 10 events (6 swab locations each; USLs 169.7, 122.2, 20 µg/swab), CAR from 11 events (3 locations; USL 103.1 µg/swab), Mic from 10 events (2 locations; USL 25 CFU/swab), 100 cm² swabs. Real production data, not simulation — but a single case; generality is asserted, not demonstrated. The comparison with commercial platforms (Leucine CLEEN and AmpleLogic as worst-case based; Kneat, from industry sources rather than direct access, as not using USL-normalisation) is positioning, not benchmarking.
Wider context
The authors claim alignment with ASTM 3106 and note applicability beyond cleaning: Stage 3 manufacturing CPV where both USL and LSL exist, plus non-parametric variance component analysis for root cause work. Read it as a statistical contribution with an automation story attached, not as an AI paper.
Sources
Yang X, Lou W, Chan M. Specification Limit Normalization for Nonparametric Process Capability Analysis and Its Application in Cleaning Validation with AI-Enabled Monitoring Models. AAPS PharmSciTech 2026;27:87. https://doi.org/10.1208/s12249-025-03267-5 (code: https://github.com/ChandlerXiandeYang/USL_unification).
Validation takeaway
The transferable idea here is not the AI label — it is the reframing of the analytical population. In a multi-product cleaning programme, a residue value carries no risk meaning on its own; only the pair (residue, its own allowable limit) does. Expressing each result as a percentage of its respective USL turns heterogeneous data onto one relative risk scale with a single threshold at 100%, which permits pooling, supports non-parametric capability estimation at defensible sample sizes, and produces a Ppu that is invariant within subgroups and consistent with ISO 22514-4 when only one specification limit exists. For teams, the immediate action is diagnostic rather than technological: establish what your current Ppu calculation actually assumes, whether the data meets those assumptions, and how non-detects and multiple limits are being handled. For Stage 3 continued cleaning process verification, capability should be monitored against an uncertainty-aware threshold — a confidence interval lower limit, not a single point value — with pre-defined responses to warning and not-capable signals and a periodic retraining or re-evaluation cycle. Automation, including LLM-assisted reporting, is a delivery mechanism on top of that statistical foundation; it does not substitute for it, and each automated element needs its own validation, fixed computational environment and documented human accountability. This is one paper on one equipment train: treat the method as a well-argued proposal to pilot and verify against your own data, not as a settled GMP requirement.
Questions worth asking in our own programme
- When our cleaning data spans several product-specific USLs, what do we currently do — pool it under one limit, apply the lowest limit to everything, or skip the capability index? Can we document the choice?
- Do we treat our analytical population as residue values alone, or as (residue, USL) pairs? If the former, our Ppu is measuring the wrong thing.
- Have we tested normality of our cleaning data (Shapiro-Wilk or equivalent) before applying parametric Ppu, and is that test documented per CQA?
- If we moved to USL-normalised pooling, would we choose CQA-wise worst case or CQA-wise pooling — and can we articulate that choice to an auditor in terms of risk rather than convenience?
- How do we currently handle non-detect results in capability calculations? If we substitute LOD or LOQ without a documented method, what is the statistical justification?
- If we built a Stage 3 monitoring threshold today, would it be a point estimate or a confidence interval lower limit — and what triggers an investigation versus a warning?
- For any automated or AI-assisted cleaning monitoring, is the computational environment (software versions, runtime, bandwidth and kernel settings, random seeds) fixed, documented and change-controlled so that outputs are reproducible?
