Tier-2 Supplier-Blame in a DFMEA: Why Auditors Hate It

TL;DR

• A DFMEA Failure Cause must describe a gap in the design specification — not what a supplier did wrong during manufacturing.
• "Supplier delivered out-of-spec parts" is the classic Tier-2 supplier-blame pattern. It is an audit failure in every AIAG-VDA review.
• The fix is to ask: what is the design drawing missing that permitted this? That missing specification is the real cause.
• Specwarden caught this pattern spontaneously on 3 out of 10 hand-authored DFMEA test fixtures — rows where we had not specifically planted the error.

---

What is Tier-2 Supplier-Blame in a DFMEA?

A DFMEA (Design Failure Mode and Effects Analysis) exists to analyze what can go wrong with a design. Every Failure Cause in a DFMEA should point to something the design team can act on: a missing tolerance, an underspecified material property, a geometry that creates stress concentration, an interface that was not validated against a failure scenario.

"Tier-2 supplier-blame" is what happens when a DFMEA cause shifts responsibility upward in the supply chain instead. The cause reads as though the design is fine — it is just that the supplier is not following through.

Classic examples:

| Failure Mode | Tier-2 Supplier-Blame Cause (Audit Fail) | Correct Design-Side Cause | |---|---|---| | Hydraulic rod seal failure | "Supplier delivers seals with incorrect Shore A hardness" | "Engineering drawing does not specify minimum Shore A hardness or incoming acceptance criterion for seal material" | | Casting surface porosity | "Foundry has insufficient process control on shell preheat" | "Engineering drawing lacks a maximum allowable subsurface porosity severity level per ASTM E446" | | PCB trace delamination | "PCB fabricator uses substandard copper plating" | "Fabrication spec does not define minimum finished copper plating thickness; no incoming dimensional acceptance criterion specified" |

The DFMEA cause column is the design team's self-assessment. A cause that blames the supplier says: our design is correct, but our supplier is failing us. That is a PFMEA (Process FMEA) or supplier qualification problem — not a design problem.

Why This Pattern Fails an Audit

AIAG-VDA Handbook section 1.4.1 is explicit: the DFMEA assumes the product is manufactured to the design intent. If the design intent is insufficient to prevent a failure mode, the DFMEA must say so. If the design intent is sufficient and the supplier is not meeting it, that is outside DFMEA scope.

An auditor reviewing a DFMEA with supplier-blame causes asks one question: What did your design team do to prevent this failure mode? If the only answer is "we expect our supplier not to mess up," the DFMEA provides no audit evidence that the design is safe.

In practice, supplier-blame causes create two follow-on problems:

1. The Recommended Action becomes supplier-facing, not design-facing. "Source from certified supplier" or "add incoming quality inspection" are procurement actions. They do not change the design. An auditor will note that the design has not been improved.

2. The Prevention Control becomes empty or circular. If the cause is "supplier delivers bad parts," the Prevention Control often reads "supplier qualification" — which is not a design control. The detection chain breaks down entirely.

The Reframe: From Supplier Action to Design Specification

The correct reframe follows a consistent pattern: identify the design specification gap that permits the supplier failure mode to occur.

Ask: If the supplier did deliver the non-conforming part, what is missing from our engineering drawing or procurement specification that would have caught it?

This question points directly to the real DFMEA cause. The supplier failure mode is a trigger, not a cause. The underlying cause is that the design specification does not constrain the failure mode.

Reframe workflow:

1. Read the supplier-blame cause.
2. Ask: What is the design drawing missing that would prevent or detect this?
3. Write that missing specification as the cause.
4. Redirect the Recommended Action: it should now be "update engineering drawing to add [specification]" or "add incoming acceptance criterion to procurement spec."
5. Adjust the Prevention Control to reflect the new design constraint.

Once reframed, the Recommended Action becomes a genuine design improvement — something that changes what gets drawn, toleranced, or specified. The DFMEA now documents actual design work.

Three Real Catches from Specwarden Test Data

During internal validation of Specwarden, we ran 10 hand-authored DFMEA test fixtures through our AI reviewer. Three of those fixtures contained supplier-blame causes — and we had not specifically planted them as "test cases" for this pattern. Specwarden caught all three.

Example 1 — Impeller casting fixture: The Failure Cause read: "Foundry investment casting shell preheat oven temperature drift and ceramic slurry viscosity deviation causes internal passage surface roughness to exceed Ra limit."

This blames the foundry's process. Specwarden flagged it as D-001b (Tier-2 supplier-blame) and recommended reframing: the real cause is that the engineering drawing did not specify a maximum allowable internal passage surface roughness (Ra), leaving the foundry without a contractual quality gate. The existing Recommended Action — "mandate Ra less than or equal to 6.3 microns on drawing" — was actually the correct design response to the reframed cause.

Example 2 — Fastener DFMEA: The Recommended Action read: "Source from NADCAP-certified supplier." The cause had already been written as a design-specification deficiency, but the action reverted to a procurement solution. Specwarden flagged this as Tier-2 contamination in the action column, noting that a NADCAP certification requirement belongs in the procurement specification — not as a DFMEA Recommended Action with no design change attached.

