Adapting models on the floor's own captures
A general model has never seen your floor. Substrate fine-tunes the shared model on captures taken in the building, on the pool, evaluates the result, and keeps the weights where the captures were taken.
· 4 min read
IN SHORT
Substrate adapts the models served from a Czar Grid by fine-tuning them on captures taken on the site's own floor, on the pool itself. The adapted weights stay on the operator's hardware, each adaptation is evaluated and recorded, and every robot on the pool, from any vendor, is served by the result. Nothing, including the captures, leaves the building.
Every floor is peculiar. The lighting is different at the dock than in the back aisles. The totes are a color the catalog does not list. The floor markings were repainted in a hurry and the new ones do not quite match the old. The items are whatever the business sells this season, in whatever packaging the suppliers chose. A general model trained on a general warehouse has never seen any of it, and it shows every time a robot hesitates over something a person would not glance at twice.
The fix is well understood: fine-tune the model on data from this floor. The reason it rarely happens is where the data would have to go. A facility pool removes that reason.
The captures are already there
A floor with robots on it produces captures all day. A pick arm meets an item it does not recognize, a person resolves it, and the image and the grasp are a capture. A mobile robot stops at an obstacle, a supervisor waves it through, and that is a capture. A humanoid asks for help and a person guides it, and the whole episode is a capture.
On a floor with a Czar Grid, those captures land on the operator's hardware and stay there. They are not sent to a vendor's cloud for labeling and they do not sit in a bucket somewhere waiting for a data scientist. They are on the rack that serves the fleet, which is also the rack that can learn from them.
Adaptation on the pool
Substrate, the serving system on the Grid, includes adaptation: fine-tuning the shared models on the site's own captures, run on the pool itself. The same nodes that serve perception and decisions to the robots are the nodes that adapt the model to the floor. Nothing leaves. The captures do not leave, the training does not leave, and the adapted weights do not leave.
The result is a model that knows this floor. It recognizes the tote color, reads the new markings, and has seen the items that actually move here. Every robot on the pool, from any vendor, is served by it. The mobile robots, the pick arms, and the humanoids all ask the same adapted model and benefit from the same captures, however many vendors are on the floor.
Evaluation and the record
Adaptation without evaluation is guesswork. Substrate evaluates each adapted model against the site's own tests before it serves, and the evaluation goes on the record with the adaptation itself. The record shows which captures went in, what the evaluation found, and when the adapted model began serving the fleet.
That gives the site control over its own model in a way a vendor update never does. An engineer can see exactly what the model was taught, read whether the evaluation justified serving it, and trace any later change in the fleet's behavior back to a specific adaptation. If an adaptation did not earn its place, the record shows that too. It is a record a person can read, and it is kept on site.
What adaptation does not change
Adaptation changes the shared model in the rack. It does not change the vendors' on-board models, which each robot keeps for reflexes and for fallback and which each vendor maintains on its own schedule. It does not change the safety envelope on any robot. Stops, speed limits, reflexes, and motion limits stay on the machine as the vendor shipped them, whatever the pool has learned.
It also does not change posture. An air-gapped site adapts on its own captures with no path out, as it does everything else. A connected site adapts the same way, because adaptation never needed a connection. The captures and the weights are the operator's in both cases.
Why on site is the only place that works
A floor's captures are among the most revealing data it produces. They show the products, the layout, the people, and the mistakes. Most sites, asked plainly, would rather not send that anywhere, which is why most floors never fine-tune and keep running a general model that hesitates at their own totes.
Adaptation on the pool is the arrangement under which a site can say yes. The data stays, the training stays, the model stays, and the fleet gets better at the floor it works on. For the pick-cell version of this story, see pick arms and the unfamiliar item, and for what it means across vendors, a new item learned once, not once per vendor.
Questions this raises
- What counts as a capture?
- A capture is a moment from the floor's own work that the site keeps: what a robot saw, what it was asked, and what happened. Exceptions resolved by a person and interventions are especially useful captures, and all of them stay on the operator's hardware.
- How does the site know an adaptation helped?
- Each adaptation is evaluated against the site's own tests, and the evaluation goes on the record alongside the captures that went in. The site can read what changed and how the adapted model performed before it served the fleet.
- Does adaptation touch the vendors' on-board models?
- No. Adaptation changes the shared model served from the pool. Each robot keeps its own on-board model for reflexes and fallback, maintained by its vendor on the vendor's schedule.
KEEP READING