CAPA Closure Criteria: The Six Things That Have to Be True Before "Closed" Means Anything

A quality engineer working corrective action responses put it plainly in a thread about verification windows: "In my experience 30 days can be a very difficult default. Where I was, some of the more commonly-ordered parts would only be received every 30 days. 90 days was a much more reasonable default." Then, a beat later, the harder admission: "To be honest that 90 day default was there before I arrived, I'm not sure if they ever practiced 30."

That second line is the real finding. The window wasn't sized to anything. It was inherited from whoever set up the form years earlier, and nobody since had asked whether it matched how often the part actually ran. A CAPA can pass every gate on a closure checklist and still be closing against a number nobody chose on purpose.

"Closed" on a CAPA record is a claim. It says: we contained it, we found the cause, we fixed it, we proved the fix held, and someone other than the person who did the work looked at the evidence and agreed. Every one of those five things can be true, or every one can be a checkbox ticked to make the record go away. The gap between the two is where the same defect comes back eighteen months later with a different revision number on the 8D.

Here are the things that actually have to be true, and what happens in the system when they aren't.

"30 Days Is Just a Thumb Rule and Not Mandatory"

A quality engineer responding to the same thread named the problem in one line: "30 days is just a thumb rule and not mandatory, it highly depends on the process time." A quality control and assurance engineer went further, pushing back on treating the window as a procedure step to survive rather than a question to answer: it is not a matter of running the standard CAPA/AS9100 playbook and waiting out a fixed clock.

The platform does not let the window default to a fixed number either. POST /capa/{id}/verify-closure requires an explicit choice among 30, 60, or 90 days (backend/app/api/v1/capa.py, VerifyClosureRequest.recurrence_check_days, validated server-side against exactly that set) and stamps recurrence_check_date from whichever one the engineer picks at the moment of verification, not from a form template default. That does not solve the sizing question by itself; a person still has to know that a part ordered every 30 days needs a 90-day window to see a second lot come and go. What it does is force the choice to be made explicitly, on the record, instead of inheriting whatever number the last person who built the form typed in.

"We Checked It" Versus "We Can Prove We Checked It"

A quality engineer working traceability described the gap this way: the distinction between saying you checked something and being able to show it. Verification happened; the evidence just lives in someone's memory of having done it, not in anything an auditor can pull.

That distinction is why the close-gating logic on a CAPA does not accept a signature by itself. _check_close_gating (backend/app/api/v1/coach.py) requires voe_verified to be true and requires actual verification content, checked across effectiveness_criteria_text, verification_method, verification_result, and closure_evidence (any one populated satisfies the check; a fix landed here specifically because engineers were writing thorough verification prose into verification_method and getting flagged as missing because the older check only looked at the dedicated column). A "verified, trust me" note with no measurable criterion behind it does not clear the gate.

The sharper version of "prove it" lives in CapaVerificationRecord (backend/app/api/v1/capa_verification.py), a typed table for verification-of-effectiveness evidence rather than a free-text field. A training-based verification links a real training assignment through the roster bridge and shows its live completion status; an inspection-based verification links an existing, completed inspection record by foreign key, not a description of one. The record is either backed by another system's data or it says so.

The Metric Can Validate the Plan While One Person's Habit Runs the Process

A recurring observation in the same discussion, restated here rather than quoted verbatim: a metric can validate a control plan on paper while the thing actually holding the process in tolerance is a fixture, or a habit, that the plan never wrote down. The number passes. The mechanism the number is supposed to describe is somewhere else entirely.

This is the failure mode verification_result is supposed to rule out and usually doesn't, because a passing number and a genuine explanation of why it passed are two different things. The AI auto-check that recommends sign-off attestations (backend/app/services/coach/signoff_auto_check.py) is built around exactly that gap: it confirms voe_not_verified only when the verification narrative describes the corrective action holding under normal production conditions over a stated period, not when a Cpk number simply shows up with no explanation of what changed to produce it. The check does not know whether the mechanism is real. It knows whether the record says what the mechanism was, which is the minimum an auditor, or the next engineer who inherits the part, needs to tell a real fix from a lucky week.

Verification Signed by the Person Who Did the Action

The structural conflict of interest in most CAPA closeouts is not hidden, it is just tolerated: the engineer who wrote the corrective action is usually the one asked to confirm it worked, on the same form, the same week the customer wants the response back.

