domains / families / software-engineering / poka-yoke

poka-yoke

authentic

Mistake-proof code, config and process: make the wrong action impossible or self-announcing rather than documented.

When to use

• Use when the user says "poka-yoke this", "mistake-proof it", or "make this harder to get wrong".
• Use when designing an interface, schema or state machine and the ask is "make invalid states unrepresentable" or "so callers cannot screw it up".
• Use when auditing existing code for footguns: "what could bite us here", "what is easy to misuse".
• Use after an incident, when the fix must close the class rather than the case: "make sure this never happens again", "this is the third time".
• Especially for money, auth, permissions, deletion, migrations and pipelines, where failure is silent.

When not to use

• Poka-yoke reduces predictable misuse; it cannot prove that a design is correct or cover
• The strongest control may be unavailable in the current language, platform or compatibility
• A guard can itself be wrong, overbroad or operationally expensive. Validate proposed devices
• This method complements, but does not replace, domain review, security review, testing,

Skill page

Source