Auditable decision engine for service robots
The robot brain that thinks, but never freelances
An LLM proposes the next move. A runtime contract vetoes anything unsafe, defers to a human when it's unsure, and logs every decision so you can replay it later.
Why raw LLM control doesn't fly with customers
No answer for 'why'
Letting an LLM drive a robot directly leaves you with no answer for 'why did it do that' or 'what will it never do.'
New site, new logic
Move to a new site or a new robot model, and the decision logic usually has to be rewritten from scratch.
Generative AI without the open-ended liability
OEMs want the capability of generative AI, but not the open-ended risk of handing it full control.
How a decision is made
Between what the robot senses and what it does, there's a layer that checks every proposal against safety rules — nothing gets through unreviewed.
-
1
Snapshot
The robot's position, sensor readings and site state are assembled into one structured snapshot.
-
2
Trigger
An event — arrival, a detected hazard, a user request — kicks off the decision flow.
-
3
Reasoning (the LLM proposes)
An LLM reads the snapshot and the site pack, and proposes what to do next.
-
4
Runtime contract (the veto happens here)
The runtime contract checks the proposal against safety rules and vetoes anything unsafe. When it's genuinely unsure, it surfaces a choice card to a human, and falls back to its own recommendation if no one answers in time.
-
5
Orchestration
The approved action is handed to ROS 2 / Nav2, or to the elevator control interface.
-
6
Decision log & replay
Every decision is logged and can be replayed later to show exactly why it was made.
Deliverables
Decision engine SDK
A full programmatic interface across snapshot, reasoning, runtime contract and orchestration.
Site pack authoring tool and validator
Model POIs, zones, elevators and skills as data, with automatic checks for completeness and format.
Decision log viewer and replay
Step back through any past decision to see what it was based on, and why it was vetoed or approved.
Human-in-the-loop choice cards and voice prompts
When the robot is unsure, it surfaces a choice card for a human to decide, with a timed fallback to its own recommendation and spoken status updates.
MCP interfaces
Virtual-wall and wheelchair-control interfaces that let external AI agents call robot actions directly.
OEM integration engineering
Hands-on engineering support to port the decision engine onto your own robot.
Who it's for
Service robot OEMs
You want generative AI in your robot, but not the liability of a black box or rules too rigid to extend.
The LLM proposes, the runtime contract vetoes. Moving to a new site means swapping a site pack, not rewriting the core.
Systems integrators deploying into hospitals and public-sector sites
These sites demand auditability — proof of why every action happened. A black-box AI can't give you that.
Every decision is logged and replayable, and uncertain cases are routed to a human — built for audit from day one.
Platform teams letting external AI agents call robots
You want an agent to control robot actions directly, but you're worried about it issuing something unsafe.
Calls go through MCP interfaces, and every action still passes through the runtime contract before it executes.
Why us
We haven't found anyone else selling 'LLM decision-making plus a runtime safety veto plus an audit trail' as a single product.
Safety is hard-coded, not learned
Brain Corp's CEO has said safety needs to be hard-coded, not learned — that's exactly what our runtime contract does. The veto rules are program logic, not LLM habit.
We sit between the LLM and the robot, not just around the hardware
Platforms like NVIDIA Halos govern hardware and functional safety; they don't govern how the AI itself decides. Our runtime contract sits directly between the LLM's proposal and the robot's action.
New site, new data — not new code
Site packs encode locations, zones, elevators and workflows as data. Porting to a new site or a new vehicle doesn't require rewriting the core decision engine.
Decisions leave a trail
Every decision is logged and replayable, not reconstructed from memory after something goes wrong.
Pricing
Structured like an OEM safety-feature subscription, not software you buy once.
OEM-embedded license
The decision engine ships embedded in the robot's firmware, licensed per robot, per subscription period.
- Per-unit, per-period subscription
- Falls back to manual mode if the subscription lapses
- Includes site pack updates
Rates set per engagement
Site pack build
Modeling a specific site, such as a hospital floor or a factory zone, into a usable site pack.
- One-time build fee
- Includes validation testing
- Optional maintenance retainer
First OEM partnership
Looking for a first robot OEM to port and ship the engine together.
- Terms open to discussion: exclusivity for guaranteed volume, or equity
- Joint proof that moving vehicles or sites only means swapping a site pack
By arrangement
Current status and what we're still proving
Verified
- 435 automated tests passing
- 4 site packs built, with POIs, zones, elevators and skills modeled as data
- Full decision pipeline validated in simulation, on one vehicle, in one site
- Virtual-wall and wheelchair-control MCP interfaces working
In progress
- The human-in-the-loop interface is still a developer-facing demo, not yet validated with real operators
- The whole pipeline has only run on one vehicle, in one site — not yet ported anywhere else
Next
- Partnering with a Taiwanese service-robot OEM to port the engine onto their robot and run it in one real site, to prove that moving vehicles or sites only means swapping a site pack
FAQ
Can the LLM take unsafe actions on its own?
No. The LLM only proposes the next move. Every proposal has to pass the runtime contract's safety rules first, and anything unsafe is vetoed before it reaches the robot.
Who writes the veto rules, and can we change them?
The veto rules live in the site pack as data and logic, set by the integration team for each site, and can be adjusted or extended as the site's needs change.
Where are decision logs stored, and for how long?
Logs are written into your own deployment environment, and your team sets the retention period. We don't currently run a separate hosted log store.
What has to be redone for a new site?
Mainly the site pack: re-modeling the new site's POIs, zones, elevators and workflows as data. The core decision engine doesn't need to be rewritten.
Can it plug into our own ROS 2 and navigation stack?
Yes. The orchestration layer talks directly to ROS 2 / Nav2, and we've already validated navigation goals, no-go zones, speed limits and arrival checks.
What happens if the cloud model connection drops?
Today, reasoning depends on a cloud-hosted large language model, so a dropped connection falls back to safe manual mode. An offline, edge-capable version is a separate product track we're currently evaluating.
Ready for a robot brain that thinks, but doesn't freelance?
Tell us about your robot or your site, and we'll set up a short discovery session.