Skip to content
ELEMENT 31

Language models on the facility network

Most of what a facility knows is written for people. A language model on the pool lets robots act on it and lets people ask the floor questions, with no text leaving the building.

· 4 min read

IN SHORT

A language model on the facility network runs on the pool in the building's rack, reads the site's own documents through retrieval, and serves robots and the people who run them without any text leaving the site. It lets a robot act on a work order written for a person and explain what it did in plain words, with every exchange recorded.

Most of what a facility knows about itself is written down for people. Work orders, standard procedures, exception handling, the note taped to the door about the dock that floods. Robots cannot read any of it. A language model on the facility network is how they begin to, and how the people who run the floor begin to ask the floor questions in their own words.

Where the model runs

The language model runs on the pool in the building's rack, on a Czar for a small floor or a Czar Grid for the facility. It is served by Substrate like the perception and decision models, over the site's own network. A prompt from a robot or a person goes from the floor to the rack and back and no further.

That placement is the point. The text a floor would send to a language model is the most sensitive text the site has: what is being built, what is being shipped, what went wrong on which line. On an air-gapped site there is no path out; on a connected site the only connections are to systems the site already secures and declared. Either way the model is inside the walls.

Reading what was written for people

The first use is letting robots act on instructions that were never written for them. A work order says to stage the fragile items near the dock before the afternoon pickup. A robot's planner has no field for that. A language model on the pool reads the order, retrieves the site's definition of fragile and the location of the dock from the site's own documents, and turns the instruction into something the task layer can bound and the robot can carry out.

Retrieval is what makes the model local. The pool holds the site's documents and the model reads from them, so its answers are about this site's procedures rather than a general idea of a warehouse. The documents stay on the pool, as does the record of which ones were read for which answer.

Explaining what the robot did

The second use runs the other way. When a robot does something a person did not expect, the person wants to know why. The pool holds the record of what the robot was shown and what it was told, and the language model can render that record as a plain explanation: the robot took the alternate route because the usual aisle was blocked and the task permitted it.

This matters for safety officers, who need to understand an incident quickly, and for automation teams, who are tuning tasks and want to know which rule a robot was following. The explanation is drawn from the record on the pool, not from the model's imagination, and the record itself remains available underneath it.

Serving people on the same pool

Once a language model is on the facility network, people start to use it directly. A supervisor asks which robots hesitated on the inbound dock this morning. An integrator asks what version of a task was running when a robot paused. A new operator asks what the procedure is for a damaged pallet. The answers come from the site's own record and documents, on the site's own hardware.

This is covered in more depth in A pool that serves people as well as robots. The short version is that a pool built to serve robots turns out to be the right place for the floor's institutional knowledge, because that is where the record already is.

What the model is and is not

Language requests have a looser latency budget than perception. A robot mid-step cannot wait for a paragraph; a supervisor at a terminal can. Substrate schedules accordingly, serving tight-budget perception and decision requests first and letting language requests fill the slack. A language model on the pool therefore adds capability without competing with the robots for the moments that matter.

The language model does not control the robots. It reads, interprets, and explains. What a robot does is bounded by site tasks that were authored, versioned, and approved by named roles, and the robot's stops, speed limits, and motion limits stay on the machine as its vendor built them. A language model that misreads an order produces a task that is still bounded and a robot that is still safe. Every prompt and every answer is in the record, which is where a site goes to see how the model is being used.

Questions this raises

Why not use a language model from a vendor's cloud?
Because the prompts carry the site's work orders, procedures, and descriptions of what is on the floor, and many sites will not send those out. On the pool the model runs inside the building, and on an air-gapped site there is no path out at all.
Does the language model control the robots?
No. It interprets instructions and documents and explains actions. Decisions are bounded by approved site tasks, and the robot's safety functions stay on the machine. The language model is a reader and an explainer, not a controller.
How does the model know this site's procedures?
Through retrieval over the site's own documents, held on the pool, and through adaptation on the site's own records where the site chooses. Both happen on the operator's hardware and nothing leaves.

KEEP READING