AIAG-VDA Action Priority vs AIAG-RPN: Migration Guide

TL;DR

• AIAG-VDA replaces the calculated RPN score with a lookup-table-based Action Priority (AP): High, Medium, or Low.
• AP is not computed from S x O x D — it is determined by cross-referencing severity, occurrence, and detection bands in a published table.
• OEMs are mandating AIAG-VDA migration through 2027. The most common migration error is carrying legacy RPN rows forward without recalculating the AP.
• Specwarden auto-detects both formats and flags AP lookup errors, Severity rating inconsistencies, and post-action closed-loop gaps.

---

What Changed Between AIAG-RPN and AIAG-VDA Action Priority?

The AIAG 4th Edition methodology (FMEA-4, commonly called AIAG-RPN) has been the dominant DFMEA standard in North American automotive manufacturing since 2008. It calculates a Risk Priority Number: RPN = Severity x Occurrence x Detection. Teams then use RPN thresholds — typically 100 or 125 — to decide which rows require Recommended Actions.

The AIAG-VDA 2019 Handbook (a joint publication of AIAG and the German association VDA) replaces RPN with Action Priority (AP). The change is not cosmetic. It reflects a fundamental critique of the RPN model: a row with S=10, O=1, D=1 produces RPN=10 — lower than a row with S=5, O=5, D=5 (RPN=125). Most engineers would agree that the first row (catastrophic severity, very rare, easily detected) deserves more attention than the second (moderate severity, moderate frequency, moderate detection). RPN inverts this intuition.

AP corrects this by anchoring the priority decision to Severity first. A Severity 9 or 10 row is High priority regardless of O and D. A Severity 1 row is Low priority regardless of how hard it is to detect.

The AP Lookup Table

The AIAG-VDA 2019 Handbook section 2.5.10 defines the AP lookup table. Here is a simplified version:

| Severity Band | Occurrence Band | Detection Band | Action Priority | |---|---|---|---| | 9–10 (Safety / Regulatory) | Any | Any | High | | 7–8 | O ≥ 4 | D ≥ 5 | High | | 7–8 | O ≥ 4 | D ≤ 4 | Medium | | 7–8 | O 2–3 | Any | Medium | | 7–8 | O = 1 | Any | Low | | 5–6 | O ≥ 4 | D ≥ 7 | Medium | | 5–6 | O ≥ 4 | D ≤ 6 | Low | | 5–6 | O 2–3 | Any | Low | | 5–6 | O = 1 | Any | Low | | 1–4 | Any | Any | Low |

The full table has more granularity; consult the AIAG-VDA Handbook for the precise version your OEM customer references. The key rule: Severity 9–10 is always High, regardless of Occurrence and Detection.

This is why the M-005 check in Specwarden flags rows with Severity 9 and AP=Low: the table makes AP=Low impossible when S is 9 or 10.

When You Must Migrate: OEM Mandate Timelines Through 2027

The AIAG-VDA 2019 Handbook was originally positioned as optional for Tier-2 and Tier-3 suppliers in North America. That changed around 2023. As of 2026:

• Stellantis has required AIAG-VDA format for new DFMEA submissions since 2023.
• General Motors is phasing in requirements by program year; most new program DFMEAs are expected in AIAG-VDA format by 2026.
• Ford requires AIAG-VDA for new parts entering certain design validation programs.
• European OEMs (BMW, Mercedes, Volkswagen Group, Stellantis Europe) have largely completed migration; Tier-2 suppliers serving European programs are already operating in AIAG-VDA.

The practical implication: if you are a Tier-2 or Tier-3 supplier serving one of these OEMs — or planning to — you will need to migrate your DFMEA templates and existing documentation.

Common Errors During AIAG-VDA Migration

Error 1: Carrying RPN Values Forward

The most common migration error is updating the column headers (adding "AP" column, removing "RPN" column) while leaving the underlying S, O, D ratings unchanged and computing AP as though it were RPN. Teams that do this end up with rows where AP=Low but S=9 — a straightforward audit failure that Specwarden's M-005 check catches.

Error 2: Mislabeled Severity Ratings

AIAG-RPN and AIAG-VDA use different Severity tables. The rating for the same failure outcome may differ by 1–2 points between the two standards. Teams that migrate without re-rating their Severity values using the AIAG-VDA table end up with legacy Severity ratings that produce incorrect AP lookups. This is harder to catch automatically but becomes apparent during qualitative review when AP=Low appears on rows with potentially catastrophic effects.

Error 3: Treating AP as Calculated

Some engineers, unfamiliar with the AIAG-VDA change, attempt to calculate AP from the S x O x D product and then assign H/M/L thresholds similar to their legacy RPN threshold policy. This produces plausible-looking results but is incorrect: AP is defined by table lookup, not calculation. Rows where the team calculated AP will diverge from table-lookup AP wherever Detection has high leverage (high D reduces calculated score more than table-lookup reduces AP level).

Error 4: Reusing the Old Detection Control Column

AIAG-VDA separates Prevention Controls from Detection Controls more explicitly than AIAG-RPN. Teams migrating from AIAG-RPN sometimes copy their existing Detection Control entries unchanged, even when those entries describe pre-release prototype testing — which AIAG-VDA section 2.4 treats as design verification, not a production Detection Control. This leads to overly optimistic Detection ratings.

Error 5: Ignoring the Closed-Loop Requirements

AIAG-VDA section 2.6.3 introduces mandatory closed-loop validation: when an engineering action is taken and the target date passes, the revised S, O, D ratings must be recorded in the post-action columns. This requirement did not exist in AIAG FMEA-4. Teams migrating their DFMEA template often add the AP column but omit the post-action columns (Revised S, Revised O, Revised D, Action Taken, Revised AP). When an OEM audit checks these columns and finds them blank on rows with past target dates and completed actions, it is a direct section 2.6.3 violation.

