Specwarden lockupspecwarden

For PFMEA owners

Catch Tier-2 process-to-product contamination — automatically

When a PFMEA cause reads "design tolerance too tight for our process," that's blaming product design from the process FMEA. Specwarden's D-101 check catches this pattern, plus D-103 control misclassification and 5 other PFMEA-specific audit failure modes.

How it works

Upload your PFMEA

Drop in your spreadsheet. Specwarden auto-detects PFMEA format from column headers — Process Step, Process Function, Current Process Controls.

D-101 + D-103 run on every row

Deterministic keyword checks catch process-to-product causes and detection-masquerading-as-prevention in under a second. Sonnet then reads every row for deeper contamination patterns.

Findings with specific reframes

Each D-101 finding includes the exact cause text that triggered it and a concrete reframe: replace the design-blame language with a process-side root cause your process team can act on.

Why Specwarden catches what reviewers miss

D-101

the deepest PFMEA moat

Process-to-product contamination is the PFMEA equivalent of DFMEA's supplier-blame pattern. Both are scope violations. Both are audit red flags. Both require a reviewer who understands the DFMEA/PFMEA boundary.

D-103

control method classification catches

In-process detection masquerading as prevention inflates PFMEA quality metrics. Specwarden checks every Prevention Control cell for detection-language keywords that signal misclassification.

Free

on your first 30-row PFMEA

See D-101 and D-103 catches on your own data. Free tier gives you 5 visible findings — if Specwarden catches process-to-product contamination, you'll see it without paying.

Three moat checks that matter

D-101: process-to-product contamination detection

Rule-based keyword detection catches causes that name design tolerances, drawing specs, or engineering ECNs — all scope violations in a PFMEA. Fires on every review, even when AI is unavailable.

D-103: control method classification

100% inspection, pressure test, auto-reject — these are Detection controls. When they appear in the Prevention column, Specwarden flags the misclassification and explains why it inflates your apparent prevention robustness.

D-005: closed-loop validation on implausible reductions

Detection dropping 8 to 1 from "team huddle and reminder posters"? Specwarden flags implausible post-action rating drops that can't be physically justified by the documented action.

Built for engineering teams reviewing high-stakes technical documents.

Workflow proof

Reviews engineering documents against risk and compliance criteria

Use-case proof

Designed for FMEA, specs, quality checks, and design review workflows

Beta proof

Private beta feedback from technical reviewers and operators

What a D-101 contamination looks like — and how Specwarden reframes it

Contaminated PFMEA cause (D-101 fires)

“Inadequate design tolerance on shaft OD spec (drawing requires ±0.05mm, but design margin is too tight for our standard honing process capability)”

Specwarden reframes as

Correct process-side cause

“Honing wheel wear exceeds 500-cycle replacement interval; bore diameter drifts outside 25mm ±0.02mm tolerance”

Recommended action: “Add Cpk monitoring on bore diameter; reduce honing wheel change interval from 500 to 350 cycles”

The design-tolerance question — whether ±0.05mm is achievable — belongs in the DFMEA. The PFMEA should document what can go wrong in the process and what process controls prevent or detect it.

D-101 contamination — common questions

What's the difference between supplier-blame (DFMEA D-001b) and process-to-product contamination (PFMEA D-101)?
Both are scope violations. D-001b (DFMEA) fires when a DFMEA cause blames the supplier for delivering bad parts instead of naming the design-specification gap. D-101 (PFMEA) fires when a PFMEA cause blames a product design tolerance instead of a process parameter. The underlying issue is the same: the cause is reaching across the DFMEA/PFMEA boundary.
Does Specwarden catch this on AIAG-VDA AND AIAG-RPN PFMEA files?
Yes. D-101 and D-103 are rule-based checks that run on every PFMEA regardless of format. The PFMEA prompt also instructs the AI reviewer to catch D-001b PFMEA variant (process-side action recommending a design change), which requires semantic understanding beyond keyword matching.
How does this compare to a senior PFMEA reviewer's catch rate?
Senior reviewers reliably catch process-to-product contamination when they know to look for it — the problem is they often have 200+ rows and catch it inconsistently. Specwarden's D-101 runs on every row in every review. It catches every explicit cause that names a design tolerance or drawing spec, including rows that a fatigued reviewer might skip.
Will Specwarden flag legitimate process-side causes by mistake?
The D-101 rule fires specifically on causes that mention product design terms (design tolerance, drawing requires, engineering ECN, spec too tight). Process-side causes like "honing wheel wear exceeds 500-cycle limit" or "coolant flow drops below setpoint" do not match these patterns and will not trigger D-101.

See D-101 catches on your PFMEA.

Free. 30 rows. No card. Takes 60 seconds.

Join waitlist