[2/6] The Structure of Things - The Connections Have Rules

The Structure of Things — Part 2 of 6

A message can arrive at the correct building and still never reach the person who can act on it. A computer can receive a perfectly valid piece of data and still have no legitimate reason to execute it as a command. A department can possess the authority to make a decision but lack any route by which the relevant evidence reaches its desk.

We often describe all three problems with the same vague phrase: a communication breakdown. That phrase hides more than it explains.

To analyze what actually happened, we need to distinguish the things involved, the places where they can interact, the connections between them, and the rules governing those connections.

In Universal Structuralism, those have names: nodes, interfaces, pipes, and wires.

Start with the node

A node is a constituent of the system under examination. It could be a sensor, a software service, an employee, a review board, or an entire organization. The word doesn't tell us how large or important the constituent is. It simply gives us a way to refer to something that can participate in a larger arrangement.

A node has capacities and limitations. A sensor can produce a measurement. A reviewer can examine a case. A payment processor can evaluate a transaction. Those capabilities matter, but none of them tells us how the node is connected to its neighbors.

That requires an interface: the defined point at which a node can send, receive, or otherwise participate in an interaction. Interfaces aren't necessarily screens, sockets, or physical ports. An agency's intake procedure is an interface. So is a software function's argument list. So is the formal process by which a committee accepts a motion.

An interface is where a relationship becomes operational.

A pipe is the route, not the label

A pipe is an actual connection through which information or another defined input can pass between interfaces. Without a pipe, two nodes may be listed next to each other on an organizational chart, or drawn side by side in a software diagram, but there is no established route for a transfer between them.

This gives us the first operating rule:

NO PIPE = NO ENTRY.

It means that a node cannot receive an input through a particular legitimate route unless that route exists. A complaint that never reaches the review process is not made consequential by the mere existence of a review department. A software feature that has no connection to the system's execution path is not activated by appearing in the user interface.

The rule is about the structure being examined. It doesn't mean that unauthorized intrusion, physical interference, or undocumented behavior is impossible. Those are additional interactions to discover and account for, not excuses to pretend a missing route exists.

But a pipe alone is not enough. We also need to know what the pipe is supposed to carry.

Type the pipe

Imagine a building-control system. One node reads a temperature sensor and produces a number. Another controls a door lock and accepts a command such as lock or unlock.

Both devices might communicate over the same general kind of network. That doesn't make a temperature reading an acceptable door command. An input's meaning and permitted use depend on the receiving interface's contract.

In our vocabulary, the wire describes the type or metadata associated with a pipe: what sort of data may pass, what shape it has, and what the receiving interface is equipped to interpret. It is not a second physical cable. A pipe carries the information; a wire tells the structure what that information is allowed to be.

TYPE THE PIPE.

Consider the difference between these messages:

• The review board received the report.
• The review board approved the recommendation.

The first describes receipt of information. The second records an authorized decision. A poorly specified process might treat the first event as though it implies the second. A typed process keeps them distinct, even if both arrive as text in a database.

This leads to another design rule:

NO WIRE = NO EXECUTION.

In a structural system built to enforce this rule, an operation does not execute merely because some bytes—or a plausible-looking document—arrived. The input must have a declared, compatible type, and the receiving interface must know how to handle it. Unknown or incompatible inputs should be rejected rather than guessed into action.

This is a rule for how we want systems to behave, not a claim that every existing institution or piece of software already behaves that way.

Compatibility isn't permission

There is a further distinction worth keeping intact. A valid input type is not the same as authorization.

Suppose a payment system accepts a correctly formatted refund request. The request may satisfy every technical requirement of the interface and still come from someone without permission to issue refunds. The information is intelligible. The operation remains unauthorized.

We therefore have at least three separate questions. Is there a route? Is the input compatible with that route? Is the sender—or the operation—authorized under the applicable rules?

Collapsing those questions into one is a reliable way to manufacture ambiguity. A system that treats the ability to send a message as permission to command its recipient has confused connectivity with authority. We'll examine authority in detail in Part 4.

For now, the crucial point is that a connection establishes a possibility of transfer, not an automatic right to execute.

An inbox is not a process

Return to the fictional complaint agency from Part 1. Suppose the resident's report reaches an inbox. That establishes a pipe from the submission interface to the inbox. It doesn't establish a pipe to the investigator, much less to the decision-making body.

Even when a report reaches the investigator, the process may still lack a declared distinction between an allegation, an evidentiary finding, a recommendation, and an adopted decision. Those are different kinds of records with different consequences. A structure that handles them as undifferentiated documents makes it difficult to tell which transitions actually occurred.

A useful audit can now be more precise than communication failed. The investigator had no incoming route. Or the report arrived in a format the interface couldn't process. Or the finding reached the decision-maker but lacked the authority required to change the decision. Each diagnosis suggests a different repair.

Notice how much confusion disappears once the connections are described accurately.

Draw the system that actually runs

You don't have to adopt specialized software to use this method. Begin with a simple sketch. Give each participating component a name. Mark its interfaces. Draw only connections that can actually carry a defined input. Then annotate what each connection carries and what the receiving interface does with it.

If you cannot say what passes through a line, the line is not yet a useful explanation. If you cannot identify the receiver, the supposed communication path remains unverified. If you cannot distinguish a request from an instruction, you've found an ambiguity that may matter later.

The payoff is practical: you can stop arguing over whether two things are vaguely connected and determine precisely what their connection permits.

Nodes tell us what participates. Interfaces tell us where participation is possible. Pipes tell us what is connected. Wires tell us what may pass through those connections. Authorization governs whether a compatible interaction is allowed to have a particular effect.

Those distinctions give us enough structure to build something larger. In Part 3, we'll connect individual nodes into a functioning assembly—and see why the capabilities of that assembly can't be read directly from the capacities of its parts.