The Structure of Things — Part 5 of 6

Two customer-service departments report the same result: 92 percent of requests closed within five days.

At the first department, closure means a staff member has carried out the requested work and the customer has confirmed the result. At the second, closure means an employee has sent a reply, even when the underlying problem remains unresolved.

The dashboards look equivalent. The experience of the customers does not.

Now imagine two completely different organizations—one a local library, the other a university laboratory—using the same intake, review, assignment, completion, and verification process for certain requests. Their missions, personnel, and vocabulary are different. Yet the routes through which those requests move may correspond almost exactly.

These cases point in opposite directions. Matching labels or matching numbers do not prove that two systems work the same way. Different-looking systems may nevertheless share an operative structure.

Part 5 of The Structure of Things is about learning to tell the difference.

Resemblance is cheap

We make comparisons constantly. A department resembles another department. A computer program resembles a workflow. One organization has a board and another has a committee. Their diagrams contain similar boxes and arrows, so we assume their behavior must be similar too.

But a box labeled Review might mean checking formatting in one system and evaluating evidence in another. An arrow might represent a request in one diagram and a binding command in the next. The diagrams may be visually interchangeable while describing different operations.

The reverse can also happen. A paper form passed across a desk and a digital message sent through an application might perform corresponding roles: accept a request, validate its type, route it to an authorized reviewer, and return a recorded decision. Their physical implementations differ, but the relationships that matter for a particular inquiry may match.

Universal Structuralism gives this comparison a name: structural equivalence.

Two systems are structurally equivalent for a declared scope when their operative structures correspond and they produce corresponding outputs under the conditions being compared. The scope matters. So do the structures. So do the outputs.

That is a stricter test than saying the systems look alike or that both produced the same number once.

Same parts, different structure

Imagine two switches, A and B, controlling a warning lamp.

In the first arrangement, the lamp turns on only when both switches are closed. The switches are arranged in series. In the second, the lamp turns on when either switch is closed. The switches are arranged in parallel.

Same kinds of switches. Same lamp. Same power source. Different connection structure.

For some inputs, the results agree. With both switches open, the lamp is off in both arrangements. With both closed, the lamp is on in both arrangements. If we tested only those two cases, we might incorrectly declare the circuits equivalent.

But close A while leaving B open. In the series circuit, the lamp stays off. In the parallel circuit, it turns on.

The difference appears not because the components changed, but because their operative connections changed. The systems are not structurally equivalent for the full set of switch combinations, and their behavior differs for some of those combinations.

This is a compact demonstration of why a useful comparison needs corresponding operating conditions. Two coincidental outputs are not enough. You must ask how the output was produced and what the system would do under the other relevant conditions.

Same outcome, different mechanism

Return to those two customer-service departments. Both may eventually report a closure. But their route to closure differs.

One system requires confirmation that the requested work occurred. The other requires only that a response was issued. Under a narrow observation—Was a closure recorded?—both may return yes. Under a different question—Did the request reach an effective resolution?—their results may diverge sharply.

Even if their closure counts happened to match across an entire month, that would not establish structural equivalence. It would establish an observed similarity in one output.

This distinction is easy to lose when institutions are compared by headline performance metrics. The same published number may be the product of different definitions, different admission rules, different permissions, and different routes through the system.

Functional equivalence means that outputs correspond for the conditions under examination even though the operative structures do not. Structural equivalence requires correspondence of the operative structures as well as their outputs. One claim does not silently turn into the other.

structuralism different things same way

Map the roles, not the names

Suppose we want to compare the way a local library handles equipment repairs with the way a laboratory handles instrument maintenance.

We would not begin by asking whether the library has someone called a technician or the laboratory has someone called a librarian. Those labels belong to their respective institutions. Instead, identify the roles relevant to the process.

A user reports a fault. An intake role records the report. A reviewer determines whether it is actionable. A responsible worker attempts the repair. A verification step determines whether the reported fault has actually been resolved. The requester receives the result.

Then establish the connections. Does the request move directly from intake to the reviewer? Can it be rejected, and on what grounds? Who is permitted to mark the repair complete? Does the verification step control closure, or merely record an opinion afterward? What happens when the repair fails?

If the corresponding nodes, pipes, wire types, constraints, authority rules, and outputs match for the process we declared, we can establish structural equivalence for that process—even if one organization works with books and the other with microscopes.

That conclusion does not say the library and laboratory are equivalent in every respect. It says something exact, limited, and useful about a process they share.

Equivalent is not identical

Part 3 introduced the bottleneck of a two-stage production line. Suppose the sealing machine handles four packages per minute and is replaced with a different model that can also seal four, with the same interface and the same behavior under the conditions we are comparing.

The resulting line is not the identical configuration: one of its components has changed. But it may remain structurally equivalent for the throughput operation under examination.

Now replace the old machine with an eight-package-per-minute model. The line's throughput may change from four to eight. The old and new configurations are no longer equivalent for a scope that includes the actual throughput value. They might still be equivalent for a narrower claim about the order and type of the stages, but that is a different claim.

In other words, identity answers Is this the same configuration? Equivalence answers Do these configurations correspond in the ways relevant to a stated comparison?

Both questions matter. Confusing them can make a legitimate improvement look like a complete redesign, or make a substantial change disappear behind an unchanged organizational label.

Structural comparisons can make predictions

Once we establish that two systems share an operative arrangement, we can look for correspondences in their constraints and possible failure modes.

If the library and laboratory really use equivalent approval routes, and the library repeatedly loses requests at a particular handoff, the corresponding handoff in the laboratory deserves inspection. That does not prove the same failure has occurred there. It gives us a specific place to look and a mechanism to test.

Likewise, if altering a connection in one system removes a bottleneck, a corresponding alteration in another may produce a similar improvement—provided the relevant capacities and conditions also correspond.

This is the value of a disciplined analogy. It does not announce that two things are secretly the same. It says: Here is the mapping; here are the matching rules; here is the outcome we expect; here is how we would find out whether we're right.

An analogy becomes useful when it exposes a testable mechanism rather than merely sounding clever.

A comparison you can inspect

The next time somebody claims two organizations operate alike, ask three questions.

First, which operation are we comparing? Without a declared scope, the claim can expand or contract whenever a counterexample appears.

Second, do the actual routes and rules correspond? Compare who receives inputs, what those inputs mean, which transitions are permitted, and where authority sits. Matching job titles are not enough.

Third, what happens under corresponding conditions? Test more than the easiest case. Look for the input that makes superficially similar systems diverge.

The central result is simple: the structure and its behavior must both support the comparison.

In Part 6, we'll put the entire series to work. We'll investigate a system that seems to function on paper, trace what it actually does, identify a missing relationship, and see what changes when that relationship is repaired.