Edge cases that break your schema reveal boundary conditions — extract them, do not dismiss them
When an edge case breaks your schema, extract the implicit boundary condition that the edge case revealed rather than dismissing the edge case as an irrelevant exception.
Why This Is a Rule
When an edge case breaks a schema, the instinct is dismissal: "That's an unusual case, it doesn't count." But the edge case just revealed information that the schema didn't contain — a boundary condition that was implicit and unknown until the edge case exposed it. Dismissing the edge case throws away the information. Extracting the boundary condition makes the schema more precise and more useful.
"My planning schema works well" → edge case: a project with an external dependency missed its deadline. The boundary condition revealed: "My planning schema assumes I control all dependencies. When external dependencies exist, the schema needs a dependency-tracking extension." The schema isn't wrong — it's scoped. The edge case revealed the scope boundary that was previously invisible.
Annotating schemas with explicit boundary conditions converts them from vague beliefs ("this approach works") into precise tools ("this approach works under conditions A, B, and C; it breaks when D is present"). Precise schemas produce fewer surprises because their limitations are documented.
When This Fires
- When a schema/rule produces an unexpected failure
- When someone presents a counterexample to your framework
- During testing when edge cases produce surprising results
- Any time a belief "breaks" under unusual conditions
Common Failure Mode
Dismissing the edge case to preserve the schema: "That situation is too unusual to be relevant." But the edge case just taught you where the schema's boundary is. The information value is enormous — you now know a condition under which your schema fails, which prevents future failures under the same condition. Dismissing the edge case means you'll be surprised again next time.
The Protocol
When an edge case breaks your schema: (1) Do not dismiss it. (2) Ask: "What implicit boundary condition did this edge case reveal? Under what condition did the schema assume it would be operating?" (3) Extract the boundary condition explicitly: "This schema works when [conditions]. It breaks when [condition revealed by edge case]." (4) Annotate the schema with the boundary condition. The schema is now more precise — it works where it works, and you know where it doesn't.