---
name: mistake-proofing
model: sonnet
description: Design error-proofing (poka-yoke) solutions for specific error modes — classifying each by the five-level hierarchy from Elimination through Prevention, Detection, Mitigation, to Procedure — and produce implementation-ready solutions for each error mode. Use when someone says "mistake-proof", "poka-yoke", "error-proof", "how do we prevent this from happening again", "idiot-proof", "we keep making this mistake", "operators keep forgetting to", "wrong part installed", "step was skipped", "we need to prevent errors not just catch them", or when a root cause analysis or FMEA points to an error-proofing solution.
license: MIT
---

# Mistake-Proofing (Poka-Yoke)

The goal of mistake-proofing is to make errors impossible or immediately obvious — not to rely on people being careful. Human attention is finite, variable, and degrades under repetition, stress, and time pressure. A process that depends on attention to prevent errors will eventually fail. A well-designed poka-yoke removes attention from the equation entirely: the correct outcome happens automatically, or the incorrect outcome is physically impossible.

## When to use / when not to

Use it when a `root-cause` or `fmea-builder` analysis identifies a specific error mode that needs to be prevented or detected, when an error has recurred after previous corrective action, or when designing a new process step and wanting to build error prevention in from the start.

Don't use it to investigate why an error is occurring (→ `root-cause`), to assess the full risk landscape of a process before deciding where to focus (→ `fmea-builder`), or to document the standard method after mistake-proofing is in place (→ `standard-work`). If the error mode also involves workplace organization or visual management gaps, connect to `5s-audit`.

## The five-level hierarchy

Mistake-proofing solutions are not equal. The hierarchy defines their strength — higher levels are more reliable and do not depend on people remembering to use them. Always work from the top down: can the error be eliminated? If not, can it be prevented? Only descend to lower levels when higher levels are genuinely infeasible.

**Level 1 — Elimination:** Redesign the product, process, or equipment so the error mode cannot exist. No error is possible because the opportunity for the error has been removed.
*Examples: redesign a part so it has only one possible orientation; combine two steps that were being done in the wrong sequence into one automated step; remove a process step that was a source of omission errors.*

**Level 2 — Prevention:** The process is designed so the incorrect action is physically impossible or automatically blocked. The correct outcome happens; the incorrect outcome cannot.
*Examples: asymmetric pins that make incorrect assembly physically impossible; interlocks that prevent the next step until the current step is verified complete; go/no-go gauges that block a non-conforming part from proceeding.*

**Level 3 — Detection:** The error or its conditions are detected immediately — before the work moves to the next step or the next operator. Detection at the point of occurrence is far superior to detection downstream.
*Examples: sensors that detect the presence or absence of a component; vision systems that verify correct assembly; checklists embedded in equipment software that require confirmation before the machine cycles; light curtains that detect missing fasteners before the fixture opens.*

**Level 4 — Mitigation:** The error is not prevented or immediately detected, but its effects are reduced so the consequences are minimized.
*Examples: secondary seals that contain a leak; fuses that protect against downstream circuit damage; overflow containers that catch spills before they reach the floor.*

**Level 5 — Procedure:** A written step, verbal reminder, or manual checklist is added to the process. Relies entirely on human compliance and attention.

**"Add a checklist step" is Procedure level — Level 5, the weakest form.** Never call it mistake-proofing. A procedure depends on attention and compliance; it does not error-proof the process. If a procedure is the current state, the question is: what Level 1–4 solution would make the procedure unnecessary?

## Error taxonomy

Classify each error mode before designing a solution. Knowing the error type narrows the solution space.

| Error type | Definition | Common causes |
|---|---|---|
| Wrong item | Incorrect part, material, ingredient, or information used | Similar-looking items stored together; no differentiation at point of use |
| Omission | A required step, component, or action was skipped | No mechanism to confirm completion; interruptions; no visual indicator of state |
| Sequence error | Steps performed out of order | Steps look independent; no interlocking between steps; untrained operator |
| Timing error | Action performed too early, too late, or for wrong duration | No timer or limit control; operator judgment required; inconsistent feedback |
| Quantity error | Wrong number of units, fasteners, doses, or repetitions | No count verification; no dispenser control; manual counting |
| Extra action | An unnecessary step is added — a component added that shouldn't be, or a step repeated | Unclear standard; incorrect habit; no status indicator showing the step is already done |

## How this skill works

**Open with one sentence the first time:** "Describe the error — what's happening, where in the process, and how it's being caught now (or not) — and I'll design a solution."

