Industries
Every fleet is offline for different reasons.
The failure is the same everywhere: a bad push to a machine nobody can reach. What differs is why the machine is unreachable, what counts as healthy, and who has to sign for it.
Pick the one you run
What is the same everywhere
Three things hold across all four, and they are why the same product fits them.
Silence is ambiguous. A robot under a shed, in a tunnel, on a charger or parked for the weekend produces the same signal as a bricked one: nothing. Any rollout that advances on elapsed time is advancing on an absence of bad news from machines that were never going to send any.
There is no safe failure mode by default. A bad push to a server is a redeploy. A bad push to a robot is a bricked unit some distance from the nearest engineer, and the release most likely to strand you is the one that breaks connectivity, because it takes out the channel you would fix it over.
Verification has to be inverted. The device decides, the cloud confirms. Each unit boots the new image on trial and must positively confirm health, including getting back online, or the bootloader reverts it unaided. Fleet gates then count confirmed units. A dark robot never passes and never blocks.
What changes between industries is the definition of healthy, the shape of the rings, how long silence is allowed to be normal, and what evidence somebody needs afterwards. That is what the four pages above are about.
Early access
Running robots in the field?
We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.
Founding customers get direct engineering time and a permanent founding rate.