Use cases
Updates for fleets that are mostly offline.
Field robots are offline more than they are online, so silence is the normal state and cannot be read as either success or failure. Transfers queue and resume, and gates measure darkness against each ring's own baseline.
Silence is ambiguous
A robot under a shed, in a tunnel, or parked for the weekend looks identical to a bricked one from the control plane. Both send nothing. Any system that infers health from check-ins is guessing, and it guesses in the optimistic direction, which is the wrong one.
There are two halves to handling this properly. The transfer half has to survive links that disappear mid-download, so a thirty minute drop costs thirty minutes rather than restarting a two gigabyte pull. The gate half has to refuse to score silence at all.
What silence can tell you is comparative. A ring that normally sees sixty percent of its units check in daily, and suddenly sees thirty, has said something specific even though no individual robot has. That is the fingerprint of a release breaking connectivity, and it is the one thing the cloud can still detect after the fact.
Getting the bytes there
Resume, do not restart
Transfers pick up where the link dropped. On a machine that gets forty minutes of usable signal a day, restarting a large image means it never finishes, and teams end up doing it by hand.
Delta, not full images
Most releases change a fraction of the filesystem. Shipping the difference turns a multi-gigabyte pull into something that fits inside the window the machine actually has.
Same bundle, any transport
An image applied from a technician's laptop at a depot is the same signed artifact, recorded the same way, and verified the same way once it lands. The audit trail has no hole in it.
Transfer and staleness
transfer: resume: true # a part-finished download survives the drop delta: true # ship the difference, not the image opportunistic: true # pull on good signal, back off on metered links bundle: signed # same artifact whether it arrives by radio or USB ring_gate: stale_after: 72h # drops out of the denominator, not a pass checkin_regression: 1.5x # vs this ring's 14d dark-rate baseline
stale_after is the honest part. When a unit has been dark past the window, it leaves the denominator, so a ring of fifty with twelve long-dark units gates on thirty eight. It does not get counted as a pass, and it does not block the release forever either.
checkin_regression compares against the ring's own fourteen day baseline rather than a global number, because a ring of underground units and a ring of warehouse units have nothing to say to each other about what normal looks like.
What this does not do
Worth being clear about
- It does not make a dark robot pass a gate. Nothing does. That is the point.
- It does not give you a real-time fleet view. If the units are not talking, the picture is as fresh as their last check-in and the interface should say so.
- It does not fix an undersized link. Delta transfer buys you a lot, but a fleet on kilobit satellite backhaul is still going to take a while.
- It does not remove the need for a depot path in the hardest segments. Some units genuinely never see a network, and pretending otherwise is how the underground fleet ends up undocumented.
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.