AIAG & VDA FMEA structures technical risk analysis—not product release
The official handbook record covers Design FMEA, Process FMEA, and Supplemental FMEA for Monitoring and System Response. A completed analysis or action-priority field is evidence for risk work—not an authorized product disposition.
Editorial figure by Quality Systems Index. Source context: AIAG — AIAG & VDA FMEA Handbook.
Three analyses answer different operating questions
The direct scope on AIAG's official record separates Design FMEA, Process FMEA, and Supplemental FMEA for Monitoring and System Response. Design analysis examines potential failures in the product design. Process analysis examines the manufacturing or assembly process. FMEA-MSR addresses monitoring and system response during operation. A quality system should connect those analyses without copying one conclusion indiscriminately across all three.
Each record needs the exact analyzed item, boundary, structure, function, requirement, failure chain, effect, cause, prevention or detection control, rating basis, action priority, action, owner, due date, evidence, residual assessment, version, and approval. The relationships matter more than a colored summary field because a later design or process change can invalidate part of the chain.
Action Priority routes work—it does not accept a product
AIAG's public materials describe Action Priority within the harmonized method. That prioritization can help teams decide where further prevention, detection, or risk-reduction work warrants attention. It is not a universal pass threshold, and a lower priority does not establish that every product, process, control, specification, customer requirement, or regulatory condition is satisfied.
Buyers should test whether a platform retains the rating criteria and rationale, handles disagreements, assigns and verifies actions, prevents unauthorized closure, and reassesses affected records after a change. A dashboard should not turn a calculated or selected priority into an automatic waiver, production approval, deviation, or shipment release.
FMEA evidence must connect to adjacent quality records
Technical risk analysis informs but does not replace design reviews, drawings, specifications, special characteristics, control plans, work instructions, measurement studies, validation, capability evidence, first-article or production approvals, deviations, inspection, nonconformance, corrective action, and change control. Systems should preserve traceability while keeping each record's purpose and decision authority explicit.
A representative demonstration should change one function or characteristic and show which DFMEA, PFMEA, monitoring analysis, control-plan step, instruction, measurement, validation, supplier, and approval records require review. It should retain the previous version and evidence rather than overwriting the historical basis for produced or released material.
Edition, customer, and scheme context still govern
The linked record identifies the AIAG & VDA FMEA Handbook and available formats. Organizations should verify the current edition, errata, licensed content, customer-specific requirements, IATF or other scheme expectations, internal procedures, and contractual obligations before applying the method. Public summary text does not reproduce or replace the licensed handbook.
This source establishes the handbook's documented purpose and high-level method scope. It does not audit an FMEA, approve ratings, certify software, release a product, or determine conformity. Quality, engineering, manufacturing, supplier, customer, safety, regulatory, and legal owners retain those decisions. Technology should keep technical-risk evidence useful without presenting method completion as product acceptance.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Quality Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.