Policy gate and decision record
In DDIL conditions — denied, degraded, intermittent or limited comms — an autonomous system has to decide for itself: hold for an operator, surface early, change a waypoint, take an AI model's answer. Routedge checks each of those against a rule you wrote and signs it into a record that survives the power being pulled, so months later you can replay the decision and show what the vehicle knew when it made it.
The testbed
Every measured result on this page comes off a small inspection ROV we designed and built ourselves — the frame, the electronics and the onboard software are all our own, not a commercial vehicle with our code bolted on afterward. It exists to validate Routedge and nothing else; it is our testbed, never a product.
The gap
A system that decides for itself, off network, in conditions nobody reproduced beforehand. Each of these is ordinary, and each one is where the hard questions come from afterwards.
After an incident the question is what the system chose and under what conditions. Without a record written at the time, on the vehicle, the answer is reconstruction from memory.
A satellite backhaul, an acoustic modem, a tether, a congested mesh. Asking anything off the vehicle is an assumption that stops holding the moment the platform goes where it was built to go.
Pull the cooling on a loaded board and it slows itself down inside four minutes. A stock model server quietly used up all 8 GB of memory in half an hour. Both measured; neither showed up on the desk.
Capabilities
The gate and the record are the product; model routing is its first adapter. Every ✓ below is a result from a run on real hardware.
State what the vehicle may do under named conditions — when to hold for an operator, when to fall back to a safe default, which model is allowed to answer — as configuration, reviewed like any other requirement.
SoDegraded behavior is signed off in review rather than discovered from a field report, and "it held" is a number off a real vehicle.
Every decision joins a signed, tamper-evident chain on the vehicle that made it, and any one of them can be pulled back out and run again against the rules you have now — or the ones you are considering.
SoWhen a program office asks why the vehicle did that, you answer from a record written at the time — one that survives the power being pulled.
Model routing is the first thing the gate was pointed at, and the easiest to adopt. Each request is weighed against the live state of the vehicle and how each model is performing, then sent to the best one available — on the vehicle first, or cloud first, whichever the mission calls for.
SoA vehicle in a dead zone answers from its own compute instead of waiting on a round trip — and that answer is governed and recorded like every other decision.
Put the failure conditions in deliberately — and publish what they find. The bench caught our record noting conditions a moment too late; the ROV surfaced three more routing defects no bench had hit. All of them are fixed and verified again on that vehicle.
SoYou learn what a failed fan or a dropped tether does to your vehicle on a workbench — and you see the faults we found in ourselves, not just the ones already fixed.
Roadmap
These are research goals, not shipped capabilities — shown here with exactly what has and hasn't been run. What's already verified is in Capabilities above.
Today the gate and the record cover model routing. The same check-and-sign step is designed to take any decision a vehicle's software proposes — a hold, a stop, a changed waypoint — not only which model answers.
A signed chain alone can miss a record that was cut short or quietly rewritten. On the bench, a prototype caught every planted edit, rewrite and deleted ending; ten hard power pulls under heavy load lost no answered request; a copy cut off by a real Wi-Fi or cable drop named exactly which entries never arrived.
Proven complete only against a copy of the record's start saved off the device at setup, plus a confirmation from the device once it's back — not a general guarantee, and not yet run across a real tether or in the water.
A record can be intact and still wrong. An after the fact comparison against the vehicle's own thruster and motion data caught a real case where a recorded stop left a thruster still driven.
An audit that runs after the fact, never a safety check — and there's no false alarm rate yet worth quoting.
If a device is lost outright, can another device it had been in contact with produce its record anyway? In a bench rehearsal between two low-cost boards, copying and signing one decision cost about 1.3–1.5 KB and under half a millisecond on both; a board that had been copying the other's sealed record held a byte for byte copy up to the last moment measured, and could verify and replay it on its own.
Nothing here is automatic yet — the copying was run by hand, not by Routedge — and the rehearsal did not test a true simultaneous loss. Whatever a lost device decided after its last contact is still gone.
Use cases
Systems that have to decide for themselves when the uplink will not help — and account for it afterwards. The subsea case is our own testbed.
ProblemA tether or acoustic modem carries kilobits while a hull survey produces continuous imagery. For most of a dive the vehicle is deciding alone, and nobody topside can say afterwards why it did what it did.
SolutionDecisions are taken on the vehicle against written rules — hold for the operator, answer locally, escalate — and each one is signed into a record the vehicle surfaces with.
On a real ROV40 of 40 answers correct on telemetry read while the vehicle was physically tilted, routine work answered on the vehicle throughout, and every urgent request held through a 7.four minute modem cut.
ProblemSatellite backhaul is metered and shared. A hot avionics bay throttles the compute exactly when tasking gets heavy.
SolutionRoutine work is decided on the aircraft. Escalation is gated on priority, measured link latency and the temperature the board is actually running at — so the expensive path is spent on decisions that earn it.
On the benchCooling pulled under load: the temperature rule raised the alarm 42–56 seconds before the hardware began slowing itself down, repeatably across four runs.
ProblemA fleet on shared Wi-Fi hits latency spikes and dead zones as it moves. An assistant that stalls mid aisle is a stopped robot and a ticket.
SolutionThe robot decides locally through the spike and reaches out only when the link is genuinely healthy. Every decision, and what it cost, is logged per robot.
On the benchAn eight hour shift with 16 link cuts: 6,711 requests, zero failures, memory flat to within a megabyte, and no thermal throttling.
Integration
Model routing is the quickest way in: Routedge answers the same requests your client library already sends, so there is no SDK to adopt and no protocol to learn. Point the client at it and leave the rest alone — body, streaming and response shape are unchanged. A general decision API, for choices that are not a model call, is designed and not yet built.
Python · same for C++, Go, anything that speaks HTTPone line changes
# before — straight to a cloud endpoint
client = OpenAI(base_url="https://api.provider.example/v1")
# after — routed on the vehicle. Every call below is untouched.
client = OpenAI(base_url="http://localhost:8000/v1")Architecture
It sits on the advisory and supervisory path only — never between a controller and an actuator. The vehicle keeps its own watchdog and its own declared default if Routedge does not answer.
Fig. 1 — Runtime topologyOne process, on the platform
Platforms
A small Linux service on the platform's own compute, roughly 74 MB resident. The cloud is an upgrade, not a dependency.
Routedge governs the advisory and supervisory path — what the vehicle is allowed to decide as conditions degrade, and what record that leaves. It never sits between a controller and an actuator. It is not a certified safety component, and the vehicle keeps its own watchdog and its own declared default for when Routedge does not answer in time. Its job is to make degradation predictable and to leave evidence of it — not to promise it will not happen.
It is also not an inference engine: it does not execute, compile or quantize models. Figures here come from bench runs on an 8 GB Raspberry Pi 5 and from an inspection class ROV running on tether power with its thrusters unpowered and its computer outside the pressure hull. Nothing here has been under water or under thrust, and nothing is claimed for other hardware until it has been run there. The specs page lists what was run, what was not, and what is still open — including the obstacle stop work, which ran against simulated sensors. Better you hear it from us than find it on the second call.
Contact
In active development, focused on defense and dual-use autonomy. If you work on systems that have to keep making accountable decisions when the link, the power or the clock fails, tell us what you are working on.