Hello all,
I’ve built a working runtime (I call it xZane) that sits between an AI model and physical actuation. The model proposes intents; a deterministic layer validates each one against the device’s declared capabilities before anything reaches the hardware, and the device’s own safety function runs underneath, independent of the model.
I’ve been running it across three quite different devices with the same four to five models (Claude, GPT and Gemini in the cloud; Mistral and Qwen locally): a ROS 2 mobile robot (Yahboom Rosmaster M1, Jetson Orin Nano), an LG webOS TV, and a robot vacuum. Same runtime, same models, one validation gate… the per-device specifics come from a schema rather than a code change.
A few short clips, because they show it better than I can describe it:
On where this sits: I’m aware of the recent related work: ROSClaw and URML both put a validation layer between a model and a robot, and both validate the command or program before execution. xZane differs in that it isn’t only a pre-execution check. The safety enforcement runs as an independent layer alongside execution, and it’s built to integrate a device’s existing safety function (the certified e-stop or safety-rated behavior) beneath the AI rather than replace it (or you can author your own), so the model is never in the safety-critical path. I mention them to place this clearly, not to relitigate their designs.
What I’d like to find out from people running real robots, industrial cells, or other machine-control setups: does this approach fit a use case you actually have? I’ve validated it on my own hardware and the useful next step is other people’s different devices, different transports. If that’s interesting to you, or if it looks worth collaborating on, I’d like to hear from you! And I’m equally interested in where you think this breaks.
Happy to go deeper on how the schema and the runtime are structured.
Thanks for your time and support!
Julio.
It fits mine, with one condition.
I built the measurement side of this, and the thing that kept surprising us is how much of the risk is invisible at the LLM boundary. A reworded instruction moved a real policy out of its safe envelope on 44 of 50 matched pairs, and the instruction itself never looks unsafe. So an interposition layer that only reads text will be looking in the wrong place.
The condition: whatever it blocks on, publish the false-positive rate. Our own safety predicate fires on about 4% of completely benign episodes. If a runtime intercepts on a predicate like that with no stated benign rate, an operator has no way to know whether it will interrupt real work.
Curious what you are intercepting on.
Hi!
Thanks, you’ve put your finger on why we don’t intercept on text at all.
We never read the instruction. The primary layer validates the action the model proposes against the device’s declared operational envelope; a second, independent layer acts on live telemetry alone. So the reworded-instruction case you describe (benign-looking text, policy pushed out of envelope) still has to emit an action with concrete parameters, and the action is what gets checked. Outside the declared bounds it’s rejected, however the instruction was phrased. The envelope is declared by the integrator, not learned by us, and the telemetry reflex latch can’t be overridden by either the model or the runtime.
On your condition: worth separating two axes, because I think your matched-pairs harness sits squarely on our primary layer. Your matched pairs measure instruction-to-action correctness: vary the phrasing, watch the action leave the envelope (correct me if I misunderstood). That’s the same boundary our rejection layer enforces on, and it’s fully auditable from our own logs, split by cause (non-conforming or undeclared-capability, versus out-of-bounds request), because the referee there is the declared schema, not the system’s opinion of itself. The second independent layer only fires on a physical telemetry threshold, so it can’t false-fire on a benign episode unless a sensor reports a hazard that isn’t there. That doesn’t make the rate zero… phantom returns from dust, glare or reflective surfaces are real, but it reduces the benign-interruption rate to a sensor-fidelity question with a nameable physical cause per event, not a predicate to calibrate.
One thing that would let me line our numbers up against your 4%: what does your safety predicate key on? policy-level conformance, physical conditions, or both? Depending on the answer, one of our rejection numbers is directly comparable. I’d rather show you the actual figures than post them out of context, happy to walk you through them, and to hear the shape of your setup, off-thread whenever suits.
Thanks again for your reply, it is very insightful for me and I really appreciate you taking the time 
Hope we can get in touch!
Julio