What the Parts Can't Tell You

The Structure of Things — Part 1 of 6

Two intersections can have the same number of lanes, the same kinds of traffic lights, and roughly the same number of cars. One moves. The other backs up for blocks.

You could examine every vehicle, inspect the pavement, and test every bulb in the signals. You might find a mechanical defect, and sometimes that would solve the problem. But if all those components are working as intended, you still haven't explained why traffic stops. To answer that question, you need to look at the timing of the lights, the order in which vehicles enter, the turns that cross one another, and whether a queue blocks the next intersection.

The problem may not be in any single part. It may be in the arrangement.

That is the starting point for The Structure of Things: what a system does depends not only on what it contains, but on how those things are connected, organized, and constrained.

The limits of taking things apart

Taking a system apart is an extraordinarily useful way to learn about it. If a motor stops turning, inspecting the motor is sensible. If a bridge component cracks, its material properties matter. A good engineer needs to know what the parts can do, how they fail, and under what conditions they operate.

But an inventory of parts is not yet an explanation of a system.

A list of the musicians in an orchestra doesn't tell you what music they'll play. A list of employees doesn't tell you how a company makes decisions. A list of software functions doesn't tell you which function can call another—or what happens when the call fails. Each component may be thoroughly understood while the behavior of the assembled whole remains a mystery.

The conventional response is often to examine the components more closely. Sometimes that works. Sometimes it produces increasingly precise information about the wrong level of the problem.

Structuralism asks a different set of questions. What is connected to what? Which interactions are possible? What travels through those connections? What rules govern the transfer? Where can a process stop, reverse, or change direction? Which relationships are necessary for the observed outcome to occur?

None of this makes the components unimportant. Their capacities are among the conditions under which a structure operates. The point is that knowing the capacities of the pieces does not, by itself, tell us what the assembled system is capable of doing.

A form is not an accountability system

Consider a fictional public agency with a complaint portal, an intake office, an investigator, and a decision-making body. On an organizational chart, all the expected pieces are present. The agency accepts complaints. It has staff assigned to review them. It has a body authorized to make decisions.

Now look at the actual route of a complaint.

A resident submits a form. The intake office assigns it a reference number. The form enters an archive. Investigators can read the archive, but their findings have no defined route into the decision-making process. The decision-making body continues its work without receiving those findings.

Nothing in that scenario requires a dishonest employee or a broken computer. The form might be processed promptly and the investigator might do excellent work. Yet the process, as described, cannot reliably turn an investigation into a consequential decision. Its components exist; the required connection does not.

This is an invented example, not an accusation against a particular agency. It illustrates a useful rule of analysis: the presence of a function on paper is not evidence that the function is connected to an outcome.

Imagine replacing every person in the agency while preserving the same routes and rules. The underlying failure could persist. Now imagine keeping the same personnel but adding a required, reviewable path from findings to decisions, together with a recorded disposition. The possible outcomes change even though the people do not.

The difference is structural.

What counts as a structure?

For our purposes, a structure is the arrangement of components, their interfaces, their connections, and the constraints that govern their interactions. The word geometry will appear throughout this series, but it doesn't always mean physical shape. A software permission boundary, an approval chain, and a network route all have an operative geometry: they determine what can reach what and under which conditions.

This is a practical method of examining existing systems. It is not a claim that every fact in the universe reduces to a network diagram, or that relationships are a substitute for evidence. We still have to observe what components do, establish which connections exist, and test whether a proposed explanation accounts for the outcome.

A structural explanation becomes useful when it makes a distinction we can check. If two arrangements contain comparable parts but behave differently, which relationship accounts for the difference? If a process repeatedly fails, does the failure follow a component, or does it remain after that component is replaced? If someone claims a system performs a function, can we trace the route by which that function produces a result?

These questions shift attention from the names of things to their actual operation.

The map must follow the work

Consider a customer-service operation. Its published workflow says a request goes from submission to review to resolution. The real workflow might send it from submission to automatic acknowledgment to an unattended queue. The public diagram says one thing; the functioning structure does another.

A useful structural map must describe the latter. Titles, departments, mission statements, and interface labels are clues, not proof. A button marked Submit proves that a button exists. It does not prove that anyone receives the submission, that a receiving system can interpret it, or that the information can affect a decision.

To investigate the system, start with an outcome that matters. Then trace backward and forward through the operations that produce it. Identify each component's inputs and outputs. Locate the places where information is transformed, rejected, delayed, or lost. Record the rules that admit some interactions while excluding others. When possible, change one relationship or compare two arrangements to see whether the outcome changes.

The result is not merely a diagram. It is a testable account of why the system behaves as it does.

A different kind of question

If we begin with Who failed?, we may miss a configuration in which even competent people cannot produce the intended result. If we begin with Which component is broken?, we may overlook a connection that was never established. If we begin with Does this institution have an oversight department?, we may confuse the existence of a department with the existence of oversight.

Structuralism doesn't forbid those questions. It makes us ask what they leave out.

The first principle is simple: the parts matter, and so do the relationships that make them a system. You cannot reliably infer the behavior of the whole from the parts alone.

In Part 2, we'll give those relationships precise names. A connection, an interface, and a rule about what may pass through it are not the same thing. Treating them as interchangeable is how systems end up looking connected while failing to perform.