Attach scope metadata to every schema — where it was built and what conditions it assumes
Store each schema with explicit scope documentation specifying the domain where it was built and the structural conditions it assumes, treating scope as mandatory metadata rather than optional annotation.
Why This Is a Rule
Schemas built in one domain get applied in others without scope adjustment. A leadership schema built in a 500-person corporation gets applied in a 10-person startup. A relationship schema built in your twenties gets applied in your forties. A debugging schema built for monolithic architectures gets applied to microservices. Each schema worked in its original scope — the failure happens when it's applied outside that scope without recognizing the mismatch.
Explicit scope documentation prevents silent scope creep by recording where the schema was built (which domain, which conditions, which era) and what structural conditions it assumes (team size, technology stack, market maturity, relationship dynamic). When you're about to apply the schema in a new context, the scope metadata tells you whether the conditions match.
Treating scope as mandatory metadata rather than optional annotation means every schema must have it — not "add scope if you remember" but "a schema without scope documentation is incomplete." This structural requirement catches the schemas most likely to be misapplied: the ones you use so confidently that you've forgotten they have scope limitations.
When This Fires
- Documenting any operating schema in your personal system
- Before applying a schema in a new domain or context
- When a schema that "always worked" suddenly fails (scope mismatch likely)
- During schema audits when checking whether schemas are applied within their validated scope
Common Failure Mode
Storing schemas without scope: "Move fast and break things" with no notation that this was built for early-stage consumer products with low switching costs. Applied to healthcare software, financial systems, or late-stage enterprise products, it produces catastrophic outcomes. The schema isn't wrong — it's out of scope.
The Protocol
For every schema you store: (1) Record: "Built in [domain/context]." (2) Record: "Assumes [specific structural conditions]." (3) When applying the schema in a new context, check: do the current conditions match the documented scope? (4) If conditions match → apply with confidence. If conditions differ → adapt the schema to the new conditions before applying, or find a schema with matching scope.