Example 3 — Turbo housing fixture: The Failure Cause: "Casting supplier delivers porous parts." This is the most direct version of the pattern. Specwarden recommended: "Engineering drawing casting notes do not specify a maximum allowable subsurface porosity severity level; absence of an explicit ASTM E446 Level 2 (or better) radiographic acceptance criterion permits delivery of structurally marginal castings without drawing nonconformance."

In all three cases, a senior manufacturing quality engineer reviewed the catches and rated them 100% correct. These were not obvious errors; two required understanding the semantic distinction between a design-specification gap and a supplier execution failure.

How Specwarden Catches Tier-2 Supplier-Blame

Generic AI tools catch placeholder text ("TBD", "N/A") and obvious formatting errors. They do not understand the semantic distinction between a cause that points to a design specification gap (correct DFMEA scope) and a cause that describes a supplier manufacturing process failure (incorrect DFMEA scope).

Specwarden's reviewer is grounded in AIAG-VDA Handbook sections 1.4.1 and 2.4. It knows that a DFMEA cause must be something the design engineer can act on — a gap in what was drawn, toleranced, or specified. When a cause instead describes what a supplier, fabricator, or process step failed to do, Specwarden flags it.

This detection logic requires genuine understanding of AIAG methodology, not just pattern matching on text. It is why Specwarden caught supplier-blame on rows that were not specifically engineered to test it.

See our supplier-blame landing page for more on how this works in practice, or visit /trust to understand how Specwarden handles your DFMEA data.

What Specwarden Checks for Post-Action Effectiveness

Beyond catching supplier-blame in the pre-action columns, Specwarden now also verifies the post-action section of your DFMEA — the "Action Results" columns required by AIAG-VDA section 2.6.3.

When an engineering action is documented and the target date has passed, Specwarden checks:

• Are the revised S, O, D ratings populated? (U-001 closed-loop check)
• Is the revised RPN arithmetic correct? (U-013 check: revisedS x revisedO x revisedD = revisedRPN)
• Has Severity been silently reduced? (U-014: Severity is design-intrinsic — if your action only added prevention controls, Severity should not change)
• Does a large detection or occurrence drop (4+ points) match a specific, physical action? (D-005: "Improve testing" does not justify D dropping from 8 to 1)

Most AI review tools stop at pre-action review. Specwarden goes through the full DFMEA audit cycle.

When Supplier-Blame IS Appropriate: PFMEA, Not DFMEA

To be clear: supplier execution failures are legitimate failure causes. They belong in different documents.

In a PFMEA (Process FMEA), the analysis covers what can go wrong during manufacturing. A cause like "heat treatment furnace operates outside specified temperature window" is correct PFMEA scope — it describes a process step failure that the manufacturing engineer can act on by improving process controls.

If you are doing a PFMEA for a heat treatment operation, causes about furnace temperature are exactly right. If you are doing a DFMEA for a part that goes through heat treatment, the relevant causes are about whether the design drawing specifies a sufficient heat treatment requirement — not whether the furnace operator follows it.

The rule of thumb: DFMEA causes are things a design engineer fixes by changing a drawing or specification. PFMEA causes are things a process engineer fixes by changing a process step or control.

FAQ

What is Tier-2 supplier-blame in a DFMEA?

A Tier-2 supplier-blame cause in a DFMEA is a Failure Cause that blames the upstream component supplier for delivering non-conforming parts, rather than identifying a gap in the design specification that permitted or failed to detect the non-conformance. AIAG-VDA Handbook section 1.4.1 requires DFMEA causes to describe design-specification deficiencies — not supplier execution failures.

Why do auditors flag supplier-blame causes?

Because a DFMEA cause that blames the supplier provides no evidence that the design team has identified and addressed a design-side risk. The corrective action becomes a procurement action ("source from better supplier") rather than a design change ("add minimum hardness specification to engineering drawing"), and the DFMEA fails to demonstrate design integrity.

How do you reframe a supplier-blame cause?

Ask: what is the engineering drawing or procurement specification missing that would prevent or detect this supplier non-conformance? That missing specification is the real DFMEA cause. Reframe to describe the specification gap, and redirect the Recommended Action to adding that specification to the drawing.

Can Specwarden detect this automatically?

Yes. In Specwarden internal evaluation, our AI reviewer caught Tier-2 supplier-blame on 3 out of 10 DFMEA test fixtures — on rows where we had not specifically planted the pattern. See Specwarden supplier-blame page or try a free review.

What is the difference between D-001a and D-001b in Specwarden?

D-001a flags Tier-1 PFMEA contamination: rows where the Failure Mode or Cause describes an operator action, assembly process step, or manufacturing process variable that belongs in a PFMEA, not a DFMEA. D-001b flags Tier-2 supplier-blame: rows where the Cause blames the upstream supplier for delivering non-conforming parts instead of identifying the design-specification gap. Both are audit failures under AIAG-VDA section 1.4.1, but they require different reframes.

---

This pattern appears in both DFMEA and PFMEA reviews — Specwarden catches both. In PFMEA, the analogous moat is D-101 (process-to-product contamination): when a PFMEA cause blames a product design tolerance instead of a process parameter, that is scope contamination that belongs in the DFMEA. Specwarden detects the PFMEA variant automatically. See the PFMEA review page for the full PFMEA check inventory.

Specwarden is an AI FMEA review tool for Tier-2 and Tier-3 manufacturing suppliers. It reviews DFMEA and PFMEA. Try it free on any FMEA up to 30 rows. See how Specwarden handles your data.