Protocol
Define the system boundary before optimizing
Optimization starts by deciding what is inside the model.
When it fits
- When a local process looks inefficient but upstream causes and downstream consequences are unclear.
When to avoid it
- A causal map is a hypothesis, not proof. Keep evidence, time scale, boundary choices and alternative explanations visible before acting on a loop.
Why it matters
Name the outcome, time horizon, actors, stocks, flows and dependencies included in the analysis, plus important factors deliberately left outside. Revisit the boundary if the proposed fix pushes cost beyond it.
Steps
- State the outcome and time horizon.
- List included actors, resources and dependencies.
- List major exclusions.
- Ask where cost or risk could be displaced.
An example
A support team wants faster ticket closure; widening the boundary reveals that premature closure moves rework into customer escalations.
Check your result
The boundary is explicit and the proposed improvement cannot succeed merely by exporting the problem.
Keep this limit in mind
- A causal map is a hypothesis, not proof. Keep evidence, time scale, boundary choices and alternative explanations visible before acting on a loop.
Connected ideas
Useful withSeparate stock from flow
Evidence and sources
Supports
System dynamics work emphasizes that well-intended interventions can be defeated by feedback-driven system responses, a pattern described as policy resistance.
A qualitative feedback story is not enough; links, delays and predicted behavior still need empirical or operational checking.
System Dynamics Modeling: Tools for Learning in a Complex World · Abstract