Spatial Structure and Locality

In the previous post, we introduced processes: concurrent behaviors that communicate and synchronize.

But we treated all processes as if they exist in a flat space — equally accessible, equally connected.

Real systems have structure. Things are somewhere.

Where Things Are Matters

Consider a distributed version of our Asset System.

Assets are held in different locations — warehouses, vaults, digital registries. Agents operate from different offices or jurisdictions. Some processes run on-site, others run in the cloud.

The structure of where things are affects what they can do:

• An agent can only inspect assets it has local access to
• A transfer between two locations requires coordination across a boundary
• A process inside a secure enclave cannot freely communicate with the outside

Space is not just metadata. It shapes the system's behavior.

Containment and Nesting

One of the most fundamental spatial relationships is containment.

A vault contains assets. An organization contains departments. A server contains services. A region contains locations.

Containment creates boundaries: what is inside a container is separated from what is outside. Crossing a boundary requires explicit action — moving, sending, or granting access.

In Spine, containment is not implicit. It is part of the system's structure, modeled explicitly.

Bigraphs: A Foundation for Spatial Structure

The idea of combining spatial nesting with behavioral linking comes from bigraph theory.

A bigraph has two independent structures:

• A place graph — describes nesting and containment: what is inside what
• A link graph — describes connectivity: what can communicate with what

These two structures are orthogonal. An agent inside a container may have communication links to agents outside it. Two agents in the same location may have no direct connection.

This separation is powerful: it allows spatial structure and communication topology to vary independently.

The Asset System in Space

Let's extend our example.

We model a system with multiple locations:

• A warehouse containing physical assets
• A registry containing ownership records
• An office containing agents who initiate transfers

Each location is a container. Facts within a container are local to it: the warehouse knows what physical assets it holds, the registry knows who owns what.

A transfer involves coordination: the registry updates ownership while the warehouse prepares the asset for movement. These are processes in different locations, communicating across a boundary.

Locality and Scope

Spatial structure introduces a natural notion of scope.

Facts inside a container are local by default. They are not visible outside unless explicitly shared. A process inside a region can access local facts, but reaching across a boundary requires communication.

This is different from the context-based scoping we introduced earlier. Context determines which rules apply. Locality determines what is accessible.

Both shape the system, but they operate on different dimensions.

Movement and Reconfiguration

In static systems, structure is fixed. But real systems change shape.

An asset moves from one warehouse to another. An agent moves between offices. A service migrates from one server to another.

These are not just changes in facts — they are changes in spatial structure. The nesting of things inside containers changes. The boundaries shift.

In Spine, movement is an explicit operation that restructures the spatial layout of the system. The type system tracks what has moved, ensuring that references remain valid and that invariants about containment are preserved.

Processes in Space

Spatial structure interacts naturally with processes.

A process operates somewhere. Its location determines what it can directly access and who it can communicate with.

Two processes in the same container may share local state. Two processes in different containers must communicate through explicit channels that cross the boundary.

This gives the system a richer notion of concurrency: not just multiple behaviors happening simultaneously, but multiple behaviors happening in different places, coordinating across spatial structure.

Adjacency and Proximity

Containment is not the only spatial relationship.

Agents may be adjacent — in neighboring locations, able to interact directly. Locations may have proximity relationships that affect what actions are possible.

For example: a physical transfer may only be possible between adjacent warehouses. An emergency protocol may require a local responder — someone in the same region.

These relationships are part of the spatial model, not encoded as ad-hoc conditions.

Connecting to Invariants

Spatial structure creates new kinds of invariants:

• An asset must be in exactly one location at any time
• A secure container must not have uncontrolled communication links to the outside
• Certain agents must remain co-located with the assets they manage

These are spatial invariants — properties about the structure of containment and connectivity, not just about the values of facts.

Because spatial structure is explicit in Spine, these invariants can be stated, checked, and enforced alongside the logical invariants we introduced earlier.

A Subtle Shift

With spatial structure in place, the system gains its final geometric dimension.

We no longer describe just what is true, how it changes, and who acts. We describe where everything is — and how the structure of space shapes behavior, access, and interaction.

This extends the earlier discussion of time and uncertainty into a full picture: systems that evolve in time, vary across locations, support concurrent processes, and maintain spatial invariants throughout.

Looking Ahead

We have now covered the major dimensions of Spine systems: facts, rules, effects, invariants, context, time, uncertainty, processes, and space.

In the next post, we will add another crucial dimension: resource tracking — the idea that some facts are consumed on use, and that the type system can enforce this discipline at compile time.