A change boundary is the interface where a change crosses from one state or subsystem to another in a complex system. Not all change boundaries are equally risky. **Two categories:** | Type | Downside Risk | Hedgeable? | Operator Role | |------|--------------|------------|---------------| | Low-risk | Small | Yes (e.g., auto-scaling groups for EC2) | Automation sufficient | | High-risk | Large | No (e.g., deploy with subtle bugs) | Active human operator required | **Core insight**: The safety of complex systems must be considered *holistically* — human operators included. Simple systems can be analyzed in terms of failure probabilities; complex systems require accounting for the human's ability to detect and correct errors that automation misses. **Implication for design**: Make change boundaries *visible and explicit*. Automation should not obscure distinctions between safer and riskier actions. When an action traverses a high-risk boundary, the human operator should know it, understand the ambient risk, and be primed to respond. **Source**: Coda Hale, "Risky Business Requires Active Operators," blog.skyliner.io, ~2016.