How to Verify Your Migrated DFMEA is Correct

A systematic verification of a migrated DFMEA covers four areas:

1. AP lookup verification. For every row, cross-reference S, O, D against the published AP lookup table and confirm the recorded AP matches. This is mechanical but time-consuming for large DFMEAs. Tools like Specwarden automate this check.

2. Severity re-rating. Pull up the AIAG-VDA 2019 Handbook Appendix A Severity table and compare your ratings. Pay particular attention to S=9 and S=10 rows — these are safety and regulatory rows and have strict AIAG-VDA definitions.

3. Post-action column audit. For every row with a Recommended Action and a target date in the past, confirm the Action Taken and Revised S/O/D/AP columns are populated. Blank post-action columns on past-due rows is the AIAG-VDA section 2.6.3 violation most commonly flagged in Tier-1 OEM audits.

4. Column header and format check. AIAG-VDA specifies a 16-column format. Confirm your submission template matches: Item, Function, Failure Mode, Failure Effect (Own Plant), Failure Effect (Customer Plant), Failure Effect (End User), Failure Cause, Current Prevention Control, Current Detection Control, S, O, D, AP, Recommended Action, Action Owner, Target Date.

What Specwarden Checks for Post-Action Effectiveness in AIAG-VDA

Specwarden goes beyond format verification. When your DFMEA includes post-action columns, Specwarden runs the following checks per AIAG-VDA section 2.6.3:

• D-004 (Closed-loop validation): Rows with a populated Recommended Action and a target date in the past should have Action Taken and Revised S/O/D populated. Specwarden flags rows where they are not.
• U-013 (Post-action arithmetic): For AIAG-RPN files, revised RPN = revisedS x revisedO x revisedD. For AIAG-VDA files, the revised AP should match the lookup table for the revised S, O, D values.
• U-014 (Severity immutability): Severity is design-intrinsic. If an action only adds prevention controls or improves detection, Severity should not change. Specwarden flags rows where revised Severity differs from original Severity in a DFMEA.
• D-005 (Implausible risk reduction): A large drop in Detection (4+ points) from a vague action like "Improve inspection process" is not credible. Real detection improvements require specific, verified test method additions. Specwarden flags the gap between the action description and the claimed reduction.

These are the checks that distinguish a closed-loop DFMEA from one that fills in numbers to satisfy a format requirement without substantive verification.

Tools and Templates

For DFMEA teams actively migrating, the practical toolkit includes:

The AIAG-VDA 2019 Handbook — Purchase directly from AIAG (aiag.org). The AP lookup table is in section 2.5.10. The Severity, Occurrence, and Detection rating tables are in Appendices A, B, and C.

Your OEM's DFMEA submission template — OEMs often have their own 16-column template that adds customer-specific columns or rating conventions on top of the AIAG-VDA baseline. Check your OEM's supplier portal for the current submission template before authoring new DFMEAs.

Specwarden — AI-assisted FMEA review (DFMEA + PFMEA) that auto-detects whether your file is AIAG-RPN or AIAG-VDA format and applies the corresponding verification logic. PFMEA migration to AIAG-VDA is also mandated by some OEMs — Specwarden handles both DFMEA and PFMEA reviews in either format. Start with a free review on any FMEA up to 30 rows, or see the AIAG-VDA feature page for the AIAG-VDA-specific feature set.

Visit /trust to understand how Specwarden handles your DFMEA data during the review.

FAQ

Does Specwarden support the 2019 AIAG-VDA Handbook format?

Yes. Specwarden auto-detects AIAG-VDA format from the presence of Action Priority (AP) columns and H/M/L assignments in the column headers, and applies the AIAG-VDA section 2.5.10 AP lookup verification logic. It also runs the mandatory section 2.6.3 closed-loop validation checks on post-action columns.

Can Specwarden handle a file that is mid-migration?

Yes. If your DFMEA has some rows still using legacy RPN logic and others that have been migrated to the AP column, Specwarden flags the mixed-format condition and identifies which rows use which methodology. It does not fail on mixed files — it processes what it can and surfaces the inconsistency.

What if my OEM customer still requires AIAG-RPN format?

Specwarden reviews both formats. Submit AIAG-RPN files for customers who still require it and AIAG-VDA files for customers who have mandated migration — the format detection is per-file, not per-account. The underlying engineering checks (supplier-blame detection, field completeness, action quality) apply to both formats.

What is the most common migration error in practice?

Based on what Specwarden catches in reviewed files: the most common error is populating the AP column with values that do not match the AIAG-VDA lookup table — usually because the team computed AP from S x O x D (treating it like RPN) rather than looking it up from the table. This almost always produces a wrong AP on rows where Severity is 9 or 10, since those rows should always be High regardless of O and D.

How does the AIAG-VDA three-effect structure change how I write failure effects?

In AIAG-RPN, a single Failure Effect column is used to describe the consequence of the failure mode. In AIAG-VDA, you must describe the effect at three levels: Own Plant (what fails at your manufacturing site), Customer Plant (what happens to your OEM customer's assembly), and End User (what the vehicle driver or product user experiences). This separation makes the Severity rating more defensible and forces teams to think through the effect cascade rather than stopping at the immediate manufacturing consequence.

---

Specwarden is an AI DFMEA review tool built for Tier-2 and Tier-3 manufacturing suppliers navigating AIAG-VDA migration. Try a free review or read how we built the reviewer.