A PFMEA gets built for a new program, reviewed, signed off, and filed alongside the control plan. Eight months later, a repeat defect on OP-40 triggers a corrective action. Someone adds a poka-yoke fixture, closes the task, and moves on. The PFMEA that flagged that failure mode in the first place still shows the original occurrence and detection ratings from before the fixture existed, because nothing in the process forces anyone to go back and update it. The document that was supposed to be the living record of process risk quietly stops being current the moment the first corrective action closes against it.
This is not a discipline problem, it is a workflow gap. Nobody sits down once a quarter to reconcile every closed corrective action against every PFMEA row it touched, because a spreadsheet gives you no way to know which rows need a second look, no way to lock the fields that should not change, and no way to show a before-and-after number when an auditor asks whether a corrective action actually worked. This post covers what a PFMEA rescore workflow does differently, and why the mechanics of "did the risk go down" turn out to be more specific than they look.
Why rescoring is a narrower problem than "update the PFMEA"
The instinct is to treat this as a document-update problem: someone edits the PFMEA row, changes a number, done. But an FMEA row is not one number, it is three ratings that mean different things, and only two of them are legitimately allowed to move after a corrective action closes.
Severity rates how bad the effect is if the failure reaches the customer. A corrective action that adds an inspection step or a poka-yoke does not change how bad the failure would be if it happened; it changes how likely the failure is to happen (occurrence) or how likely you are to catch it before it ships (detection). Severity is a property of the effect, not the fix. A rescore that lets someone lower severity because "we fixed it" is scoring the intervention, not the risk, and it is exactly the kind of inconsistency an IATF 16949 auditor is trained to catch, per our PFMEA guide on why severity ratings have to stay consistent across the document.
A rescore workflow enforces that distinction structurally rather than trusting the engineer to remember it: severity carries forward from the original row and cannot be resubmitted, only occurrence and detection accept new values, and the new RPN is calculated as the original severity times the new occurrence times the new detection. You cannot accidentally lower a safety-critical failure mode's risk number by touching the wrong field.
Why a fixed RPN cutoff misses the point of a rescore
Plenty of teams still use a rule like "take action on anything over 100," and our own PFMEA guide already covers why a universal RPN cutoff has no statistical grounding: a severity 10 failure mode can post a lower RPN than a severity 3 one depending on how occurrence and detection multiply out. That critique holds for building the PFMEA. It holds just as hard for deciding which rows to prioritize when a batch of corrective actions closes and someone has to pick where to spend rescoring time first.
The fix is not a fixed number, it is a number relative to the document. A rescore eligibility check can compute the 75th percentile RPN across a PFMEA's own rows rather than applying an absolute threshold pulled from a different program's risk profile. That flags the top quartile of that specific PFMEA, the rows genuinely driving the document's own risk picture, rather than every row that happens to clear an arbitrary number that means something different on a safety-critical assembly than it does on a cosmetic finish operation. A sixty-row PFMEA for a bracket and a fifteen-row PFMEA for a fastener each get their own top-quartile line, not the same one.
Where the evidence actually comes from
The other gap in a spreadsheet-based rescore is that the "what did we actually do" text lives somewhere else entirely, usually in the corrective action ticket, a SCAR, or a CAPA record that never gets linked back to the PFMEA row it was supposed to fix. A rescore workflow that is wired into the same platform running corrective action tracking can pull the closure note from a completed task directly into the rescore row as a suggested "what was done" entry, so the engineer rescoring occurrence and detection is not retyping a description that already exists somewhere else in the system. The objective evidence field, the actual proof a control works (a Cpk chart, an inspection log, a poka-yoke validation record), stays a distinct field from the narrative, because "we added a fixture" and "here is the data showing the fixture works" answer two different audit questions.
What a before-and-after number is actually for
Once a set of rows carries new occurrence and detection values, the workflow produces a before-and-after summary: total risk (the sum of RPNs across the document), average RPN, max RPN, and counts of rows still sitting at or above 100 and 200. None of these numbers are new math. What is new is that they exist as a documented before-and-after pair, computed automatically instead of hand-tallied, and they can go straight into the PFMEA's PDF, Excel, or Word export alongside the original scoring. That export is what actually answers a customer or auditor's question, not a verbal claim that "we fixed it." A corrective action effectiveness argument that says "average RPN dropped from 84 to 31 across the twelve rows we actioned, and rows above 100 went from five to one" is a different conversation than "yes, we addressed that."
This is the same effectiveness-verification problem our CAPA effectiveness verification guide covers for corrective actions generally, applied to the specific document where FMEA risk lives. A CAPA can close on paper. Whether it actually reduced the risk it was opened against is a separate question, and for a PFMEA-linked corrective action, the rescored RPN is the objective answer, not the closure date.
What this replaces on a spreadsheet
- Manually cross-referencing every closed corrective action against every PFMEA row to see which ones need an update
- Recomputing RPN by hand and hoping nobody fat-fingers the severity column in the process
- Retyping a "what did we do" narrative that already exists in the corrective action ticket
- Producing a before-and-after risk number for an audit only when someone remembers to build one in a separate spreadsheet
- Losing the rescore history the next time the PFMEA gets exported for a customer package
Getting started
If your PFMEA still shows occurrence and detection ratings from before your last three corrective actions closed, Build runs this rescore workflow directly against the PFMEA it generates: severity stays locked, the eligibility check flags the top quartile of that specific document's own risk profile, and the before-and-after summary exports with the document. A 30-day trial, no credit card required, is enough time to run one closed corrective action through a rescore and see the number move.
FAQ
Can a rescore change the severity rating? No. Severity carries forward from the original PFMEA row and is not accepted in a rescore submission. Only occurrence and detection can change, because a corrective action affects how often a failure happens or how well you catch it, not how bad the failure would be if it reached the customer.
How is the new RPN calculated after a rescore? Original severity multiplied by the new occurrence rating multiplied by the new detection rating. Severity never changes in this calculation.
Why use a percentile threshold instead of a fixed RPN cutoff like 100? A fixed cutoff treats every PFMEA the same regardless of its actual risk distribution. A 75th-percentile threshold flags the rows genuinely driving risk within that specific document, which stays consistent with the broader critique that arbitrary RPN cutoffs have no statistical basis.
Does rescoring replace corrective action effectiveness verification? No, it is the FMEA-specific instance of it. The before-and-after RPN is the objective evidence that a corrective action actually reduced the modeled risk, the same principle covered for CAPA generally, applied to the document where failure mode risk is scored.
Where does the rescore data show up in the final PFMEA document? It exports alongside the original scoring in the PFMEA's PDF, Excel, and Word outputs, so the before-and-after risk numbers travel with the document instead of living in a separate spreadsheet nobody attaches to the customer package.
