CAPA / 8D — reuse that reaches backwards

Every quality system promises that lessons learned get applied to the next project. Almost none of them can show it happening. The lesson goes into a register, and the register gets consulted when somebody remembers to consult it.

This exercise tested whether KF does better, and set the bar high: not "can a new project inherit a lesson?" but "does a lesson reach a project that already existed?"

What was built

A reusable problem-solving cycle as a type — the eight disciplines, PS0 through PS8, each a task with its own obligations. Instantiating it gives a team the whole 8D skeleton with nothing to remember.

Beside it, a candidate-cause library: recurring root causes, grouped the way a fishbone groups them — material out of specification, work instruction inadequate, tool or fixture worn beyond limit, inspection frequency too low to catch the defect. Each one an item, reusable, linkable from any investigation.

Then a real process to hang it on: two machined brackets, each with the same four operations — machine, deburr, inspect, ship — and a real defect. Burrs remaining after deburring, traced to a tool worn past its limit, with no tool-life limit defined.

The test that decided it

The corrective action for that defect is specific to Bracket A. The preventive action is not: define and monitor a tool-life limit belongs to deburring as an operation, wherever it happens.

So the lesson was promoted to the type Deburring operation — and nothing else was touched.

Bracket B was typed against that operation before the lesson existed. Nothing was written to it, before or after. Its checklist was saved to disk on both sides of the promotion.

Before: the Check column was empty. After: a row reading Deburr ← Deburring operation | Define and monitor a tool-life limit.

The same row appeared simultaneously on Bracket A's deburr operation, typed earlier still. Every edge touching Bracket B was verified identical before and after — the inheritance is computed at read time, not copied at write time.

Verdict: the reuse loop is real, and it is retroactive. All six acceptance checks passed.

Why this is the hard version of the claim

A system that pushes a lesson to future instances is doing template expansion. Useful, but it means the lesson is frozen at the moment of copying, and everything already in flight misses it.

KF resolves the checklist when you ask for it. Add a requirement to a type today and every instance owes it from that moment — including the project that started eighteen months ago and is halfway to shipping. That is exactly the population a lessons-learned register never reaches.

What it did not do

The exercise found real defects, and they had to be fixed before the run completed cleanly. That is the point of running it rather than describing it.

The honest limits worth stating:

• The 8D pack is a convention, not an enforced workflow. KF will not stop you closing D5 before D4. If you need gate enforcement, the type library expresses the shape but not the sequencing.
• Promotion is a judgment call, and stays one. KF shows you which lessons have not been generalised — that is the inverted checklist — but deciding that a lesson is general rather than local is engineering work, and it should be.