Right assay, wrong endpoint
A method can pass every transfer requirement and still fail in routine use. The usual reason is not a bad method. It is a transfer package that measured the wrong thing.
Robustness studies are usually built around the analyte: does the measured attribute stay stable across handling time, temperature, and operator? That is necessary and not sufficient. A result also has to be reportable. If sample quality degrades faster than the analyte does, rising debris, falling viability, or background that swamps the population, the analyte can be perfectly stable while the result becomes unreadable.
The fix is to carry reportability attributes into robustness and transfer studies from the start: the rate of non-reportable results, the quality metrics that decide whether a run can be read, and the precision at the edges of the handling window. If a study only asks whether the thing you measure survives, it cannot tell you whether you will be able to measure it.
Two methods, two instruments: why Passing-Bablok
When a method moves to a new instrument or a new site, the question is not whether the two sets of results correlate. They almost always do. The question is whether they agree, and if not, how.
Ordinary least squares assumes the reference method has no error, which is rarely true when both are real assays. Passing-Bablok regression makes no such assumption, is robust to outliers, and separates two different problems: a constant bias (the intercept confidence interval excludes zero) and a proportional bias (the slope confidence interval excludes one). They have different causes and different fixes.
Pair it with a Bland-Altman plot, and decide the acceptable limits of agreement before looking at the data. A p-value tells you whether a difference is detectable; only a pre-set criterion tells you whether it matters. You can try both in the method comparison tool.
What an inspector checks in flow cytometry data
Flow cytometry is unusually exposed in an inspection because so much of the result depends on analyst decisions after acquisition. The questions tend to follow the data:
- Can every reported number be traced to the raw file it came from, and is that raw file protected from change?
- Are analysis templates version-controlled, and can you show which version produced which result?
- Who can change a gate, and does the audit trail show when, why, and by whom?
- Are instrument settings and quality control records tied to each run?
- When a result was reprocessed, is the original preserved and the reason documented?
Most findings are not about the science. They are about whether the record proves the science was done the way the SOP says.
Governing AI in GxP change control
AI tools are useful in investigations and change control, for surfacing hypotheses, drafting assessments, and checking consistency. They are also fluent, and fluent is not the same as correct. An AI-suggested root cause can gather momentum before anyone tests it.
The controls that work are familiar ones: treat AI output as a supplemental input, never as the decision; require documented human review of anything it contributes; record where it was used; and test its hypotheses against data the organization already owns before committing resources. Defining what an output must satisfy before you trust it is a regulated discipline, and it applies to models the same way it applies to methods.