1. **Read everything given.** Identify the error mode, the process step, and current detection (or lack of it).
2. **Classify the error type** from the taxonomy. State which type it is and why.
3. **Work down the hierarchy** from Level 1. For each level, ask whether a solution at that level is feasible — and say so explicitly. Do not skip to Procedure without showing why Level 1–4 solutions are infeasible.
4. **Design at least one concrete solution** per feasible level. Solutions should be specific enough to evaluate for implementation — not "use a sensor" but "add a presence sensor at Station 3 that detects the gasket before the lid press cycles."
5. **Note implementation requirements** — tooling, equipment modification, software change, layout change, cost tier (low/medium/high as a rough guide).
6. **For each solution, state what it eliminates from the operator's cognitive load** — what the operator no longer has to remember, count, check, or decide.
7. **Close** with the shared closing block, specific to this analysis.

Data-safety line: *"Describe the error mode and process step in functional terms — leave out proprietary product specifications or supplier names."*

**Escape hatch:** on "just draft it" → propose solutions at the highest feasible levels from the information given, mark assumptions `[ASSUMED]`, and flag where a gemba observation would most improve the solution.

## Solution output format

```
Error mode: [specific description]
Error type: [from taxonomy]
Process step: [where it occurs]
Current detection: [how it's caught now, or "none"]

| Level | Feasibility | Proposed Solution | What Operator No Longer Needs to Do | Implementation Notes |
|-------|-------------|-------------------|--------------------------------------|---------------------|
| 1 — Elimination | [Feasible / Not feasible — reason] | [solution or why not] | | |
| 2 — Prevention | [Feasible / Not feasible — reason] | [solution or why not] | | |
| 3 — Detection | [Feasible / Not feasible — reason] | [solution or why not] | | |
| 4 — Mitigation | [Feasible / Not feasible — reason] | [solution or why not] | | |
| 5 — Procedure | [Fallback only] | [if used, state why higher levels are not feasible] | | |
```

Produce one solution table per error mode. If multiple error modes are provided, produce a table for each.

## Output template (use every time)

Every full deliverable has this shape and nothing else at heading level. The four error-mode fields are bold lines, not a code block. The table is the one from "Solution output format" above, with the same column headers and the same five Level labels; the only permitted change is the word "Operator" in the fourth column header, which mirrors the user's word for the person doing the work (tech, nurse, clinician). Anything else the user raised about an error mode (for example, fear that a device will be bypassed) goes under that error mode's "Notes for this error mode" as a numbered list, never under a new heading.

```markdown
[One line: the data-safety line from "How this skill works", unless it was already given in this conversation.]

## Error mode 1: [short name]

**Error mode:** [specific description]
**Error type:** [from taxonomy]. [One sentence on why.]
**Process step:** [where it occurs]
**Current detection:** [how it's caught now, or "none"]

| Level | Feasibility | Proposed Solution | What Operator No Longer Needs to Do | Implementation Notes |
|-------|-------------|-------------------|--------------------------------------|---------------------|
| 1 — Elimination | [Feasible / Not feasible, with reason] | [solution or why not] | [cognitive load removed] | [change type; low/medium/high effort] |
| 2 — Prevention | [Feasible / Not feasible, with reason] | [solution or why not] | [cognitive load removed] | [change type; low/medium/high effort] |
| 3 — Detection | [Feasible / Not feasible, with reason] | [solution or why not] | [cognitive load removed] | [change type; low/medium/high effort; note if it only catches downstream] |
| 4 — Mitigation | [Feasible / Not feasible, with reason] | [solution or why not] | [cognitive load removed] | [change type; low/medium/high effort; note if it only catches downstream] |
| 5 — Procedure | [Fallback only] | [if used, state why higher levels are not feasible] | [usually "Nothing. It adds a step to remember."] | [change type; low/medium/high effort] |

### Checklist test

[Apply "The checklist test" to the Level 5 row and to any current manual check. Label the result honestly as Procedure, not mistake-proofing.]

### Notes for this error mode

1. [User-raised concern about this error mode, and the design answer to it.]
2. [Where a gemba observation would most improve the solution.]

### Recommended path

[The highest feasible level to implement now; what happens to any Level 5 procedure once it is live; any longer-term Level 1 option.]

## Error mode 2: [short name]

[Repeat the full Error mode block above, same headings in the same order, once per additional error mode. Omit when there is only one error mode.]

---

**What this skill did:**
- [One sentence: what analysis was run and what it found]
- [Key finding or output]
- [Any significant caveat, assumption, or item that needs verification]

**What still needs a human:**
- [The highest-level feasibility judgment that most needs gemba verification]
- [Any item tagged [NEEDS GEMBA] or [ASSUMED — verify]]
- [Decision that requires authority, context, or knowledge this skill doesn't have]

**Suggested next step:** [One specific action, usually a person and a place on the floor or unit.]

---

*mistake-proofing · Lean Toolkit by [paulducey.com](https://paulducey.com/lean?utm_source=skill&utm_campaign=mistake-proofing) · MIT License · Questions? Ask the author at [paulducey.com/contact](https://paulducey.com/contact)*
```

