Completion is not effectiveness
Verification of implementation asks: did we do the thing we said? An effectiveness check asks: did doing it change the outcome? The first is a record-keeping question. The second is the one the CAPA exists to answer, and it cannot be answered on the day the action is completed — only after enough of the process has run through the change to show something.
The second version can fail. That is what makes it a check.
The four things a defensible check states
- What is measured. A specific, observable thing — a signature present, a deviation of a named type, a result within a range. Not "compliance with the revised procedure."
- Over what window. A start and an end, chosen so enough of the process runs through it to mean something. A check over two batches when you make forty a quarter has measured almost nothing.
- Against what threshold. The number that decides pass or fail, written before the data exists.
- Decided by whom. A named role, so the judgement has an owner.
The test that matters: could this check have failed? If there is no result the process could have produced that would have failed it, it is not a check — it is a formality with a signature. Write it before you have the data, and this stays honest by construction.
What does not count
- Training completion. Shows the action was implemented. Says nothing about whether behaviour changed.
- The action itself, restated. "Procedure was revised to require verification" is the action, offered as evidence for itself.
- "No recurrence to date" with no window. To date is not a period. Without a stated window and a volume, it means only that nobody looked.
- A document review with no criterion. "Records were reviewed and found acceptable" — acceptable against what?
- A check that could not fail. If the measure is whether the revised SOP exists, the answer was determined the day it was issued.
Choosing the window
The window should be long enough that the failure mode had a fair chance to reappear. For a changeover error, that means enough changeovers — not enough calendar. For something seasonal or campaign-based, it means covering the conditions the failure occurred under. A check that runs across a plant shutdown has measured a quiet period.
Where volume is genuinely low, say so and give the number. "Six changeovers occurred in the window; all six complete" is honest and lets a reader judge the weight. "No recurrence observed" hides the six.
A failed effectiveness check is a working quality system, not a black mark. It means the check was capable of detecting something and did. The record that never fails one is the record a reader stops trusting.
Why it has to be defined up front
A check written after the action has been running is shaped, unavoidably, by the data that exists. The window lands where the data is clean; the threshold settles just above what was achieved. Nobody decides to do this — it is what happens when you design a test knowing the answer.
Defining it when the action is written costs a few minutes and removes the question entirely. It also forces a useful conversation at the right moment: if you cannot say what would show this worked, the action may not be specific enough to work.
Where this sits in Dry Run. The quality-event criteria pack checks the mechanical parts — whether a verification step is named at all, whether a window and a threshold are stated, whether the stated action connects to the stated cause. Each criterion carries its regulatory reference as fixed text written by a person, not generated per run.
Whether your threshold is scientifically right, or your window long enough for your process, is judgement — and a screening that returns REVIEW there is saying the document did not contain enough to decide. That is a real answer, and filing it as satisfied is the mistake worth avoiding.
See how a CAPA record screens. The demo runs a canned quality-event record and returns per-criterion findings, including where verification is missing.