ZillA xZane

AI execution runtime · patent pending

Stop rebuilding the AI execution layer.

Every AI project you ship to a building or a production line needs the same layer between the model and the machine: command checking, a hardware abstraction, safety gating and a record of what happened. You rebuild it on every project, and you carry the liability. xZane is that layer, already built. Drop it above your existing stack.

Start a pilot conversation See how it works
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"
}
A real response from a ROS 2 robot. The command never reached the wheels.
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.

Where it applies

Two kinds of site, one runtime.

Building automation

AI that adjusts setpoints inside limits you declare, across HVAC, lighting and plant. Protocols such as BACnet, Modbus, KNX and OPC UA connect through adapters written in your pilot.

Building automation →

Factory and warehouse automation

AI on sorting, picking and material handling, on the line or in the warehouse, with the machine's own safety still in charge. Robots, conveyors and drives through ROS 2, OPC UA, Modbus and vendor interfaces.

Factory and warehouse automation →

Running today: a ROS 2 robot, a smart TV and a router, all through the same runtime.

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.

Open the enquiry form ↗

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