How Xolver works.
Xolver gives machines the ability to understand instructions, check whether an action is safe, and act — all without a human needing to program every step.
Most AI systems for robots stop at understanding. Xolver owns the full chain: understanding the scene, verifying safety, and executing — with a record of every decision.
Available today
The AI model, safety layer, and runtime are all implemented and available. Deployment is scoped per engagement — we start with a technical assessment and move to a controlled pilot.
Works with what you have
Xolver sits alongside your existing equipment — PLCs, controllers, plant systems. You don't replace what's already working. You add intelligence on top of it.
Safe by design, not by training
Safety isn't something we train the AI to be careful about. It's a hard check that runs before every move — separate from the AI, impossible to bypass.
Where to start
Start from the role you play in the deployment. Xolver does not assume live actuation, certification, or production readiness until the deployment path is resolved.
OEMs
Start with: Manufacturer compatibility and integration assessment.
Share: Controller family, how the robot is controlled, and your integration requirements.
Next: Confirm compatibility fit and share relevant technical materials.
System integrators
Start with: Retrofit commissioning and safety-gated preview review.
Share: Cell layout, robot profile, fixtures, task constraints, and safety boundaries.
Next: Draft a commissioning path from preview to evidence review.
Enterprise operators
Start with: Use-case scoping, cell constraints, and passive evaluation pilot planning.
Share: Operational problem, current downtime/reprogramming cost, and pilot success criteria.
Next: Decide whether a bounded technical assessment or pilot makes sense.
Technical evaluators
Start with: Runtime, evidence, deployment, and preview documentation.
Share: Evaluation questions, deployment assumptions, and required evidence materials.
Next: Review preview-only flows before discussing live actuation.
How the layers interact.
Xolver is not a single model making unchecked decisions. The system is deliberately separated so each stage has a clear role and a clear boundary.
1. Interpret
Perception and state understanding build a real-time picture of the scene, task, and likely next move.
2. Propose
The model proposes intent and candidate action sequences within a bounded domain.
3. Constrain
Hard safety checks verify policy, timing, physical feasibility, and safety limits before anything physical happens.
4. Execute
The local runtime carries out approved actions on-site, logs any deviations, and escalates rather than improvising when conditions fall outside expected bounds.
Robotics Foundation Models
Research and Pilot
The AI watches through cameras and sensors, reads the environment in real time, and understands plain-language instructions. Give it a task — "pick the red part and place it in bin B" — and it figures out how to do it.
It understands the scene. It does not command the machine directly.
Our models are trained specifically for industrial environments — manufacturing, logistics, and field operations. They generalise across varying conditions: parts moved out of place, cluttered workcells, changing layouts.
What happens here
- Reads cameras, sensors, and environment
- Understands the task in natural language
- Works out what to do next
What does not happen
- Does not move the robot directly
- Does not make safety decisions
- Does not take irreversible actions
Model X1-D
Our flagship Vision-Language-Action (VLA) foundation model.
Enforcement Layer
Pilot and Production Adjacent
This is the most important layer in the system.
Before the robot moves a single millimetre, this layer runs a hard check. Is this move physically possible? Does it stay within the safety zones you defined? Is it consistent with the rules for this machine?
If any check fails — for any reason — the machine stops. Not usually. Not most of the time. Every time.
The AI proposes. This layer decides whether the robot is allowed to act.
What it checks
- Is this move physically possible?
- Does it stay inside the safety zones?
- Does it follow this machine's rules?
- Can it be completed in time?
When something fails
Stop. Record. Alert.
The machine stops, the reason is recorded, and the operator is alerted. Stopping is not a failure — it's the system working as designed.
Why this is separate from the AI
AI is very good at understanding scenes and figuring out what to do. But it can also be wrong. Safety cannot be something the AI "tries" to maintain — it has to be a hard check that the AI cannot override.
Enforcement Layer
The deterministic gatekeeper for physical AI.
Edge Runtime
Pilot and Deployment-Specific
Xolver runs on-site, at your facility.
The AI model, safety checks, and execution all happen locally — on hardware at your site. If the internet drops, your machines keep operating safely. There's no dependency on a cloud connection for anything safety-critical.
Every action is also logged locally, with the full context of what the AI intended, what the safety check decided, and what the machine actually did.
What happens locally
- The robot moves and is monitored in real time
- Every action is logged with a reason
- If anything looks wrong, the machine stops
Your data stays at your site
Raw camera feeds and sensor data don't leave your facility. Only audit logs and monitoring summaries go to the cloud — nothing safety-critical depends on a network connection.
Safety-First Runtime
Deployment configurations, reviewable operator tasks, and explicit safety rules defined before hardware runs.
Xolver Edge Console
Live telemetry, joint health diagnostics, and on-site AI processing visibility.
* Hardware and robotics platform currently under development.
Works with your existing AI model
X1-D is our flagship model, but Xolver isn't locked to it. If you already have a robotics AI model, Xolver can wrap it with the same safety layer and runtime — the safety check doesn't care which model is making suggestions, only whether the action is safe.
Train on your own environment
Operations collected from your cells — pick-and-place runs, inspection passes — can be used to fine-tune the model for your specific environment. Everything collected is traceable back to the original run, so you can show exactly what data the model learned from.
Contact hello@xolver.ai to discuss custom training access.
Set up once, reproduce exactly
Once you define how a robot cell should operate — what the machine can do, what the safety rules are, what counts as a valid move — that setup is locked. Every deployment from that point is identical to the one you validated. Changes require re-validation.
A paper trail for every run
Every run produces a record — what the AI intended, what the safety layer decided, what the machine actually did. If you need to prove a machine operated safely for an audit, insurance review, or regulatory submission, that record is already there.
Testing in simulation is useful for previewing behaviour — but it doesn't replace validation on the actual hardware.
Ask your AI assistant about your machines
Connect Claude, GPT-4o, or any compatible AI assistant to your Xolver deployment. Ask it why a run failed, what might improve performance, or whether a cell is ready for a new task — and get a clear, structured answer.
Your AI assistant can suggest. It cannot act. Every change still requires a human to approve it, and nothing the AI assistant says can reach hardware directly.
Protected by foundational patents.
The separation between AI perception and hard safety enforcement is a core architectural innovation. Our approach is backed by an active patent portfolio and built around evidence-driven deployment, with each integration path reviewed and validated before live operation.
Core Concepts
World models
A world model is not a map. It is a persistent representation of physical state that evolves over time and explicitly represents uncertainty.
Planning happens across sequences, not frames. This enables safer behavior in noisy, partially observed environments.
What this enables
- Tracking objects through clutter and partial visibility
- Establishing causal ordering of events
- Planning safely under sensor noise and drift
Time and causality
Physical systems unfold over time. Order matters. Xolver treats time as a first-class variable. Events are ordered. Causes are inferred.
This matters for safety and accountability. When something goes wrong, the system can explain not just what happened, but why it happened.
Why this matters operationally
- Events can be reconstructed in order
- Operator acknowledgement paths stay visible
- Audit trails remain tied to actual physical outcomes
Failure handling
Failure is inevitable; silent failure is unacceptable. Xolver follows a deliberate cycleValidate → Execute → Monitor → Refuse → Recover.
Refusal is a feature. When ambiguity exceeds tolerance, the system stops and escalates rather than guessing. Recovery paths are explicit and observable.
Read more on safety constraintsWhat we do not do
We draw boundaries deliberately
- We do not manufacture hardware
- We do not replace PLCs or existing control systems
- We do not promise general intelligence
- We do not remove humans from oversight
Boundaries are not a lack of ambition. They are how physical systems achieve reliability.
Where Xolver fits.
Xolver sits between interpretation and actuation. We do not replace the entire automation stack. We provide the intelligence boundary that connects learned perception to bounded physical behavior.
- Models interpret state and propose intent
- Enforcement checks what is allowed
- Runtime carries out bounded execution locally
- Existing plant systems and human oversight remain part of the loop
Failure without this architecture.
Models alone are too probabilistic to hold final authority over motion. Control logic alone becomes brittle when environments drift. Cloud-dependent autonomy introduces the wrong failure modes into physical systems.
Xolver's architecture exists to separate these concerns so the system can adapt where it should, constrain where it must, and refuse when confidence is not enough.
A concrete example.
Consider a warehouse vehicle asked to move inventory to a staging area while avoiding a restricted zone and adapting to a blocked aisle.
Foundation model
Interprets the environment, tracks obstacles, and proposes a task-level reroute based on the current world state.
Enforcement
Rejects any candidate route that crosses a restricted zone, violates traffic rules, or exceeds motion constraints.
Runtime
Executes the allowed route locally, monitors drift during motion, and keeps response inside latency limits.
Failure behavior
If no safe route exists, the system refuses, logs the reason, and escalates instead of improvising a potentially unsafe action.
Decades of breakthroughs in months.
Explore the chronological timeline of algorithmic and architectural advancements that power Xolver's physical intelligence.
FAQ
Does Xolver replace robotics middleware or controllers?
No. Xolver sits at the intelligence boundary between learned perception and physical execution. Existing middleware, controllers, PLCs, HMIs, and plant systems remain part of the stack.
What happens when a model proposes an action that fails enforcement?
The action is rejected before it reaches the machine. The system can halt, log the reason, attach evidence, and escalate rather than turning an invalid proposal into physical behavior.
Why can't critical physical loops run through the cloud?
Critical physical loops are sensitive to latency, connectivity loss, and timing drift. Running them locally keeps response bounded where the machine is actually operating.
Can I use Xolver with a model I have already trained?
Xolver separates the model from the enforcement and runtime layers. If your model produces actions that conform to the runtime contract schema — action dimensions, observation format, control frequency — it can run inside the Xolver enforcement and runtime boundary. We maintain native adapters for X1D. Third-party model adapters can be validated against the same contract interface.
Where does retrofit fit in the architecture?
Retrofit sits below the core runtime boundary as an integration path for existing robot cells. It uses manufacturer compatibility packs, workspace geometry, safety zones, skill previews, and evidence records to add bounded autonomy without replacing working equipment.
How should simulation results be interpreted?
Simulation results are useful evidence for preview and bench readiness, but they are not production certification. Live operation still depends on hardware-specific validation, safety hardware checks, connection readiness, and operator approval.
What data is meant to leave the site?
The architecture is designed so raw sensor streams can stay local. Cloud-facing surfaces are intended for observability, audit trails, evidence references, heartbeats, and deployment review rather than live safety-critical control.