The shared world model is not a map

A fleet working a floor has to agree about the floor. Not about its geometry — that is a map, and maps are a solved problem — but about its current state: which bays are occupied, which lanes are passable, where the pallet that appeared an hour ago is sitting, which stretch of aisle a machine has claimed for the next leg of its route, and what each machine intends to do next. That agreement is a distinct component of the architecture, and it is worth naming precisely. It is the shared world model.

Stated plainly, it is a current, common representation of the space the machines work in. It carries occupancy and traversability. It carries the fixed infrastructure that rarely moves and the movable things that constantly do, along with where those things are going. It carries the regions that are claimed and by whom. And it carries the state of the machines themselves — what each is doing, what it has committed to, and what it is still capable of.

Two things it is not. It is not a map, because a map is authored once and describes what will still be true next year. And it is not the union of every robot's local state, because local state is private, partial, and — from any other machine's point of view — already stale.

Independent beliefs become physical conflicts

The tempting design is to skip the shared structure entirely. Every machine already builds a picture from its own sensors, so let each act on what it knows and let the interactions resolve themselves. This works with two machines in a large space and degrades from there.

What it produces at scale is familiar. Deadlock, when two machines each yield to the other's inferred intent and neither proceeds. Thrash, when each replans in response to the other's replan and the pair oscillates in a corridor. Duplicated work, when two machines are dispatched against the same task because neither knew the other had taken it, or when three of them independently re-observe the same region because none of them can benefit from what the others already saw.

The deeper problem is where disagreements get settled. In a software system, two services with inconsistent views of shared state produce a wrong answer that someone reconciles afterward. On a floor, the reconciliation is physical: a blocked corridor, a near-miss, an emergency stop, a dropped load. Every unresolved difference of belief between machines eventually presents itself as an event involving mass and momentum. That is the reason the shared structure has to exist as a designed component rather than an emergent side effect of a messaging layer.

One structure, several consistency requirements

Here is where the engineering gets genuinely hard, and it is not the part most designs anticipate. The shared world model has several classes of consumer, and they want incompatible guarantees from the same structure.

Facts relevant to collision in the next moment need freshness above everything. A slightly imprecise obstacle position available now is worth more than a precise one that arrives after the machine has passed the decision point. Correctness here is defined by timeliness, and any protocol that trades latency for agreement is trading away the property that mattered.

Claims on space need the opposite. A claim is only meaningful if it is exclusive, so two machines must never both believe they hold the same aisle for the same interval. That requires agreement in the strict sense, with all the cost that agreement carries, and it is worth paying because a fast claim that is not exclusive is not a claim at all.

The long-lived layout sits at the other end. A rack that moved this morning can propagate through the fleet over a comfortable interval without anything going wrong, and forcing that traffic through a strong protocol wastes budget the urgent classes need.

One consistency model applied to the whole structure therefore fails in one of two directions: it is too slow for the parts that must be fresh, or too weak for the parts that must be agreed. The design consequence is that the world model has to be partitioned by guarantee rather than by data type — which is uncomfortable, because the same physical object routinely appears in more than one partition, as an obstacle to avoid this second and as a fixture to remember tomorrow.

Reconciling views that disagree

Nothing observes the facility directly. The world model is assembled from partial views produced by different machines with different sensors, from different angles, at different moments, and those views disagree constantly. One machine saw the lane clear on its last pass. Another, approaching from the far end with a different sensing modality, reports an obstruction where the first saw nothing. Both reports can be honest and both can be current.

Taking the newest observation is not a fusion policy, it is a coin flip with extra steps, because the newest observation may come from the worse vantage point or the less suitable sensor. Averaging is worse — the average of "clear" and "blocked" describes no world that exists. Reconciliation has to account for what each sensor is good at, what each viewpoint could actually see, and when each observation was taken, which is why agreement about time is a precondition for this entire structure rather than a detail beneath it.

And when reconciliation cannot resolve a disagreement, the world model has to say so. Exposing uncertainty is not a weaker product than exposing a single confident value; it is the only honest one. A consumer handed a confident answer will plan against it at full speed. A consumer told that a region was clear on last observation, from a poor angle, some time ago, can slow down, route wide, or go look. Uncertainty that reaches the planner is information. Uncertainty that gets flattened before it leaves the world model is a latent fault.

Absence and expiry are first-class

The same logic drives the treatment of age. An entry that is wrong is worse than an entry that is missing, and the asymmetry is not close. A missing entry produces caution, a slower approach, an extra observation. A wrong entry produces confident action into a space that does not match the belief.

So a representation that can only say "occupied" or "clear" is underspecified. It needs to distinguish a region observed clear from a region never observed, and both from a region that was observed clear long enough ago that the observation has expired. Every entry carries when it was seen and when it stops being trustworthy, and expiry is a property of the structure rather than a background job that tidies up on a timer. Data that ages out has to age out visibly, in a way consumers can reason about, because the transition from trusted to expired is exactly the moment behavior should change.

Why it lands on the facility plane

Placement follows from what the structure is. It is shared state, so it does not belong to any one machine — and in the environments fleets actually work, the machines are not reliably reachable from one another anyway, with steel, distance, and interference between them.

It also cannot sit in a remote region. This structure is read and written continuously with a timing requirement attached, so every access would carry a round trip and inherit a failure mode nobody at the site controls. The structure would become unavailable precisely when the uplink is worst, which in most facilities is when the facility is busiest.

That leaves the site itself: one hop on the facility's own switches, inside the boundary, under local authority, scoped to exactly the space the model describes. The shared world model is not incidentally hosted on the facility plane. It is one of the reasons the facility plane exists.

What is not solved

Two problems here are open, and are named as such on the architecture page. The first is scale under a worst-case bound. Maintaining this structure for a handful of machines is tractable; doing it for a large mixed fleet while keeping the worst-served machine inside its timing bound, rather than the average machine, is unsolved work.

The second is heterogeneity. A real facility runs arms, mobile robots, and fixed automation with different capabilities, different footprints, and different failure modes. A representation general enough to coordinate all of them tends to flatten away the specifics that made each machine worth deploying. Finding one that does not is still ahead of us, and we would rather say so than describe a common schema as if generality were free.