DEV Community: 8D Gate

What a customer quality engineer checks in your 8D in the first five minutes

8D Gate — Tue, 06 Oct 2026 06:03:11 +0000

Your 8D lands in a customer quality engineer's inbox along with a dozen others. They won't read it like a novel, from D1 to D8. Most reviewers jump straight to the sections that tell them whether the supplier really understands the problem, and they form a first impression within minutes.

This post walks through that reading order from the reviewer's side, so you can check your own report the same way before you send it. It's a different angle from my earlier post on the 8 reasons customers reject supplier 8D reports: that one was a checklist by discipline; this one is about what gets looked at first and why. If you'd like an automated skeptical first read, there's a free pre-send readiness check, 8D Gate. More on it at the end.

Minute 1: Does D2 match the complaint?

The reviewer has their own complaint record open next to your report. The first check is simple: is this the same problem?

They compare part number, defect description, quantity, dates, and where it was found. If your D2 says "dimensional issue" and their complaint says "burr on bore edge, 37 pcs found at incoming inspection," they already suspect the rest of the report is generic. A sharp D2 with the customer's own numbers in it signals that you've read the complaint carefully.

Your check: Could the reviewer match your D2 to their complaint line by line, without guessing?

Minute 2: Are there real numbers in D3?

Next, containment. The reviewer wants to know whether any more bad parts are on their way, so they look for three things: quantities, locations, and a break point.

Here's an illustrative example (made up for this post, not from a real report):

Weak D3 (illustrative): "All stock was sorted and no further defects were found. Containment is effective."

Improved D3 (illustrative): "Sorted 100% by visual inspection under 10x magnification: supplier warehouse 2,400 pcs checked, 6 rejected; in transit 800 pcs checked, 0 rejected; customer site 1,150 pcs checked by our sort team, 3 rejected. First lot known good: lot 24-118, produced after tool change on [date]. All shipments from lot 24-118 onward are marked with a green dot."

The weak version asks the reviewer to take your word for it. The improved version gives them numbers they can check against their own stock, and tells them exactly which parts are safe.

Your check: Does D3 give checked and rejected counts at every location, the inspection method, and a clear break point the customer can use?

Minute 3: Does D4 explain both occurrence and escape, with evidence?

This is where most reviewers slow down. They look for two root causes, not one: why the defect was made (occurrence), and why your controls didn't catch it before it shipped (escape). And they look for evidence in the report, not just a statement.

Weak D4 (illustrative): "Root cause: operator did not follow the work instruction. Operator has been retrained."

Improved D4 (illustrative): "Occurrence: deburring tool insert worn beyond limit; tool life was not defined in the setup sheet, so inserts were changed only when an operator noticed. Confirmed by reproducing the burr with a worn insert and eliminating it with a new one (photos and measurements, attachment 3). Escape: final inspection checks the bore diameter with a plug gauge, which does not detect an edge burr; the control plan had no visual or tactile check for burrs. Confirmed by passing 5 known burred parts through final inspection, all accepted (attachment 4)."

"Operator error" tells the reviewer the analysis stopped early. The improved version says why the process allowed it, covers both causes, and shows how each was confirmed. More on both in How to write the D4 root cause in an 8D and Escape point in 8D.

Your check: Is there a separate occurrence and escape cause, each confirmed by data in the report?

Minute 4: Is there verification data in D5 and D6?

Reviewers scan D5 for whether each action actually addresses a D4 cause, then go straight to D6 looking for results. Not "actions implemented and effective," but data: how many parts were produced after the change, what was measured, what the result was, over what period.

If D6 is a single sentence, the reviewer usually stops there and writes back asking for evidence. If D6 still needs time to collect data, say what you'll measure and when, rather than claiming effectiveness early.

Your check: For every action, can the reviewer see what changed (D5) and the numbers showing it worked (D6)?

Minute 5: Did anything change in the system (D7), and does it all add up?

Finally, two quick checks that decide whether the reviewer reads the report as complete or not.

D7: Which documents were updated, with revision numbers? The control plan, PFMEA, setup sheet, work instruction? Were similar parts, tools, or lines checked? A D7 that names specific documents and other places the fix was applied tells the reviewer this won't come back next month on a sister part.

