Skip to content
Sentia
3D digital twin view of a tank robot with an on-screen readout of a real emergency-stop event: command issued, every robot stopped a tenth of a second later
Back to all postsplatform

Assured Autonomy and Human Command

platformsafetytrust

There's a version of autonomy that optimizes for looking impressive: minimal human involvement, maximal independence, decisions made and acted on before anyone outside the system fully understands them. SentiaCore is built against that version, deliberately. We think autonomy earns the right to operate near people and physical danger only by being more conservative than a careful human — never less — and by never, under any circumstance, being harder to stop than it is to start.

A gate that holds no model

Every proposal that could move a robot — whether it came from doctrine, a planner, or a language instruction — passes through a fixed, deterministic set of safety rules before it reaches that robot. There's no model and no randomness inside that gate. The same situation produces the same answer, every time, and when the gate blocks something, it says why, in terms a commander can actually act on. This isn't a second opinion from another model — it's a hard boundary that doesn't move just because something upstream of it got more confident.

Rules earned, not assumed

The rules in that gate aren't a theoretical list drawn up in advance of ever seeing a real incident. Each one exists because a specific, real situation demanded it — a case where the default behavior would have been wrong, examined carefully, and turned into a standing rule. New rules go through the same scrutiny before they're trusted to govern a live robot. The gate grows the way a seasoned team's judgment grows: through specific, examined experience, not blanket caution applied everywhere equally.

The override sits outside the loop

The emergency stop in SentiaCore is not a feature of the reasoning system — it's wired beneath it. That's a deliberate architectural choice, not an implementation detail: it means the override keeps working even in a failure mode the reasoning layer itself never anticipated. A safety mechanism that depends on the system it's meant to override working correctly isn't a safety mechanism. SentiaCore's isn't built that way.

We've measured this in rehearsal, not just asserted it: in one run, every robot in the fleet came to a stop within a single control tick of the command being issued — a tenth of a second. That's a rehearsal-measured latency for the reflex itself, not a claim about any particular robot's physical hardware — but it's the number we hold the architecture to, and it's why the override sits where it does.

A commander is never a spectator

Every plan SentiaCore proposes renders as a readable card before it runs — what it will do, what tradeoff it's making, and what the rehearsal against the alternative showed. A commander can approve it, override it, or stop it at the plan level, or reach straight for the emergency stop — and neither path is ever closed off just because the system has been running smoothly. Approval and override are symmetric by design: stopping a plan is exactly as easy as starting one, never harder.

Why this is a product decision, not a compliance checkbox

It would be possible to build a faster, more independent system by loosening any one of these constraints — fewer gate rules, a softer override, less visibility into what's about to happen. We don't think that trade is available to us, or to anyone building autonomy for physical emergencies. The whole premise of SentiaCore is that a team of robots making decisions near real danger is worth deploying only if a human commander can trust every decision enough to stand behind it, and can end any decision, instantly, without having to ask the system's permission first.