Protocol
Keep reversible experiments behind a boundary
Boundaries can contain learning risk.
When it fits
- When innovation is useful but experimental changes could destabilize the stable core.
When to avoid it
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Why it matters
Place the experiment behind an interface, feature switch, sandbox or isolated process so it can be tested and removed without forcing broad migration.
Steps
- Choose the experimental assumption.
- Define the containment boundary.
- Define rollback and data isolation.
- Prevent downstream consumers from depending on unstable internals.
An example
A new AI-assisted classification path runs behind a switch and outputs the existing schema, allowing quick rollback.
Check your result
The experiment can fail or be removed without a wide coordinated recovery.
Keep this limit in mind
- Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner.
Connected ideas
Useful withSeparate policy from implementation mechanism
Evidence and sources
Supports
Parnas showed that modularization outcomes depend on decomposition criteria and argued for boundaries that hide changeable design decisions to improve flexibility and comprehensibility.
This is foundational software-design reasoning; organizational adaptations require separate validation.
On the Criteria To Be Used in Decomposing Systems into Modules · Abstract and design comparison