Consistency: Reviewers notice when the numbers don't agree. Quantities in D2 that differ from D3, dates where the action closes before the root cause was confirmed, a D4 cause with no matching D5 action, or an 8D marked closed while D6 says "monitoring ongoing." Each contradiction makes them doubt the rest.

Your check: Read the report top to bottom once looking only for numbers, dates and statuses. Do they all agree?

Reading your own 8D like a reviewer

The simplest habit: before you send, open the customer's complaint next to your 8D and follow the same five-minute path. D2 against the complaint, D3 numbers, D4 occurrence and escape with evidence, D5/D6 data, D7 and consistency. Anything you have to explain verbally is something the reviewer won't see.

If you'd like a second, skeptical reader, 8D Gate is a free pre-send readiness check. Upload an English 8D (PDF, DOCX or Excel) and in typically under a minute you get an Accept / Conditional / Reject advisory, a score, ratings per discipline, missing evidence, and the questions a reviewer is likely to ask. You review it on screen and can download a PDF.

Run the free 8D readiness check

8D Gate is a free pre-send readiness advisory. It doesn't replace the customer's decision. We don't store your 8D body in our database; you can delete anytime. Anthropic processes the text for the review.

How to answer an audit finding with an 8D: a corrective action response that holds up

8D Gate — Tue, 06 Oct 2026 06:02:52 +0000

An audit nonconformity lands in your inbox: a customer process audit, an IATF 16949 surveillance audit, an ISO 9001 recertification, or a certification body visit for a food-contact line. You have a deadline, a corrective action form, and an auditor who will read your answer with one question in mind: does this show the system is fixed, or just the one thing I happened to find?

Many quality teams answer audit findings with an 8D, and it fits well. The disciplines force you to separate containment from root cause from verification, which is exactly where most audit responses go wrong. Below is how to structure the response so it has a good chance of being accepted the first time. If you'd like a skeptical second reader on the draft before you send it, there's a free pre-send readiness check, 8D Gate. More on it at the end.

1. Restate the finding objectively (D2)

Start by restating the nonconformity in your own words, without softening it and without arguing with it. Name the requirement (the customer requirement, your own procedure, or the standard, quoted exactly as the auditor wrote it), what was observed, where, and on what evidence.

Weak: "Auditor noted some issues with calibration records."

Better: "During the audit on [date], 3 of 12 torque wrenches sampled on Line 2 had no calibration record for the current period, contrary to procedure QP-07 rev. C."

If you can't restate the finding precisely, you aren't ready to find its root cause. If you genuinely disagree with the finding, raise that with the auditor through the proper channel before you submit, not inside the corrective action.

2. Check the extent of condition (D2/D3)

Auditors sample. They saw three wrenches on one line. Your response has to answer the question they will ask next: where else is this true?

Check the same requirement across every line, shift, site, and process that falls under it, and report what you found with numbers: how many items checked, how many affected, where. "We checked all 148 torque tools across both plants; 9 had lapsed records, all on Lines 2 and 4" is far stronger than "the issue was isolated." If the problem turns out to be wider than the sample, say so. Finding it yourself is much better than the auditor finding it at the next visit.

3. Separate correction from corrective action (D3 vs D5)

This is the most common gap in audit responses. They are different things, and the response should show both:

Correction fixes the specific instance: calibrate the three wrenches, quarantine and re-check anything they were used on since the record lapsed.
Corrective action removes the cause so it doesn't happen again anywhere.

A response that only lists the correction ("wrenches were calibrated on [date]") tells the auditor the symptom is gone but the system that produced it is unchanged.

4. Find the system root cause (D4)

For an audit finding, the root cause is almost never "the operator forgot" or "oversight." The useful question is: why did the management system allow this to happen and not notice?

Work it from two sides, the same way an 8D separates occurrence from escape:

Why did it occur? For example, the calibration schedule lived in a spreadsheet owned by one person, with no reminder or backup when that person was away.
Why wasn't it detected internally? For example, the internal audit plan didn't sample calibration status on the shop floor, only the master list.

