AI execution runtime, patent pending

Take AI from pilot to production, safely.

Many AI pilots in buildings, factories and warehouses stall at the same two gates: the safety sign-off, and an integration you rebuild for every site. xZane is the execution layer between the model and the machine. It puts the device’s built-in safety above the AI, keeps the model inside limits you declare, and lets you reuse the adapter you write on the next site.

Ledger: real responses from a ROS 2 robot rejected robot.move.forward, duration_ms=7200000 exceeds max 20000
interrupted reflex latched mid-motion, front
  • Commands through xZane
  • The device’s own safety
One runtime between the AI models and three kinds of site. When one unit’s own safety trips, only that unit is refused.
Keeps your stack
Sits above ROS 2 or proprietary firmware. Your controllers and safety equipment stay in place.
Any model
Claude, GPT, Gemini, or a local Qwen or Mistral. The device does not know which one is asking.
Runs on the edge
The runtime runs on your own hardware. No cloud connection is needed to validate or enforce.

Pilot to production

Two gates stand between a working pilot and a rollout.

The demo works. Then the client asks who signs off the safety, and the next site asks for the same integration again. xZane is built for those two questions.

  1. 4 to 6 weeks

    Pilot

    One device, one use case. xZane runs live on your hardware, and your engineers write the adapter with us.

  2. Gate 1

    Safety sign-off

    The device’s built-in safety stays above the AI. The model can only request what the schema declares, and every command, rejection and stop is logged.

  3. Gate 2

    Integration you reuse

    The adapter and the schema are yours. The next building or line starts from them, and a new AI model changes nothing on the device.

  4. Rollout

    Production

    Licensed per device per year, on a central hub. You add devices through adapters, not rewrites.

How it works

The AI proposes. xZane decides what reaches the device.

xZane sits between the AI and your devices. The model proposes a command. xZane routes it by device identity, checks whether that device's own safety has tripped, validates the command against the schema you declared, and only then hands it to the adapter that speaks the device's protocol. Every step lands in the ledger.

You write the adapter

A HAL adapter speaks your hardware's language: a protocol, a vendor API or a ROS 2 topic. You write it once for a hardware model and reuse it on every project after.

You declare the schema

A capability schema lists what the device may do, with ranges and allowed values. The model can only request what the schema sanctions.

Everything else is xZane: routing, the safety gate, validation, modules for perception and mapping, and the ledger.

What xZane enforces

Three things, on every command.

A capability contract

You declare what a device can do, for example a speed range or a setpoint band. A command outside it is rejected before it reaches the hardware, and the rejection is logged.

Device safety above the AI

xZane puts the device’s built-in safety above the AI. While a device's own safety is tripped, xZane refuses AI commands to that device. The AI can ask for a reset. It cannot force one. Other devices keep working.

A ledger of everything

Every command, every rejection and every safety stop is logged with its context and the model that proposed it.

What stays yours. xZane does not replace your controllers, firmware or safety-rated equipment, and it is not a safety-rated device itself.

Runtime in action

Real responses from real hardware.

These are responses from xZane running a ROS 2 robot. The same runtime also drives a smart TV and a router.

Runtime responserejected
// AI asked to drive forward for 2 hours
{
  "status": "rejected",
  "error_code": "parameter_out_of_bounds",
  "violations": [
    "duration_ms=7200000 exceeds max 20000"
  ],
  "intent": "robot.move.forward",
  "ts": "2026-08-12T20:03:52Z"
}
The schema caps the duration. The command is rejected before it reaches the hardware.
Runtime responseinterrupted
// Legal command, stopped by the world
{
  "status": "interrupted",
  "outcome": "interrupted_by_reflex",
  "reason": "reflex_latched_mid_motion",
  "latch_reason": "front",
  "ai_command": null,
  "confidence": null
}
A valid command, stopped mid-motion when the robot's own safety latched on an obstacle in front.

Pilot

A bounded sprint, not an open-ended project.

One device, one use case, four to six weeks. We write the adapter together. At the end xZane is running live on your hardware, and your engineers understand every part of it.

Standard pilot

€10,000

Single device · standard hardware · 4 weeks

  • xZane running live on your device
  • An adapter written with us and owned by your engineers
  • A ledger of every command, rejection and safety stop
  • SDK access, so you can write future adapters without us
  • 2 to 3 hours a week of an engineer's time

Extended pilot

€25,000

Multi-device installation or custom hardware · 6 weeks

  • Everything in the standard pilot
  • Multi-device integration
  • Adapter development for custom hardware
  • Ground Control UI, so operators watch AI decisions in real time

Ongoing licence: €400 to €600 per device per year. A 10-device installation runs at €4,000 to €6,000 a year. xZane installs on a central hub, and devices connect through adapters.

Who is building this

Built by the engineer who designed it.

xZane was designed and built by Julio Chinchilla: the runtime, the validation gate, the device-safety interface and the hardware abstraction layer. The work spans runtimes, data platforms and embedded systems, between Vilnius and Tallinn.

ZillA Technologies OÜ is an Estonian company (registry code 17335489). A US non-provisional patent application and a PCT application are filed. The SDK is ready to hand to a first integrator.

Start a conversation

A described device is enough to start.

Tell us about your device and what you want a pilot to prove. A 30-minute call is usually enough to scope whether the pilot makes sense for your project. No commitment required.

Or write to [email protected]

What we need from you

  • One device or test setup
  • A use case: what you want it to do through xZane
  • 2 to 3 hours a week of an engineer's time