Hardware, platform, and sustainment in one line
Most facility compute arrives as three invoices from three parties. A Grid arrives as one line, and that shape changes who is accountable when the pool is slow, out of date, or in doubt.
· 4 min read
IN SHORT
A Grid is sold as one subscription line because the hardware, the serving software, and the sustainment of both are inseparable in practice. A sealed appliance that attests its own image cannot have its software and hardware supported by different parties. Putting all three in one line, fixed for the term, gives the facility one accountable party and a figure that does not move as the floor grows.
Most compute that arrives in a facility arrives as three relationships. A hardware supplier ships the boxes and warrants them. A software supplier licenses what runs on them and pushes updates on its own schedule. A third party, or the site's own staff, holds the support contract and is the one who gets the call when something stops working. Each party is responsible for its piece, and the seams between the pieces are where the facility's problems live.
A Grid is sold differently. The subscription for the configured Grid is one line that covers hardware, platform license, and sustainment together, fixed for the term. This is not a packaging convenience. It follows from what the appliance is.
Why a sealed appliance cannot be split
A Czar node ships with a sealed enclosure and a sealed, signed, read-only software image. Before it joins a Grid or accepts a task, it attests what it is running. Its integration, sealing, and software load are recorded together as the provenance of that node.
If the hardware and the software were supplied by different parties, that attestation would have no single owner. The hardware supplier could not vouch for the image; the software supplier could not vouch for the enclosure. The provenance record would be two half-records from two companies, and the site would be back to reassurance instead of evidence. One line exists so that the party that integrated the node is the party that signed its image and will sign every update to it.
Sustainment belongs in the same line for the same reason. A signed update is only meaningful if the signer is the one who sealed the original image. A remote session is only safe if the party on the other end is the one whose attestation the node already trusts. Pulling sustainment out into a separate contract would break the chain the appliance depends on.
What the facility gains from a single accountable party
When the pool is slow, the operator does not have to decide whether it is a hardware problem, a serving problem, or a configuration problem before deciding whom to call. There is one party. When a robot vendor reports that its machines are falling back to on-board models more often than expected, the same party answers for the pool's latency budgets and for the nodes that serve them.
This matters most for the safety officer and the automation lead, who do not have time to referee between suppliers. A pool that fails leaves a robot that stops, not one that guesses, so the floor is safe during an outage. But the outage still has to be resolved, and resolution is faster when accountability is not shared.
The customer portal reflects this. Support, billing, signed update downloads, and remote sessions live in one place for the one subscription. The appliance never connects to the portal; the operator goes there, and what the operator finds is a single relationship rather than a directory of vendors. The Czar page describes the node these properties belong to.
What it means for the budget
A line fixed for the term behaves like a cost of the building, in the way power, the network, and the rack already do. It can be planned against the floor's output rather than against a forecast of how many inferences the robots will request. More robots on the pool do not move the line, so a decision to add a vendor's pick arms or a few humanoids is a decision about the floor, not a renegotiation of the compute.
The alternative, where hardware is capitalized, software is metered, and support is renewed on its own calendar on different paper, produces three numbers that move independently and a budget meeting every time one of them does. One line produces one figure that stays put.
Both routes carry the same line
Under Facility Direct the building holds the subscription. Under Czar Chassis the robot vendor or integrator holds it and ships the Grid under their own name, with Element 31 providing sustainment and attestation underneath. In either case the structure is identical: hardware, platform license, and sustainment, one line, fixed for the term.
The vendor route is sometimes described as a bundle, but it is more precise to say the line is already a bundle and the vendor is adding their fleet to it. The facility sees one system either way. The How to buy page lays out how each route is held, and the pricing page describes the subscription itself.
Questions this raises
- Why not buy the hardware and license the software separately?
- Because the hardware and the image are sealed together. The node attests that specific image before it joins a Grid, and the provenance record covers integration, sealing, and software load as one event. Separating them would mean separating the thing from the proof of what it is.
- Does one line make it harder to see what each part is worth?
- The proposal describes the configured Grid in full: the nodes, the floor they serve, the posture, and the sustainment that runs for the term. What the single line removes is the possibility that one part lapses while the others continue.
- Can the facility's own IT team take over sustainment to lower the line?
- No. Sustainment is part of what a Czar is, not an optional service on top. The site's team operates the pool, approves tasks, applies updates, and reads the record, but the signed image and the attestation chain come from Element 31 for the whole term.
KEEP READING