Each cause needs evidence in the response itself: the spreadsheet history, the internal audit checklist, interview notes. If you've already written D4s for customer complaints, the same discipline applies; there's more detail in How to write the D4 root cause in an 8D and Escape point in 8D.

5. Make corrective actions system-level (D5/D7)

Each root cause should have an action that changes the system, not just people's attention. Moving calibration due dates into the maintenance system with automatic alerts and a named backup owner is a system change. "Retrained the responsible person" on its own is not, and auditors read it as a sign the root cause stopped too early.

Then extend it (D7). Which other procedures, sites, or records rely on the same weak mechanism? Name the documents you updated, with their new revision, and the other areas you applied the fix to.

6. Attach objective evidence

Assume the auditor will accept only what they can see. For every claim in the response, attach or reference the evidence: updated procedure with revision and date, training records, screenshots of the new system alert, the completed extent-of-condition check, re-check results for affected product. "Procedure updated" without the procedure is an assertion, not evidence.

7. Plan effectiveness verification with realistic timing (D6)

You usually have to submit the response before you can prove the fix works over time. That's normal. What matters is that you say how and when effectiveness will be verified: for example, an internal audit of calibration status on all lines after the next two monthly cycles, with the expected result stated. Then do it, and keep the record, because the next audit will likely look for it.

Don't declare the action "effective" on the day you implemented it. Implemented and effective are different claims.

Common reasons audit responses get sent back

The finding is restated vaguely, or argued with inside the response.
No extent-of-condition check beyond the auditor's sample.
Correction only, no corrective action.
Root cause is a person ("human error," "oversight") rather than the system that allowed it.
No root cause for why internal checks didn't catch it.
Actions are retraining or reminders only.
Claims without attached evidence.
Effectiveness declared immediately, with no verification plan or data.

Many of these overlap with why customers reject supplier 8Ds generally; I covered those in The 8 reasons customers reject supplier 8D reports.

Pre-check before you send

Before submitting, read the response once as the auditor would, top to bottom, asking "where's the evidence for that?" at every sentence.

If you'd like a second pass, 8D Gate is a free pre-send readiness check for 8D reports. Upload an English 8D (PDF, DOCX or Excel) and in typically under a minute you get an Accept / Conditional / Reject advisory, a score, ratings per discipline, missing evidence, and the questions a reviewer is likely to ask. It's built for customer 8Ds, but the same gaps show up in audit responses written in 8D format. It doesn't replace the auditor's or certification body's decision on your response.

Run the free 8D readiness check

The 8 reasons customers reject supplier 8D reports, and how to check yours before you send it

8D Gate — Mon, 05 Oct 2026 18:41:48 +0000

If you write 8Ds for automotive or industrial customers, you know the email: "Thank you for your report. Please revise and resubmit." Each revision loop costs days and keeps the complaint open.

Most rejected 8Ds don't fail because the engineering is hard. They fail because the report doesn't show the work. A customer quality engineer reading your 8D has only the document in front of them. If the evidence isn't in the text, as far as they can tell it doesn't exist.

Below are the eight gaps that most often send an 8D back, roughly in D1–D8 order. Use them as a checklist before you send. If you'd like a second, skeptical reader on your draft, there's a free tool for that, 8D Gate. More on it at the end.

1. The problem statement is vague (D2)

"Customer complaint, quality issue on part X" is not a problem statement. Your reviewer wants the basics: what, where, when, how many, and how it was detected. Give the part and lot, the shipment or date window, the quantity affected, the detection point, and the requirement that wasn't met, with the spec value.

A common mistake is putting the suspected cause into D2. D2 should describe the deviation, not explain it.

Check: Could someone who has never seen the part restate the problem, with numbers, from D2 alone?

2. Containment has no numbers or no boundary (D3)

"Stock blocked and sorted" doesn't tell the customer much. They want to know which stock, at which locations (your finished goods, WIP, in transit, at the customer, at other sites), how many pieces were checked, by what method, and how many were found nonconforming. They also want a break point: the last known good shipment and the first shipment verified good after containment.

An unfinished sort is fine if you say so. A containment section that sounds finished but has no quantities is not.

Check: Does D3 give counts for checked and rejected parts at every location, the inspection method, and a clear break point?

3. The root cause stops at the symptom or at a person (D4)

