Adding capacity to a Grid without stopping the floor

A floor that has a pool comes to depend on it in the ordinary way: the robots do more, the stops are fewer, and the automation team stops thinking about it. Then the fleet grows, or a new vendor's machines arrive, or a line is added, and the record starts to show missed budgets at the busiest hour. The pool needs more room. The requirement is to add it without the floor noticing.

Capacity lives in the rack

The first reason this is tractable is that capacity is in the rack, not on the robots. Adding a node to a Czar Grid is an installation in the building's own rack, on the network the pool already uses. No robot is updated, reconfigured, or taken off the floor. The robots that were being served by the existing nodes continue to be served by them, within their budgets, while the work happens.

This is the practical difference between a pool and per-robot compute. Adding compute to a fleet of robots is a fleet operation, scheduled against each vendor. Adding compute to a pool is a rack operation, scheduled against the site.

A node earns its place

A new Czar does not simply plug in and start answering. It arrives sealed, with a signed, read-only software image, and before it joins the Grid it attests what it is running. Substrate admits it only when that attestation matches what the site expects. Its integration, sealing, and software load are on record, so the site can say where this node came from and what it carries from a record rather than a reassurance.

Once admitted, the new node takes its share of demand. Substrate spreads requests across the pool against each robot's budget, so the effect on the floor is that the tight-budget requests at the busiest hour are met more often, and the record of misses thins out.

The same path for updates

The same arrangement that lets a node be added lets a node be taken out. Every node is eventually updated, and the update arrives as a signed bundle: carried in by media on an air-gapped site, or downloaded by the customer from the portal and applied on a connected one. On a Grid, one node is removed from the pool, updated, re-attested, and admitted again while the others keep serving.

A one-node pool cannot do this. While a single Czar is updating, the robots run on their on-board models, which is safe but reduces what the floor can do. A Grid turns an update into a rack operation the floor does not see, which is one of the three reasons a site moves from one Czar to a Grid.

Posture does not change

Adding a node does not reopen the question of posture. If the site runs air-gapped, the new node attests over the site's own network and never has a path out. If the site runs connected only to the systems it already secures, the new node inherits the same declared routes and the same default-deny egress. Mixed estates, with some areas air-gapped and others connected, add nodes to each according to the posture already set for that area.

Nothing about growing the pool changes what leaves the building, which is still nothing. Feeds, captures, task records, adapted weights, and the record of every decision stay on the operator's hardware before and after.

What changes commercially

The subscription is for the configured Grid: hardware, platform license, and sustainment in one line, fixed for the term. Adding robots to a pool that is already configured does not move it. Adding a node is a change to the configuration, and it is worked through as one, with E31 Consulting and the operator's automation team, so that the site knows what it is subscribing to before the node arrives.

That is the right order. The record shows where the pool is short; sizing shows what would fix it; the configuration changes; the node is installed, attests, and joins; and the floor keeps working through all of it. For how to read the record that starts the process, see The record a pool keeps of every decision.