This is the closing note in the diagnosis series. The earlier posts did the hard work of finding the cause — reasoning under uncertain evidence, judging when the evidence is enough, scaling to a fleet, and putting numbers under the method. This one starts where they end and asks the question that decides whether any of it mattered: how do you make sure the fault never comes back?

Fixing the cars that already failed is containment — necessary and urgent, but entirely backward-looking. It says nothing about the next firmware build, the next supplier lot, or the next program that reuses the same part. Recurrence is the real failure. The discipline that closes the gap is the corrective-action loop: contain the bleeding, remove the cause, prevent it from recurring, verify, and standardize — Ford’s 8D, the broader CAPA framework, and Deming’s PDCA wheel underneath them all. We feed our two confirmed causes — a firmware cold-throttle bug and a high-resistance connector lot — all the way through it, end to end.

We keep the running scenario from the rest of the series: a fleet of 6,000 EVs throwing one charging code (P0AE0), hiding two causes.

What it covers

Eleven sections, about twenty-two minutes, in plain language with the steps worked out.

Part A · The disciplined loop

§ 2 — The 8D / CAPA loop. The eight steps from containment through root cause, corrective action, preventive action, verification, and standardization — laid out as a ratchet you cannot short-circuit, with the loop in pseudocode.

§ 3 — Contain ≠ correct ≠ prevent. The three actions people constantly conflate, drawn as a staircase: stop-the-bleeding, fix-this-batch, make-it-impossible — each reaching further forward in time.

Part B · Feed the cause back into design & process

§ 4 — DFMEA / PFMEA updates. Turning the confirmed cause into a documented failure mode with severity × occurrence × detection (RPN), and re-scoring so the number actually falls.

§ 5 — Process control plans & SPC. Charting the manufacturing parameter that caused it — the connector crimp force — so a drift trips before a single bad part exists.

§ 6 — Poka-yoke / error-proofing. Making the failure physically impossible: a keyed connector the wrong lot can’t seat, a compile-time guard the firmware cast bug can’t pass.

Part C · Catch it earlier next time

§ 7 — The escape point. Why validation missed it, and how adding the specific missing gate — a cold-charge HIL test, a unit test for the cast — closes the escape.

§ 8 — Lessons-learned & institutional memory. Wiring the case into a knowledge base, FMEA library, and design guidelines so the next program inherits the fix instead of re-suffering it.

§ 9 — Worked example. Both causes run all the way through the loop — 8D steps, FMEA updates, a poka-yoke each, the added test, the standardized guideline.

§ 10 — Practical notes. Field rules for closing the loop.

§ 11 — References & further reading. Quality engineering, reliability, and the lean tradition, with pointers.

Read it

Open the monograph →

The monograph lives at its own URL in the warm-paper layout of the series, with a flowchart of the eight-step loop, the contain/correct/prevent staircase, a before-and-after RPN figure, an SPC control chart on the cause, a before/after poka-yoke panel, an escape-point diagram, the knowledge loop, a worked example with two cause cards and a summary table, two algorithms, practical notes, and references.

Where it sits

The diagnosis series, in order:

I · The core method

  1. Root-Cause Analysis Under Uncertain, Heterogeneous Evidence
  2. When Is the Evidence Enough?
  3. Harder Cases in Diagnosis

II · At fleet scale

  1. Fleet-Scale Root-Cause Analysis
  2. Fleet RCA, Made Rigorous

III · Proof, foundations & prevention

  1. Proving Cause with Experiments
  2. Diagnosis on the Vehicle
  3. The Data Plumbing Behind Fleet Diagnosis
  4. From Root Cause to No Cause — (this post)

Full map: The Diagnosis Series index.

← Back to Autonomy