"Operator error," "operator carelessness," and "lack of attention" are the most common reasons an 8D gets rejected. Customers read them as "we haven't found the cause yet." People make mistakes when the process allows those mistakes and doesn't detect them. The real root cause usually sits in that gap: setup without a verified standard, a missing poka-yoke, tool wear with no monitoring, or an unclear work instruction.

The other version of this failure is a root cause with no evidence behind it. "Team discussion concluded…" or "see attached fishbone" is not proof. Show the analysis method (5-Why, Ishikawa, is/is-not), the data that confirms the cause, and ideally that you can switch the defect on and off.

Check: Does D4 explain why the process allowed the defect, and is there data in the report itself that confirms it?

More detail: How to write the D4 root cause in an 8D.

4. There is no escape point analysis (D4)

When the customer found the defect, there are two questions: why it was made, and why it wasn't caught. Many 8Ds answer only the first. Others answer the second with "final inspection didn't notice," which is the person-blame problem again in a different discipline.

Name the control point that should have detected the defect. Then explain why it couldn't: the characteristic wasn't on the control plan, the gauge couldn't discriminate, the sampling frequency was too low, or the inspection depended on someone's visual check.

Check: Does the 8D have separate occurrence and non-detection (escape) root causes, each with its own evidence?

More detail: Escape point in 8D: what it is and how to write it.

5. Corrective actions treat the symptom (D5)

"Retrain operators," "remind inspectors," "100% inspection," and "quality alert on the line board" are reasonable interim actions. They are not permanent corrective actions. They don't change the conditions that produced the defect.

A permanent corrective action should map directly to a root cause you've proven. If D4 names two root causes (occurrence and escape), D5 needs actions for both, each with an owner and a date.

Check: For every root cause in D4, is there an action in D5 that changes the process, tooling, method, or detection, beyond people's attention?

6. "Effective" is claimed with no verification data (D6)

"No further complaints since the training, so the actions are effective" is one of the weakest sentences you can put in an 8D. A quiet few weeks may only reflect low volume.

Verification means evidence: before-and-after measurements, capability data after the change, a trial run with results, or a validated error-proofing check. If the data isn't available yet, say so and give the date when it will be.

Check: Does D6 include actual results (numbers, charts, or test outcomes) in the report, not just a statement that the actions worked?

7. Nothing systemic changes (D7)

Customers look at D7 to see whether the organization learned anything or only fixed one part. "Add 'be careful' to the work instruction" and "share in the monthly meeting" don't count. Reviewers expect to see the system documents updated: PFMEA (occurrence and detection reconsidered), control plan, work instructions, and lessons learned. They also expect a read-across to similar parts, processes, or lines, with a list rather than "will be reviewed."

Check: Does D7 name the specific documents updated (with revision status) and the similar products or processes the fix was extended to?

8. The report contradicts itself or closes too early (D8 and overall)

Reviewers notice inconsistencies: a quantity in D2 that differs from D3, a corrective action marked "done" before its root cause was confirmed, a D8 that proposes closure while the same section lists the sort, the work instruction, and the read-across as still open. There's also the attachment problem. Anything you write as "see attachment" or "available on request" is evidence the reader can't see if it isn't in the document.

Check: Read the 8D from start to finish as a skeptic. Do the numbers, dates, and statuses agree, and is the key evidence actually in the document?

How to pre-check before you send

The best pre-check is a colleague who reads like a demanding customer. That person isn't always free when the deadline is tomorrow, so we built 8D Gate as a free pre-send readiness check for exactly this moment.

You paste your English 8D (D1–D8) or upload it as PDF, DOCX, or Excel. You get back an advisory decision:

Accept: looks complete enough to send
Conditional: usable once the named gaps are closed
Reject: not ready; fix these before you send

With the decision you also get a score, ratings for each section, the missing evidence, and questions to close the gaps. The review follows a public rubric covering problem definition, containment, root cause, evidence quality, corrective action, verification, prevention, and consistency. It has hard gates for issues like an unsupported root cause or symptom-only corrective actions. Polished wording doesn't raise the score. When the 8D doesn't contain the evidence, the review says so instead of filling the gap. You can review the result on screen and download it as a PDF. A review usually takes under a minute.

