Boundaries Decide What Exists

LESSON

002 25 min beginner

Boundaries Decide What Exists

By the end of this lesson, you will be able to...

Choose a model boundary that matches a question, time horizon, and decision.

Identify what a boundary makes visible, what it hides, and what crosses its edge.

Compare a narrow and a wider model without assuming that either one is universally better.

Idea in one sentence: A model boundary decides which parts of a situation can affect the explanation, so an invisible factor can look like it does not exist.

Core Insight

Imagine a public library preparing staff for a busy Saturday. The manager uses the previous lesson's simple model: past visitor counts plus planned events produce an estimate of how many people will arrive.

At 11:00, the total visitor count looks normal. The front desk is still overwhelmed. A children's workshop has created a long queue for one room, while the reading area is almost empty. The staffing model says “normal day” because it only represents the whole building as one number.

The manager and the children's librarian now disagree about the model. The manager says the count proves that staffing is adequate. The librarian says the model has ignored the problem.

Both are looking at the same library. They are using different boundaries.

The manager's boundary is:

the whole building, one total visitor count, and one staffing decision.

The librarian's boundary is:

separate rooms, visitor groups, queues, staff skills, and the next two hours.

Neither boundary is automatically correct. Each makes a different situation visible.

This is the pressure behind the lesson:

Before arguing about what a model says, agree on what the model is allowed to see.

The First Boundary Is Usually Invisible

When people say “the system,” they often imagine that the system has a natural edge. A library, a product, a team, or a neighborhood feels like a thing with a clear outline.

But a model still has to choose:

which people or components count as part of the situation;
which time period matters;
which place or level of detail matters;
which inputs are treated as outside conditions;
which output the model must explain.

The library building is a physical boundary. It does not answer every modeling question. The bus that brings visitors is outside the building but may affect arrival waves. A school event is outside the library's staff roster but may explain the queue. A staff member's training is inside the organization but may be invisible in a model that only counts heads.

Plain meaning:

A boundary is the line around the part of a situation that the model will explain directly.

In this scenario:

The boundary decides whether the model sees one total visitor count or separate rooms, visitor groups, queues, and staff capabilities.

Technical name:

This is a model boundary. It separates what the model represents from what it treats as context, input, or outside its current purpose.

The word “outside” does not mean “irrelevant.” It means “not represented by this model in this form.” That distinction is easy to lose and causes many bad explanations.

The Naive Boundary: One Building, One Number

The manager's first model is attractive because it is easy to operate:

expected visitors -> required staff

It has a small boundary:

Inside the model	Outside the model
Total visitors in the building	Which room they use
Total staff on duty	Staff skills and role fit
Opening hours	Queue length at a specific service
Planned large events	Arrival timing inside the day

This boundary may be good enough for a rough monthly budget. It is weak for deciding whether the children's room needs another trained staff member at 11:00.

The model is not failing because it is small. It is failing because its purpose changed without its boundary changing with it.

This is a common pattern:

A small model works for an initial question.
People reuse it for a more specific question.
The missing detail becomes the main cause of the observed problem.
The model reports “nothing unusual” because the relevant thing is outside its boundary.

A Boundary Is a Design Choice

To choose a boundary, start with the question rather than the objects you happen to notice.

The library may ask three different questions on the same Saturday:

Budget question: How many staff hours should the library fund this month?
Service question: Where will visitors wait longer than ten minutes today?
Safety question: Can the building evacuate each room if the main exit is blocked?

The models need different boundaries.

Question	Useful inside boundary	Important outside or interface
Monthly staff budget	Opening hours, total demand, contracted hours	Room-level queues and one unusual event
Service waiting time	Rooms, service desks, visitor groups, staff skills, time of day	Long-term budget rules
Evacuation safety	Rooms, exits, doors, mobility needs, staff roles, crowd movement	Ordinary checkout speed

The boundary is not a decoration added after the model. It is part of the design. It determines which variables can influence the output and which explanations will be impossible to express.

Worked Path: Expanding the Library Model

Let us repair the Saturday staffing decision without trying to model the entire city.

Starting point

The question is:

Why is the children's room queue long when total library visits look normal?

The old model cannot answer this. Its output is a building-level staffing estimate.

Step 1: State the old boundary

Inside: total visitors, total staff, opening hours
Outside: room, visitor group, queue, staff skill, arrival time
Output: total staffing adequacy

The first useful move is not to add random data. It is to name what the old model could not see.

Step 2: Choose a new question-sized boundary

For the queue question, include:

the children's room and the front desk;
visitors attending the workshop;
arrivals in 30-minute intervals;
staff trained to supervise the workshop;
queue length and waiting time.

Keep the wider city, the monthly budget, and the building's entire history outside for now. They may matter later, but including them immediately would make this local diagnosis harder to inspect.

Step 3: Follow one small sequence

Time	What the narrow model sees	What the wider service model sees
10:30	42 visitors in the building	18 workshop visitors arriving at the children's room; 24 elsewhere
10:45	55 visitors total; still near the normal average	Workshop queue reaches 12; one qualified staff member is occupied
11:00	61 visitors total; “normal” staffing result	Children's-room wait reaches 14 minutes; reading area has spare capacity
11:15	66 visitors total	A second qualified staff member reduces the queue; total building count changes little

Step 4: Produce a different decision

