Add boundary clauses to validated schemas: tested conditions AND untested conditions
Reformulate validated schemas with explicit boundary clauses that specify the conditions under which they were tested and the conditions under which they remain untested.
Why This Is a Rule
A validated schema without boundary clauses is dangerous because validation feels like proof. "I tested this and it worked" becomes "this is true" — but it was tested under specific conditions, and conditions you didn't test remain unknown territory. The schema might fail spectacularly in untested conditions while feeling validated.
Boundary clauses convert a schema from "validated = true" into "validated under [conditions], untested under [other conditions]." This precision prevents over-application: you know where the schema is trustworthy (tested territory) and where it's uncertain (untested territory). Applying the schema in untested conditions becomes a conscious choice rather than an invisible assumption.
The "untested conditions" clause is as important as the "tested conditions" clause. Listing what you tested tells you where the schema is strong. Listing what you didn't test tells you where caution is required — and where future testing should focus.
When This Fires
- After completing schema validation (Test schemas at the smallest possible scale first — observe results against pre-stated predictions, Test each component of a compound schema independently — compound failures give no diagnostic)
- When a validated schema is about to be applied in a new context
- During schema documentation when formalizing a belief as operational
- When someone asks "does this always work?" about a validated schema
Common Failure Mode
Listing only tested conditions and omitting untested ones: "Validated under: team sizes 5-15, B2B SaaS context, US market." This looks complete but leaves the untested boundary invisible. Adding "Untested under: teams >30, B2C, non-US markets, non-software domains" makes the uncertainty explicit.
The Protocol
After validating a schema: (1) Write the schema statement. (2) Add "Tested under: [specific conditions where validation occurred — context, scale, domain, timeframe]." (3) Add "Untested under: [specific conditions where the schema has NOT been tested — different scales, domains, contexts]." (4) When applying the schema in the future, check: are current conditions in the "tested" or "untested" zone? Tested → apply with confidence. Untested → apply cautiously, treating it as a hypothesis rather than a validated tool.