--- name: corrective_action_tracking description: Run corrective action (CAPA) end to end: contain the problem, run root-cause analysis with 5 Whys and fishbone, build an action plan with named owners and dates, extend the fix to similar processes, and verify effectiveness against criteria set in advance before closing. Use when a defect, incident, audit finding, complaint, or nonconformity keeps recurring, or when someone asks to open, track, escalate, or close a CAPA or corrective action. --- # Corrective Action Tracking ## Purpose Stop a problem from happening again, and prove it stopped. A corrective action record that only lists tasks done is a to-do list, not a CAPA. This skill runs the full loop that FDA 21 CFR 820.100 and ISO 9001:2015 clause 10.2 both require in substance: react and contain, investigate the cause, act on the cause, check whether similar problems exist elsewhere, review effectiveness, and keep documented evidence of the problem, the actions, and the results. Use the tracker in `bin/capa_tracker.py` to enforce the gates. It refuses to close a record that has unfinished actions or no passing effectiveness check. ## Workflow 1. **Open and contain first.** Record the problem in one specific sentence: what happened, where, when detected, how much is affected, and how you know. Then separate three things that teams constantly blur: - **Correction:** the immediate fix for the detected problem (rework, reissue, roll back, quarantine, notify affected customers). This stops the bleeding. It does not prevent recurrence. - **Corrective action:** action that eliminates the cause so the same problem does not recur. - **Preventive extension:** the same cause checked, and fixed if present, in similar products, lines, services, or processes where the problem has not happened yet. Containment comes before analysis. If affected product, data, or customers are still exposed while the team debates causes, containment is the first action, with its own owner and time. 2. **Triage by risk, and set the clock at intake.** Score severity (harm or impact if it recurs), reach (how much is already affected), and detectability (would you catch a recurrence quickly, or only after a customer does). High risk gets a cross-functional owner, a short containment clock, and management visibility. Low risk still gets a named owner and a due date. The level of effort, formality, and documentation should be commensurate with the level of risk. That risk-proportionate principle is stated in ICH Q10 for CAPA and in the FDA inspection program for drug CAPAs. There is no universal 30 or 90 day rule. Set dates from risk, write them down at intake, and treat a date change as a decision that needs a reason and an approver, not a quiet edit. 3. **Investigate to a cause you can act on.** Follow the ASQ sequence: describe the problem, collect and analyze data, identify possible causes, evaluate and prioritize them, then act. Full method detail is in `references/rca-methods.md`. - Start with evidence, not opinions: records, logs, samples, trend data, the actual item or output that failed. - Use a fishbone diagram to map breadth across People, Machine, Method, Material, Measurement, and Environment, then use 5 Whys to go deep on the branches the evidence supports. - Test each candidate cause before adopting it: if this cause were removed, would the problem still occur? Could you reproduce or observe the cause at work? A cause you cannot test is a hypothesis, label it that way. - Stop at a system cause: a missing check, an ambiguous procedure, a design that allows the error, training that never covered the case, a supplier input with no incoming check. "Human error" and "retrain the operator" are not root causes. They are where weak investigations stop. Ask what in the process allowed the error and why it was not caught. - Check extent: has this cause produced the same problem before, and does it exist in similar processes? ISO 9001 clause 10.2 requires determining whether similar nonconformities exist or could potentially occur. Record the answer, even when it is no, with the search you ran. 4. **Build the action plan.** One row per action: action, owner (a named person, never a team), due date, and the evidence that will show it is done (revised document number, test result, configuration change, training record with names). Rules for a plan that holds up: - Every confirmed root cause gets at least one action that removes or controls that cause. An action list that only contains training and a memo rarely removes a cause. - Prefer actions that make the error impossible or self-detecting (a forcing function, an automated check, a design change) over actions that rely on people remembering. - Include the change itself: update the procedure, drawing, code, checklist, or spec the action changes, and record the new version. FDA 820.100 explicitly requires implementing and recording changes in methods and procedures. - Include dissemination: who else needs to know, and how they were told. - Write the effectiveness criteria now, at plan approval, not after implementation. See step 6 and `references/verification-criteria.md`. 5. **Implement, and verify implementation separately from effectiveness.** Mark each action done only with its evidence attached. Verification of implementation answers: was the change actually made as planned? Effectiveness answers a later, different question: did the problem stop? Closing a CAPA the day the last task is checked off skips the second question, and inspectors treat that gap as a finding. 6. **Verify effectiveness against criteria set in advance.** The check needs four parts, all written before or at implementation: - **Metric:** what you will measure (recurrence count for the same failure mode, defect rate, error rate in the affected step, audit sample result). - **Threshold:** what counts as pass (for example, zero recurrences of the same failure mode, or the rate back inside its prior control limit). Pick a threshold the data can actually decide. - **Window:** how long or how many cycles you will observe. The window must be long enough for the problem to plausibly recur. A weekly failure needs weeks of observation, a quarterly process needs cycles, not days. One FDA inspection compliance summary describes reviewing nonconformances for four quarters after implementation when judging a significant CAPA, which shows the scale inspectors expect for slow processes. - **Adverse-effect check:** did the fix break something else? FDA 820.100 requires verifying the action is effective and does not adversely affect the finished device. The general form holds anywhere: check the outputs adjacent to the change. If the problem recurs inside the window, the check fails. Do not extend the window and call it a pass. Reopen the investigation: either the cause was wrong or incomplete, or the action did not remove it. Record the failure in the same record so the history stays visible. 7. **Close, or risk-accept in writing.** Close only when: containment is complete, every action is done with evidence, the effectiveness check passed on its pre-set criteria, and the extent check is recorded. `bin/capa_tracker.py close` enforces the first three. If leadership chooses to accept the remaining risk instead, record who accepted it, their authority, the residual risk, and a review date. A silent timeout is not risk acceptance. 8. **Run the register, not just the record.** Review the whole open list on a fixed cadence: - Overdue actions, oldest first, with the owner present. - Records awaiting effectiveness checks whose windows have elapsed (these are closable work, not paperwork to defer). - Recurrence report: any problem that matches a closed CAPA reopens that question in the review. - Trend view: group open and recent records by cause category. Three CAPAs with the same system cause in a quarter is a system problem, and it belongs in management review. FDA 820.100 requires submitting relevant information on quality problems and CAPAs for management review, and using statistical methodology where necessary to detect recurring problems. Run `bin/capa_tracker.py report --as-of YYYY-MM-DD` for the counts, overdue list, and checks due. ## Output Contract - CAPA record: ID, problem statement, source (complaint, audit, incident, trend, internal detection), severity and risk triage, containment actions with owner and completion evidence. - RCA write-up: evidence reviewed, methods used, candidate causes tested and ruled out with reasons, confirmed root cause(s), extent check result. - Action plan: one row per action with owner, due date, completion evidence, and the document or system change it produced. - Effectiveness plan and result: metric, threshold, window, adverse-effect check, observed data, pass or fail verdict, reviewer, and date. - Closure note: criteria met, or written risk acceptance with approver and review date. - Register report: open count by status, overdue actions, effectiveness checks due, recurrence flags, cause-category trend. ## Operating Rules 1. Correction is not corrective action. A record whose only response is fixing the instance in front of you stays open. 2. No owner, no date, no action. Every action carries a named person and a due date, or it does not enter the plan. 3. Effectiveness criteria are written before the check runs. Criteria invented after seeing the data prove nothing. 4. Implementation is not effectiveness. Both verifications happen, in that order, and the second one waits for its window. 5. A recurrence inside the window is a failed check and a reopened investigation, never a reason to quietly extend the window. 6. "Human error" is a starting point for the next why, not a root cause and never a closing cause on its own. 7. Effort and documentation scale with risk. A minor record can be short; it still needs a cause, an owner, and a check proportionate to how often the problem could recur. 8. Date changes are decisions. Record the old date, the new date, the reason, and who approved it. 9. Never invent numbers, dates, quotes, or events in a record. Where evidence is missing, write that it is missing and what you did to look for it. 10. Style for all output from this skill: no em dashes, plain direct sentences, no filler. Write the record so a third party reading it a year later can follow what happened, in order, from the evidence alone. ## References - `references/rca-methods.md`: 5 Whys, fishbone, is / is-not, Pareto, and cause-testing, with when to use each and where each one fails. - `references/verification-criteria.md`: how to write effectiveness criteria that can actually pass or fail, window sizing by recurrence rate, and worked criterion examples. - `references/worked-cases.md`: three illustrative cases run through the full loop, including one failed effectiveness check and reopen.