Define what the validated result is intended to support
Describe the material, matrix, reference standard, biological mechanism, reportable potency and unit, range, decision context, laboratories, instruments, and routine workflow. Identify which steps belong to the analytical procedure and which records and decisions the software must control.
For relative potency, define how reference and test responses are compared, any restrictions, preparation corrections, and how an invalid or non-estimable result is handled.
Select relevant performance characteristics
Q2(R2) provides a general framework rather than a universal bioassay recipe. The protocol should explain why each characteristic is relevant, how it is studied, and how the evidence supports the analytical target profile.
| Characteristic | Potency-assay considerations |
|---|---|
| Accuracy | Agreement using suitable reference, spiking, orthogonal, or expected-mixture evidence |
| Precision | Repeatability and intermediate sources such as days, analysts, instruments, lots |
| Specificity | Matrix, related materials, interference, and mechanism-relevant controls |
| Range | Potency levels where accuracy, precision, and model behavior are acceptable |
| Robustness | Deliberate changes to critical method parameters |
| Stability | Reference, samples, reagents, and prepared-plate conditions where relevant |
Predefine calculations and acceptance criteria
Specify the experimental unit, transformations, variance model, confidence intervals, pooling, missing data, exclusions, model restrictions, weighting, and rounding before examining validation outcomes. Criteria should map to the intended use and expected sources of variability.
A system-suitability rule used per routine plate is not automatically a validation acceptance criterion, and a validation-wide precision estimate is not automatically a per-run limit. Keep their purposes distinct.
Connect each requirement to its evidence
Link every protocol requirement to the raw data, analysis settings, software version, calculation output, deviation or exclusion, observed result, criterion, and conclusion. Generate tables and plots from the saved result values so changing the report format cannot change the calculation.
Include the analyst and analysis date, model parameters, system-suitability outcomes, fingerprints for the source data file and analysis configuration, report-template version, and signatures or approvals only when the workflow actually captures them.
Evaluate the system as it will be used in your laboratory
Vendor tests and release records can support customer validation, but they do not qualify the deployed system by themselves. Consider access, records, audit trails where required, backup and restore, connections to other systems, calculations, reports, controlled settings, deployment, procedures, training, and change management.
Provenarium is designed to provide records and controls that can support this work. Using the software does not by itself make a customer’s assay, process, or deployed system validated or compliant.
Frequently asked questions
What acceptance criteria should a relative-potency validation use?
There is no universal set. Define criteria from intended use, assay behavior, risk, development evidence, applicable guidance, and scientific/statistical review.
Must every Q2(R2) characteristic be studied?
Select characteristics appropriate to the procedure and its purpose, documenting the rationale. Consult the final guidance and your quality/regulatory experts.
Does a reproducible PDF make a system compliant?
No. A report is one record. Compliance and data integrity depend on the implemented controls, records, procedures, people, and operating environment.