Be clear about what it is. It's an advisory pre-send readiness check for your team. It doesn't replace your customer's decision, and an Accept from 8D Gate is not a customer Accept. Follow your own company's and your customer's rules on sharing documents. If a report contains sensitive customer details, consider redacting them before you paste it.

Run the free 8D readiness check

The tool is in an early version (V0.1, English only). If you try it, I'd like to hear what was useful, what was too lenient, and what it missed.

I built an AI 8D reviewer that isn't allowed to invent evidence (try it with a sample report)

8D Gate — Mon, 05 Oct 2026 18:03:21 +0000

If you work in automotive or industrial manufacturing, you know the 8D report: when a supplier ships a defect, the customer demands eight disciplines of problem solving (team, problem, containment, root cause, corrective action, verification, prevention, closure). If you don't, here's the short version: it's the document that decides whether a supplier gets trusted again.

Most 8Ds don't fail on the hard engineering. They fail on completeness: root cause = "operator carelessness", corrective action = "retrain + 100% inspection", effectiveness = "verified" with no data. The customer bounces it, and the loop costs days.

So we built 8D Gate: a free, skeptical pre-send check. Paste the text or upload PDF / DOCX / Excel, and get an advisory ACCEPT / ACCEPT WITH CONDITIONS / REJECT with a score per section and a fix list.

👉 Try it: https://8d-gate.vercel.app/?utm_source=devto&utm_medium=community&utm_campaign=feedback24h

Design rules that mattered more than the prompt

1. A fixed, weighted rubric. Root cause 25%, evidence quality 20%, corrective action 15%, problem definition / containment / verification 10% each, prevention and consistency 5% each. Nicer wording can't raise the score.

2. Hard caps the model can't argue past.

Unsupported root cause → capped at 49 → REJECT
Corrective action that only treats the symptom (sorting, training, extra inspection) → REJECT
Major internal contradiction → REJECT
"Effective" with no verification data → ACCEPT WITH CONDITIONS at best
Customer-detected defect with no escape analysis (or "person-blame" as the escape) → ACCEPT WITH CONDITIONS at best

3. Evidence labels. Each finding is FACT, CLAIM, ASSUMPTION, MISSING or INCONSISTENCY. A filename, "see attachment" or "available on request" is never a FACT, because the text isn't there. When something can't be judged, the output says "Insufficient evidence to conclude." We'd take that over a confident wrong answer.

4. Golden tests. A set of synthetic 8Ds with known expected decisions (REJECT for unsupported root cause, symptom-only CA and contradictions; CONDITIONAL for weak D6 and a missing escape analysis; ACCEPT for solid ones). A run only passes if the decision matches exactly.

Stack: Next.js on Vercel, Anthropic for the review, pdf-parse / mammoth / xlsx for extraction, pdfkit for the downloadable report. No signup. The 8D body isn't stored in our database (it's sent to Anthropic for processing). English only, V0.1, advisory only.

Try it in 60 seconds with a synthetic 8D

No 8D of your own? Copy the fictional report below (company names are made up), paste it into https://8d-gate.vercel.app/review?utm_source=devto-sample&utm_medium=community&utm_campaign=feedback24h and see what it does with "operator carelessness" as a root cause. Our expected result is a REJECT for an unsupported root cause; tell me if it says otherwise.

Synthetic 8D: brake hose clip escape (click to expand, then copy)

# 8D Report — Brake Hose Clip Dimensional Escape

| Field | Value |
|-------|-------|
| 8D No. | ACME-8D-2026-0142 |
| Customer | Acme Auto — Plant Bratislava |
| Supplier | TierCo Fasteners s.r.o. |
| Part No. | TC-BH-4412 / Clip, brake hose retainer |
| Complaint No. | AA-Q-88921 |
| Date opened | 2026-03-12 |
| Date of this revision | 2026-03-28 |
| Severity | Customer line stop risk (sorted at customer) |

---

## D1 — Team

| Role | Name | Function |
|------|------|----------|
| Champion | M. Horvath | Quality Manager |
| Team lead | P. Novak | Process Engineer |
| Member | A. Kovac | Production Supervisor, Line 3 |
| Member | L. Benes | Incoming / Final Inspection |
| Customer contact | J. Meier | Acme Auto SQE |

