making-illegal-states-unrepresentablelisted

# Making Illegal States Unrepresentable ## Overview Every state a type can hold is a state somebody must handle. If the type permits combinations the business forbids, then every consumer either checks for them, or is wrong for inputs that will eventually arrive. The alternative is to design the type so the forbidden combination cannot be built. Then the check is not skipped, forgotten, or duplicated: it does not exist, because there is nothing to check. This is the single highest leverage rule in domain modelling, and it composes with everything else. ## When to use - A record holds fields that are only meaningful together - Code checks a condition that "should never happen" - A function begins with three guard clauses about its own input - A bug report says a value was in an impossible state - Reviewing any domain type before code is written against it Not for: input that genuinely arrives malformed from outside, which is parsed at the boundary. See [crossing-io-boundaries](../crossing-io-boundaries/SKILL.md). Also not for a shape whose field set is decided outside the code, by config, by a tenant, or by an admin. There is no closed set of cases to design against, and modelling one produces a type with everything optional, which is the defect this skill exists to remove. See [choosing-types-or-plain-data](../choosing-types-or-plain-data/SKILL.md). ## Core rules 1. **Count the states.** List what the type can hold and what the business allows. Every extra state i