How a proposal for a Grid is built

A proposal for a Grid does not begin with a model number. It begins with a walk across the floor the pool will serve: which robots are on it, which vendors made them, what they need from a pool that they cannot carry on board, and what each one does when the pool is silent. Everything in the proposal follows from those answers. This article describes the sequence so a site knows what to prepare and what it will receive.

Listing the fleets and what they need

The first document is a fleet list. For each fleet on the floor, and each fleet planned for it, the list records the vendor, the kind of machine, and the models it will ask the pool for. Mobile robots in a warehouse may need perception models for aisles that change daily. Pick arms may need decision models for items the on-board model has never seen. Humanoids on a plant floor may need language models to take instructions from a supervisor. Cranes and automated vehicles at a terminal may need inspection perception over feeds that must stay on site.

The list also records what each robot keeps on board. Stops, speed limits, reflexes, and motion limits stay on the machine as its vendor set them. The proposal does not touch these, and it says so plainly, because the safety officer will ask.

Setting the latency budgets

For each model a robot will ask for, the proposal records the latency that robot can tolerate before it falls back to its own on-board model. This is not a figure Element 31 supplies. It comes from the robot vendor and the site's own experience of the floor. A mobile robot approaching an intersection has a different budget from an arm deciding how to grip a new item, and both differ from a humanoid waiting for a spoken instruction.

Substrate enforces each robot's budget inside the pool. The proposal captures those budgets so the Grid can be configured to meet them for the whole floor at once, not just for the first fleet installed. A proposal that skipped this step would produce a pool that works in the pilot and struggles when the second vendor arrives.

Choosing the posture

Posture is a decision per site, and the proposal is where it is made. An air-gapped Grid has no path out; updates arrive as signed bundles carried in on media. A connected Grid reaches only the systems the site already secures and has declared: the robot vendors' fleet software, the warehouse system, the PLCs, and nothing else. Local Bridge holds that list and denies everything not on it.

The proposal records which systems the pool may reach and who at the site authorized each one. On a mixed estate, where one building is air-gapped and another is connected, each facility's proposal records its own posture. The decision is written down because a connection is a decision, not a default, and the record should show who made it.

Naming the roles

Agency Studio requires that site tasks be approved by named roles before they run. The proposal lists those roles: who may author a task, who may bound it with zones and speeds and stops, who may approve it for the floor, and who may read the record afterward. These are the operator's people, whether the Grid arrives under Facility Direct or under a vendor's name through Czar Chassis.

Naming roles at proposal time avoids a common failure, where the pool is installed and the first task sits unapproved because nobody was given the authority. The use cases page shows the kinds of tasks those roles will be approving.

Configuring the Grid and setting the route

With fleets, models, budgets, posture, and roles on paper, the Grid is configured: the number of Czar nodes for the facility's rack, joined into one pool. One Czar serves a small floor. Several joined serve a whole facility. The configured Grid is what the subscription names.

The last decision is the route. Under Facility Direct the building subscribes. Under Czar Chassis a vendor or integrator ships the Grid under their own name with their fleet, and Element 31 provides sustainment and attestation underneath. The proposal states the route, and the result is one line: hardware, platform license, and sustainment, fixed for the term. The How to buy page describes both routes, and E31 Consulting engineers are the ones who walk the floor and assemble the document described here.