_check_close_gating has a specific rule for this. When reviewer_mode is "human", closure fails on the reviewer_is_originator code if reviewer_id matches created_by, unless the user explicitly attests around it through the sign-off panel. An AI-assisted review path exists as an alternative, gated on the originator explicitly acknowledging the AI's assessment rather than silently inheriting it. Either path requires a second party, human or disclosed AI, in the record. Self-grading is possible only if someone deliberately clicks past a checklist item that names the problem out loud.

No Rescore of the PFMEA Line

Closing a CAPA does not, by itself, touch the PFMEA. That is worth saying plainly rather than glossing over, because the platform's own document cascade makes it easy to assume otherwise. PFMEA rescoring is a real, separate workflow: it checks eligibility on a PFMEA document, pulls the closure notes from the tasks actually linked to that PFMEA's rows, and lets an engineer submit a new occurrence and detection score with severity locked so the record can't quietly reclassify the hazard on the way down. But nothing in verify_closure or the close-gating checks calls that workflow. A corrective action can close with a torque value changed, an inspection frequency doubled, and a training record updated, and the PFMEA row that originally scored the risk stays exactly where it was until someone opens the rescore tool on purpose.

That is a real gap in the closure claim, not a platform failure to disclose. The record can be honest that a rescore is due and still not do it for you. How to close a CAPA so it actually stays closed covers the wider version of the same problem: propagation to a linked document is a separate step from closing the record, on this platform and on every other one, and the six-condition list here is what "closed" has to mean before that propagation step is even reachable.

The Follow-Up That Exists, and the One That Doesn't Yet

Here is where a specific claim needs a specific correction. There is an hourly beat in the system, check_recurrence_due (backend/app/services/followup_scheduler.py), that checks for CAPAs whose recurrence_check_date has come due and nothing has flagged a recurrence, and it automatically creates a follow-up action item plus a notification for an org admin: pull the NCR and complaint history since closure, confirm the fix held, mark recurrence if it didn't.

That beat is real, and it is not universal. It is scoped, in the code, to delivery_mode == "otto_delivered", Otto's delegated-CAR track. A self-service CAPA, which covers the overwhelming majority of records on the platform today, gets the recurrence-check date written to the row and nothing else. Nobody gets pinged when it comes due. The engineer who set the 90-day window has to remember to come back and look, which is precisely the failure mode the practitioner quote at the top of this post was describing: a date on a record is not a system, it's an intention.

Otto's own role here is disclosed the same way it is everywhere else on the platform: she prepares the record and can draft the five-why chain and the effectiveness criteria, and on a delivered CAR she gets the automatic recurrence follow-up wired to her queue. A human still verifies the evidence, still reviews independently of whoever wrote the corrective action, and still closes the record. She never signs.

What Closed Actually Has to Mean

Six things, checked against the record and not against the form: containment happened and is described with a scope. Corrective action is recorded as a system change, not a one-off fix. Effectiveness criteria exist somewhere in the record, measurable, not a sentence promising to monitor. Verification is marked verified against evidence, ideally a linked record rather than a claim in a text box. An independent reviewer, human or disclosed AI, looked at it. And the recurrence window, sized to how the part actually ships and not to a form default, either ran out clean or got flagged.

Miss any one of those and the record can still say "closed." That's the point of writing this down: the word on the status field and the six conditions underneath it are not the same thing, and the gap between them is exactly where a defect walks back in.

CAPA effectiveness verification goes deeper on the acceptance-criteria and observation-window math. CAPA effectiveness metrics covers how to track this across a CAPA program instead of one record at a time. 8D vs CAPA untangles the response format from the management system when the two get conflated. The 5 Why and Fishbone AI coach is where the effectiveness criteria and the five-why chain usually get drafted in the first place. And if the corrective action was triggered by a PPAP rejection rather than a floor defect, PPAP rejection reasons and how to catch them covers what has to be true before the resubmission goes back out, which is the same discipline running one stage earlier. Supplier risk scoring is where a pattern of CAPAs that don't hold shows up at the supplier level instead of the single-record level.

Start the next CAPA in Correct and see the closure gate before the record ever gets to the door. The 30-day, no-card trial covers the full workflow: get started.