Vendor clouds and the copies of your floor

A robot that runs its heavy models in its vendor's cloud is, among other things, a camera that uploads. The perception model cannot judge a frame it has not received, so the frame travels to wherever the model lives. Over a shift, the vendor's cloud has seen everything the robot saw.

Call that a copy of the floor. It is not a metaphor. It is a continuous, time-stamped visual and operational record of the building, held by a company that is not the operator, under terms the operator probably did not negotiate line by line. This article is about how those copies come to exist, how a mixed fleet multiplies them, and what a facility pool does instead.

How the copies come to exist, and multiply

Nobody sets out to give a vendor a copy of the building. It happens as a consequence of architecture. The perception and decision models that make a modern robot useful are too large to run on the robot itself. The vendor has two places to put them: a cloud it operates, or a pool inside the customer's facility. The cloud is easier for the vendor, so it is the common choice.

Once the model is in the cloud, the feed must follow it. Frames go up, decisions come down. Captures of hard cases are kept, because they improve the model. Task logs accumulate, because they are useful for support. None of this is malicious. All of it means the vendor holds the floor.

Few buildings run one vendor's robots. A fulfillment center has mobile robots from one company, pick arms from another, and a humanoid trial from a third. A plant adds mobile manipulators to a floor that already has arms and vision from established suppliers. Each vendor with a cloud-served model takes its own copy.

The copies are not the same copy. Each vendor's robots see the floor from their own positions, keep their own captures, and log their own tasks. Each copy sits under a separate agreement with separate retention terms and a separate security posture the operator has to assess. The operator's view of its own building is now distributed across several companies, and the operator holds the least complete version.

That is the hidden cost of a mixed fleet when the models live elsewhere: not the integration work, which is visible, but the fragmentation of the floor's record into pieces the operator does not control.

The pool as the place where the heavy models run

A Czar Grid changes the architecture rather than the agreements. It is an inference pool inside the facility, in the building's own rack, serving every robot from any vendor over the facility's own network. The perception, decision, and language models that were too large for the robot run on the pool instead of in a distant cloud.

Because the models are inside, the frames stay inside. The robot sends a frame across the building and gets an answer back across the building. The vendor's cloud is not on the path. Captures saved for adaptation stay on the pool, and Substrate fine-tunes on them there. Task records and the decision record accumulate on the operator's hardware. The copy of the floor is the operator's own, and it is the only one.

The robots keep their on-board models for reflexes and fall back to them when the pool cannot answer in time. Safety stays on the machine as each vendor delivered it. The pool takes over the heavy lifting, not the stops.

Keeping the fleet software, losing the copies

Operators sometimes hear this as an instruction to abandon their vendors' fleet software. It is not. Fleet software dispatches, monitors, and maintains the fleet, and the site may well keep using it. On a connected Czar, the site declares a route to each vendor's fleet software, and the pool coordinates with it through that route.

What the route does not carry is the floor. Feeds, captures, weights, and records do not travel over it, because the pool does not export them and Local Bridge denies any route the site did not declare. The vendor keeps running its robots. It stops receiving the building. A connection is a decision, not a default explains how the declaration works.

Czar Chassis: the vendor's name, the building's data

Some vendors will prefer to ship the pool themselves, as part of their offer, so their customer receives one system. That is Czar Chassis. It is not a second machine. It is the same Grid, shipped under the vendor's name with the vendor's fleet, installed in the customer's building, with Element 31 providing sustainment and attestation underneath.

The data arrangement does not change. The pool is in the customer's rack. The feeds, captures, weights, and records are on the customer's hardware. The vendor has shipped a product that keeps its customer's floor in its customer's building, which is a stronger thing to sell than a cloud that quietly holds it. Czar Chassis describes the route for vendors and integrators.

What the operator gets back

The practical result is a single, complete record of the floor, held by the people who run the floor. One pool serves the mixed fleet. One record covers every robot's decisions. No vendor needs a copy to do its job, so no vendor has one. See Czar Grid for the pool itself and Camera feeds are the building's data for why the feed was worth keeping in the first place.