No AI in the control loop: how a MoLogica robot stays safe
Six safety rules built into the architecture, from a whitelist that refused 'chase the intruder' to a watchdog that stops the robot in 0.94 s.
Engineering notes · Safety ·
Language models are good at planning and good at judging. They are also slow by robot standards and occasionally wrong. A model that takes a few seconds to answer and is sometimes mistaken should never be the thing deciding whether a robot brakes.
That idea shapes the whole safety design. MoLogica’s AI plans missions and judges inspections. It never touches anything that moves in real time. Braking, balance and obstacle avoidance run in proven controllers, in milliseconds, behind a safety supervisor that sits between every command source and the wheels.
These are six rules, and they are architectural. They describe how the system is built, not settings someone can switch off.
Rule 1: No AI in the real-time control loop
There are two speeds in a patrol robot. Planning happens in seconds: which checkpoint next, which route, what to photograph. Control happens in milliseconds: slow down, steer around the pallet, stop before the wall.
Language models live entirely on the planning side. The control side runs on proven controllers that each do one job well. The planner can suggest where to go. It cannot steer.
Status: proven in simulation.
Rule 2: The control loop never crosses the internet
The safety supervisor runs on the robot, on its NVIDIA Jetson computer. The decision to stop never waits for a network, a site server or a cloud model. If the link drops, the robot can still stop.
This matters most on the sites MoLogica is built for: mine perimeters, basements and remote yards where connectivity is weak. A robot whose safety depends on a connection is unsafe exactly where the connection is worst.
Status: proven in simulation.
Rule 3: A strict chain of command
Every command source has a rank:
- Hardware emergency stop
- Human operator
- Mission
- AI
Each outranks the ones below it. The human always outranks the AI. The hardware e-stop cuts power regardless of any software, so even a fault in the supervisor itself cannot keep a robot moving once the e-stop is hit.
Status: the software chain of command is proven in simulation. The hardware e-stop is validated on the first physical robot, which is on the bench now.
Rule 4: The AI can only touch what it’s allowed to
When a model plans a mission, it does so by calling robot functions, such as “go to waypoint”, “face this object” or “capture an image”. Those calls run over the Model Context Protocol, the standard way AI models use tools. A whitelist sets which functions a model may call at all.
In testing, a model was given the instruction “open the roller door and chase the intruder”. It was refused before the robot did anything. Pursuit is not on the list of functions the AI can call, so there was nothing to plan with.
That is the useful thing about a whitelist. “Never pursue” is enforced as a function the AI does not have, on top of being written in a policy.
Status: proven in simulation.
Rule 5: Fail safe, not fail moving
Software crashes. Links die. When commands stop arriving, a robot that keeps doing the last thing it was told is a hazard.
MoLogica’s watchdog watches for that. If commands stop, it stops the robot within about a second and sends explicit stop commands to the wheels. In testing it locked the robot in 0.94 seconds. An operator can still drive the robot after the watchdog trips, so a stopped robot is never a stranded one.
Status: proven in simulation.
Rule 6: Rules of engagement are built in
Four rules sit on top of the technical design:
- Never pursue. The robot alerts and holds position.
- Alert first. Detections go to the control room with an image.
- Protect the guard. People’s safety comes before any detection.
- Log everything. Every command, verdict and takeover is recorded for evidence.
Status: designed.
How the rules fit together
| Rule | What it prevents | Status |
|---|---|---|
| No AI in the control loop | A slow or wrong model making a real-time decision | Proven in simulation |
| Loop never crosses the internet | A dropped link stopping the robot from stopping | Proven in simulation |
| Chain of command | The AI overriding a person | Proven in simulation, hardware e-stop pending |
| Whitelist | The AI calling a function it should not have | Proven in simulation |
| Watchdog | A robot carrying on after its commands stop | Proven in simulation (0.94 s) |
| Rules of engagement | Pursuit, unlogged action, risk to people | Designed |
Human in the loop, always
Any operator can take over any robot at any time, in two ways.
Directed, in plain language. “Go back to the east gate, get closer, show me that lock.” This runs through the mission layer and the safety supervisor like any other mission, so it follows the same rules.
Direct joystick. Millisecond control on the human path, bypassing the AI entirely.
Both are logged. In the designed learning loop, each takeover becomes a correction episode the system learns from.
The same supervisor on every body
MoLogica runs one software image across every robot, so the same supervisor sits on a small indoor robot, an industrial rover and, later, a legged robot. The end-to-end proof gate passed on two different robot bodies in simulation with no rewrite, and the safety rules came with it. A safety design that had to be rebuilt for each body would be a safety design with gaps.
Legged bodies follow the same rule as the rest. Balance comes from the manufacturer’s proven gait controller, and MoLogica’s supervisor, mission layer and inspection run on top. The AI never balances the robot.
Why this matters to a buyer
A security or operations manager does not need to understand language models to judge this design. The questions are simple:
- Can the AI make the robot do something dangerous? It can only call functions on the whitelist, and none of them is pursuit.
- Can the robot stop if the network fails? Yes. The supervisor is on board.
- Can a person always take over? Yes, in plain language through the supervisor, or by joystick around the AI.
- What happens if the software hangs? The watchdog stops the robot in about a second.
Where this stands
Rules 1 to 5 are proven in simulation, including the refused “chase the intruder” instruction and the 0.94 s watchdog, apart from the hardware e-stop, which is validated on the first physical robot now on the bench. The rules of engagement are designed. The safety supervisor has not yet run on a real site; pilot sites are the next stage.
Book a demo to see the supervisor refuse an instruction in simulation.