---

## D2 — Problem description

On 2026-03-11, Acme Auto Plant Bratislava reported that brake hose retainer clips (TC-BH-4412) from delivery note DN-78441 (shipped 2026-03-04, qty 4,800 pcs) failed to snap onto the hose during vehicle assembly. Operators observed clips that “felt loose” and did not retain the hose after hand fit.

- Symptom: clip opening width oversize; hose retention force insufficient (customer feel-check).
- How detected: assembly station B12, Acme Auto Bratislava.
- Quantity affected at customer: 37 pcs confirmed nonconforming from one tote; full tote qty 500 pcs quarantined by customer.
- Supplier stock: 12,400 pcs on hand (same tooling family) placed on hold 2026-03-12.
- Spec: opening width 12.40 ± 0.15 mm; retention force ≥ 35 N per drawing TC-BH-4412 Rev C.

Problem statement: *Clips from lot L260302A exhibited opening width above upper spec, causing failed hose retention at customer assembly.*

---

## D3 — Containment

1. Customer sorted remaining tote (500 pcs): 37 NOK, 463 OK (customer report dated 2026-03-12).
2. Supplier hold of FG stock 12,400 pcs effective 2026-03-12 14:30 CET (owner: L. Benes).
3. 100% dimensional check of FG stock started 2026-03-13 using digital caliper (opening width). Results to date: 412 / 12,400 checked; 9 NOK found and scrapped. Sort ongoing.
4. No further shipments of TC-BH-4412 until hold release approved by Quality Manager.
5. In-transit: none per logistics (ASN closed).

Break point: last conforming shipment prior to DN-78441 was DN-78102 (2026-02-18).

---

## D4 — Root cause

**Occurrence root cause:** Operator carelessness during setup of the progressive die. The operator did not pay enough attention when adjusting the forming station, which led to an oversized opening width.

**Escape root cause:** Final inspection did not notice the problem.

**Method:** Team discussion on 2026-03-14. Ishikawa sketch prepared (attachment referenced as “Fishbone_v1.pptx” — not attached to this PDF export).

**Why this is the root cause:** Experienced operators normally produce good parts; therefore the issue must be related to attention during setup.

No capability study, setup sheet comparison, or tool wear measurement is included in this revision.

---

## D5 — Corrective actions

| # | Action | Owner | Due | Status |
|---|--------|-------|-----|--------|
| CA1 | Retrain all Line 3 operators on “careful setup” and awareness | A. Kovac | 2026-03-20 | Done 2026-03-19 |
| CA2 | Remind inspectors to check opening width carefully | L. Benes | 2026-03-20 | Done 2026-03-19 |
| CA3 | Post a quality alert on the line board | P. Novak | 2026-03-18 | Done |

Interim action: continue 100% sort of FG until CA1/CA2 complete.

---

## D6 — Implementation & validation

- CA1 completed: training attendance sheet signed by 11 operators (2026-03-19).
- CA2 completed: verbal reminder in morning meeting.
- Effectiveness: “No further customer complaints received since training. Therefore corrective actions are effective.”
- No before/after opening-width distribution, no retention-force retest data, and no process capability after training are provided in this report.

---

## D7 — Prevent recurrence

- Add “be careful during setup” to existing work instruction WI-LINE3-04 (revision pending).
- Share lessons learned in monthly quality meeting (scheduled April 2026).
- Similar parts: “will be reviewed” — list not yet generated.

---

## D8 — Congratulate / close

Team is thanked for fast containment response. 8D proposed for closure pending customer acceptance of this report.

**Residual open items:** FG sort not finished; WI revision not released; similar-part review not started.

---

## Attachments listed (not embedded)

- Customer complaint AA-Q-88921 PDF
- Sort log excerpt (412 pcs)
- Training attendance 2026-03-19
- Fishbone_v1.pptx (referenced, not attached)

What I'm asking for

A comment with what landed and what missed: was the verdict fair, was anything confusing, would you trust it on a real report? Especially valuable if you're an SQE or quality manager. Tell me where it's too lenient.