Why safety stays on the robot
A facility pool serves perception and decisions. It never serves the stop. Here is why that line is drawn where it is, and what it means for the vendor, the safety officer, and the floor.
· 4 min read
IN SHORT
Safety stays on the robot because the safety case belongs to the machine and the vendor who built it, and a network service cannot be part of it. A Czar Grid serves perception and decisions; stops, speed limits, reflexes, and motion limits remain on board as the vendor shipped them. A pool that fails or answers late leaves a robot that stops, not one that guesses.
Every robot on a working floor has a line inside it that nothing on the other side of a network is allowed to cross. On one side are the stops, the speed limits, the reflexes, and the motion limits, built and validated by the vendor as a single piece. On the other side is everything the robot would like to know but can survive without. Element 31 builds the inference pool for the second side only, and keeps it there on purpose.
That sentence does a lot of work, so it is worth being precise about what it means and why the line is drawn where it is.
What the pool is allowed to do
A Czar Grid serves perception, decision, and language models to every robot in the building. It can tell a robot what the object in front of it is, where a grasp point lies, whether an aisle is clear, what a supervisor meant by an instruction, and what the next step of a task should be. These are answers to questions. They are useful, and they are the kind of answer that benefits from a model too large to carry.
What the pool does with those answers is send them back to the robot. That is the end of the pool's involvement. The robot's own controller decides whether and how to act, and it does so within the envelope the vendor shipped. The pool proposes; the robot disposes.
What the pool is never allowed to do
The pool never holds the stop. It never sets a speed limit, never relaxes a motion limit, never participates in the reflex loop that keeps a humanoid upright or keeps a mobile robot from rolling into a person. None of that logic runs on the rack, and none of it waits for the rack.
This is not a configuration option that a site could switch the other way. It is the shape of the product. A network service that could reach the stop would be inside the safety case, and the safety case is the vendor's, built around the machine. Putting a shared pool inside it would mean the vendor's safety argument depends on a rack in a customer's building, which no vendor should accept and no safety officer should approve.
What happens when the pool is late or gone
Because the robot's safety does not depend on the pool, the failure modes are tame. Substrate holds a latency budget for each robot's question. If the budget passes without an answer, the robot treats it as no answer. It falls back to its on-board model and does what that model can do alone, or it stops.
A pool that fails leaves a robot that stops, not one that guesses. There is no state in which a robot is partway through acting on an answer that never arrived, and no state in which the robot keeps moving on a stale answer because the better one is late. The behavior of a robot without the pool is the behavior the vendor already shipped and the site already approved. Adding the pool adds capability on top of that behavior; it does not change the floor underneath it.
Why this matters for a mixed floor
The line is also what lets vendors share a pool at all. If the pool held any part of safety, the safety case of a mobile robot from one vendor would be tangled with the safety case of a pick arm from another, through a rack neither of them built. Because the pool holds none of it, each vendor's safety case stays its own. The vendors can share perception, share decisions, share a record, and share a model adapted to the building, and still answer for their own machines.
That is why a robot vendor loses nothing when a site adds a pool, and why a vendor can ship the same Grid under its own name as Czar Chassis without rewriting its safety argument. The pool is beside the robot, not inside it.
What the record shows
The record kept on the Grid reflects the same line. For every question a robot asked, the record shows what the pool answered, when, and whether the robot acted on the answer or fell back. When a safety officer reviews an event, the record separates the two cleanly: here is what the pool proposed, and here is what the robot's own controller did. It is a record a person can read, kept on site, and it never shows the pool doing something the pool cannot do.
For the fallback behavior in more detail, see a robot that stops, not one that guesses, and for the broader design, the technology overview.
Questions this raises
- Could the pool be configured to override a robot's stop?
- No. The Grid serves perception and decision models over the network; it has no role in the robot's safety logic. Stops, speed limits, reflexes, and motion limits remain on the machine as the vendor shipped them.
- What does the safety officer need to review when a site adds a pool?
- The safety officer should confirm that the vendor's safety envelope is unchanged and that the robot's behavior when the pool is absent is the behavior already approved for that robot. The pool adds answers; it does not add a new path to motion.
- What is the difference between a pool answer and a robot decision?
- A pool answer is a proposal: what the object is, where to grasp, which way to go. The robot decision is what the robot's own controller does with that proposal within its limits. The controller can decline, slow, or stop regardless of what the pool said.
KEEP READING