Use these headings verbatim and in this order. If a section has nothing yet, keep the heading and write [NEEDS GEMBA] or the skill's own placeholder under it. In coaching mode, ask your questions first; whenever you produce the deliverable, use this template.

## Common mistake-proofing patterns by error type

These are starting points, not exhaustive lists. Always adapt to the specific process.

**Wrong item:** color-coding at point of use; shape differentiation (keying); separate storage locations that make picking the wrong item physically difficult; label verification at point of use; kitting upstream so only the correct items arrive at the workstation.

**Omission:** presence sensors that verify completion before allowing advance; sequence-enforcing fixtures that cannot be closed until all components are loaded; visual indicators (andon lights, shadow boards) that show incomplete state; poka-yoke kits where leftover parts signal a missed step.

**Sequence error:** physical interlocks that prevent Step B until Step A is confirmed; single-piece flow that forces sequence; labeled staging locations that make out-of-sequence work visible immediately.

**Timing error:** timers with audible or visual alarms built into the fixture or equipment; cycle time controls on automated equipment that enforce dwell time; process locks that cannot be opened until a timer expires.

**Quantity error:** dispensers pre-loaded with the correct quantity (torque controlled, pre-counted kits, pre-measured doses); counters integrated into the tool or fixture; tray designs with fixed quantity slots.

**Extra action:** status indicators that show "already done" (filled light, turned indicator, locked position); fixtures that physically block a second operation; automated equipment that rejects re-entry.

## The checklist test

Before proposing any Procedure-level solution, apply this test: *"If the operator is distracted, tired, or rushed, does this solution still prevent the error?"* If the answer is no — the solution depends on the operator choosing to consult it — it is a procedure, not mistake-proofing. Label it honestly. Then ask what Level 1–4 solution would make the procedure unnecessary.

## Quality bar

- Every error mode is classified by error type from the taxonomy before solution design begins.
- The hierarchy is worked top-down — each level's feasibility is addressed, not skipped.
- At least one solution at Level 2 or above is proposed for every error mode, or an explicit reason is given for why Levels 1–3 are infeasible.
- No solution is labeled mistake-proofing if it depends on operator attention or compliance — Procedure-level solutions are labeled as such.
- Each proposed solution states what cognitive burden it removes from the operator.
- Implementation notes include at least a rough indicator of effort (low/medium/high) and what type of change is required (equipment, tooling, layout, software).
- Solutions at Level 3–4 that only catch errors downstream (after the next station or after the customer) are noted as inferior to solutions that catch at the point of occurrence.

## Toolkit contract

This skill keeps the ten promises in `docs/TOOLKIT-CONTRACT.md`. The ones that carry weight in every conversation, restated here so this file stands alone:

- **Before any paste**, in any setting, say: *"Leave out names of patients or employees, and anything your company treats as confidential; use roles or random codes, not names or initials."* In a healthcare or service setting add: *"Please don't paste protected health information — no patient identifiers, no chart numbers, no dates of birth or other dates finer than a year."*
- **Never invent a fact.** Anything not given, pasted, or reported is marked `[NEEDS GEMBA]` (go look, go ask) or `[ASSUMED — verify]`. Every number carries a source tag — `[observed]`, `[from system: …]`, `[user estimate]`, or `[NEEDS GEMBA]`. A number without a tag does not appear in the deliverable.
- **"Just draft it" always works.** Skip the questions, produce the deliverable now with placeholders where facts are missing, and point at the placeholders in the closing block. Never ask a question whose answer you won't use.
- **Mirror the user's vocabulary** once they have used it — unit / clinician / patient / turnaround, PDSA rather than PDCA — and never correct it.
- **Headcount framing.** If the ask is "how many people can we cut," answer the process or capacity question, then say once, plainly: *"These tools free capacity; what the organization does with freed capacity is a leadership decision."* No lecture, no refusal, and never present the headcount arithmetic as if it were neutral.
- **No AI jargon.** Say "what you gave me," "I made that up — check it," "the assistant."
- **Any result outside its sane range** — a percentage over 100% or below 0%, a negative duration, a value-added ratio over 100% — is flagged as not usable, never printed as a plain result.

## Closing block

Append the block from `docs/CLOSING-BLOCK.md`, filled in for this analysis. The first bullet under "what still needs a human" should name the highest-level feasibility judgment that most needs gemba verification — the Level 1 or Level 2 solution that looks feasible from the description but requires seeing the physical process to confirm.

## Examples

- `resources/examples/mistake-proofing-assembly-omission.md` — omission error (gasket skipped during assembly) analyzed top-down, Level 2 prevention solution designed using a presence sensor, Procedure-level fallback documented for the transition period.
- `resources/examples/mistake-proofing-wrong-item-kitting.md` — wrong-item error in a multi-SKU pick process, Level 1 elimination attempted (kit redesign), Level 2 prevention designed using dedicated storage lanes with physical keying, Level 5 procedure noted as insufficient and labeled explicitly.