Questions to ask any facility AI vendor
Before a facility signs for compute that will serve its robots, there are things to ask every vendor, Element 31 included: where the data goes, who holds safety, and what the bill does as the floor grows.
· 4 min read
IN SHORT
Ask any facility AI vendor where the feeds and captures go, whether safety stays on the robot, what a robot does when the compute cannot answer in time, whether the pool serves other vendors' robots, how the vendor proves what the hardware runs and where it came from, who reads the record, and whether the bill moves when robots are added. Hold Element 31 to the same list.
A facility choosing compute for its robots is choosing where its feeds go, who holds its safety case, and what its bill does as the floor grows. These are not technical niceties. They are the operating terms of the building for as long as the robots run. The list below is what an automation lead, a safety officer, and a procurement owner should put to every vendor at the table, Element 31 included. Each entry gives the question to ask and what a good answer sounds like.
Where the feeds and the captures go
Ask the vendor to state what leaves the building. Camera feeds, captures from the floor, task records, adapted model weights, and the record of each decision are the site's most sensitive material. A vendor whose compute is in a distant cloud is carrying all of it out, and a vendor who says the data is anonymized or encrypted in transit is still carrying it out.
A good answer is short. Nothing leaves. The pool is in the building's rack, serves over the facility's own network, and keeps every capture and every record on the operator's hardware. If the vendor needs a connection out for anything other than a customer-initiated update or session, ask what for and who authorized it.
Who holds safety, and what the robot does on a miss
Ask whether the robot's stops, speed limits, reflexes, and motion limits remain on the robot as its vendor set them, or whether any of them now depend on the vendor's compute. A pool that serves perception and decisions is one thing. A pool that the robot must consult before it may stop is a different thing, and the safety officer should refuse it.
A good answer is that safety stays on the robot. The pool serves perception, decisions, and language; the machine keeps its own reflexes. The vendor should be able to say this without qualification.
Then ask what the robot does when the compute is slow, busy, or down. Every floor will have those moments. A vendor who has not thought about this will describe the happy path and go quiet.
A good answer is that each robot keeps an on-board model for reflexes and falls back to it when the pool misses the robot's budget, and that a failed pool leaves a robot that stops rather than one that guesses. Ask to see where each robot's latency budget is set and who set it.
Whether the pool serves other vendors' robots
Ask whether the compute will serve a second vendor's humanoids, a third vendor's pick arms, and whatever arrives after that, on the same terms as the first vendor's fleet. A floor with more than one vendor on it needs one pool, not one per vendor.
A good answer is that the pool serves every robot in the building from any vendor, each under its own latency budget. If the vendor ships the pool under its own name, ask whether the agreement preserves that neutrality or quietly limits it.
How the hardware is attested and who reads the record
Ask how the vendor can show, from a record rather than a reassurance, what each node is running and where it was integrated, sealed, and loaded. Ask whether a node proves its image before it joins the pool or accepts a task.
A good answer is a sealed enclosure, a sealed and signed read-only image, attestation before joining or accepting work, and a provenance record the site can read. Ask to read it. A vendor who describes a supply chain instead of showing a record has answered a different question.
Next, ask who may author a task for the floor, who bounds it with zones and speeds and stops, who approves it, and who reads the record of every run afterward. Ask whether those are the operator's named people or the vendor's.
A good answer is that the roles are the operator's, the record stays in the building, and every run is replayable. The Agency Studio description on the technology page shows what that looks like on a Grid.
Whether the bill moves
Ask what happens to the bill when the floor adds a fleet. Many offers meter by robot, by request, or by data, so every operational decision on the floor becomes a compute cost decision as well.
A good answer is a single line for the configured pool, hardware and platform license and sustainment together, fixed for the term, that does not move when more robots join. Ask the vendor to say so in writing. The pricing page is where Element 31 states its own answer.
Questions this raises
- Why should Element 31 be asked the same questions as everyone else?
- Because the answers are what matter, not the vendor's name. A pool that keeps everything on site, leaves safety on the robot, fails to a stop, attests its image, and sits on a fixed line should be able to show each of those things, and a buyer should check.
- What is the most common gap these questions expose?
- Fallback. Many offers describe what happens when the compute answers and are quiet about what the robot does when it does not. The right answer is that the robot falls back to its own on-board model and stops when it must, with nothing in the pool able to override that.
- Is a neutral pool a fair thing to ask a robot vendor for?
- Yes. A vendor shipping a Czar Grid under its own name through Czar Chassis is shipping a pool that can serve any vendor's robots. Whether it will is a matter of the agreement, and the facility is entitled to ask for it plainly.
KEEP READING