The old model recommends no change because total demand is ordinary. The new model recommends moving or adding one trained person during the workshop window.

Step 5: Compare the boundaries

The wider model did not discover a hidden magical variable. It changed the unit of explanation from “the building” to “rooms, groups, time, and skill.” The same visitors now form a pattern the first boundary could not express.

The naive failure was to treat the first boundary as the situation itself. The better approach treats it as one useful view with a known blind spot.

So far, we have seen the core mechanism: boundary choice changes the possible explanations and decisions. A factor outside the boundary cannot influence the model's output, even if it strongly influences the real situation.

Boundaries Have Edges and Interfaces

A model does not always need to place a factor fully inside or fully outside. Some important relationships cross the edge.

The school event is outside the library's staffing roster, but it is an input to visitor arrivals. The bus route is outside the building, but it is an interface through which people enter. The monthly budget is outside the 11:00 queue diagnosis, but it constrains which staffing changes are possible.

It helps to label three different cases:

Inside: the model represents the factor's state or behavior directly.
Outside input: the model accepts the factor as a condition or signal without explaining it.
Interface: the model represents what crosses the boundary, such as people, requests, money, information, or constraints.

For the service model:

school event --arrival wave--> library rooms
staff roster --available skill--> workshop service
room queue --waiting time--> visitor experience
monthly budget --constraint--> staffing choices

This is more useful than drawing a perfect circle around the library. It tells us what crosses the edge and what the model is allowed to ask about.

What a Boundary Makes Impossible to Say

Suppose the model includes only total visitors. It cannot honestly explain why one room has a queue while another has spare capacity. The information has been discarded before the calculation begins.

Suppose the model includes rooms but not staff skills. It can show that the children's room is busy, but not why moving an untrained person there may fail to reduce the queue.

Suppose the model includes today but not the next hour. It may describe the current queue while missing that the workshop is about to end and a new group is arriving.

This leads to a useful diagnostic:

If the model cannot express a proposed cause, the cause may be outside the boundary rather than absent from reality.

The fix is not always “make the model bigger.” First ask whether the missing cause is relevant to the current question, and whether representing it is worth the cost.

Trade-offs and Limits

The central trade-off is that a narrow boundary makes a model easier to understand and operate, but it can hide causes that cross the edge. A wider boundary can reveal those causes, but it requires more data, more coordination, and more assumptions.

A larger model can also create a new problem: nobody knows which relationships matter. A model that includes every department, visitor, policy, and historical event may look comprehensive while producing no useful decision.

Boundaries can also create responsibility traps. If the staffing model excludes accessibility needs, no row in the spreadsheet appears responsible for them. If it excludes the queue's experience, “staffing adequate” may be technically true inside the model while visitors experience failure outside it.

Use this boundary test:

This boundary helps when the question is narrow and the omitted factors are stable enough.
It costs when the model must collect, explain, and maintain more context.
It does not protect us from a factor that changes across the edge.
You can see the boundary when a proposed explanation has no place in the model, or when the output remains normal while the lived outcome is clearly bad.

Answer: State the current boundary and ask whether the payment call should be represented as an outside input or an interface. The team should not conclude that the application code explains the whole latency just because that is all the first model contains.

Check: A city model includes traffic inside the city but treats a stadium event outside the boundary. On game night, travel times become much worse. Is the event irrelevant because it is outside?

Think first, then reveal.

Answer: No. The event may be an outside input that changes arrival flows. The model can keep it outside while representing its effect, or expand the boundary if explaining the event itself becomes part of the question.

Practice: Draw Two Boundaries

Choose one messy situation: a software incident, a hospital waiting room, a school lunch queue, or a neighborhood recycling problem.

Draw two model boundaries for the same situation:

a narrow boundary that answers one immediate question;
a wider boundary that explains one important failure the narrow view misses.

For each boundary, write:

the question and time horizon;
what is inside;
what is outside;
what crosses the edge as an input, signal, flow, or constraint;
the output or decision;
one trade-off introduced by choosing that boundary.

A good answer should show that the two boundaries are not simply “bad” and “good.” It should explain which question each one can answer and identify a failure that the narrow model cannot express.

Connection to the Next Lesson

Once a boundary is chosen, the model still needs a way to describe what matters inside it. The next question is deceptively simple:

Which things are real parts of the situation, and which things are only the signals or proxies we use to observe them?

That distinction is the focus of the next lesson.

Resources

[BOOK] The Model Thinker — Focus: Compare models by purpose instead of treating one boundary as universally correct.
[BOOK] Thinking in Systems — Focus: System boundaries, inputs, outputs, and what a model leaves outside its explanation.
[ARTICLE] Mental Models I Find Repeatedly Useful — Focus: Notice how a model's framing changes the question it can answer.

Key Takeaways

A model boundary decides what the model can explain directly and what it treats as context.
Outside factors can still matter through inputs, signals, flows, and constraints.
A narrow boundary buys clarity and lower maintenance cost; a wider boundary can reveal causes but costs more to build and operate.
If a proposed cause has no place in the model, it may be outside the boundary rather than absent from reality.
Choose the boundary from the question, time horizon, and decision—not from the physical shape of the thing being modeled.

← Back to World Modeling Foundations

← Back to Mind Cognition And Behavior

← Back to Learning Hub