Docs & Resources.

Public technical resources for Xolver's current foundation model work, architecture direction, and deployment approach.

Not every part of the stack is public, and not every part is complete. Deployment follows a cycle from shadow evaluation to active enforcement as confidence grows.

This page is the public technical entry point. It covers what we can describe openly today and points technical partners to deeper materials where appropriate.

Deployment Approach

READY

1. Assess

Analyze environment complexity & existing stack. Define risk tolerance and latency budgets.

ACTIVE

2. Pilot

Deploy in "Shadow Mode" (passive evaluation). Measure refusal rates & constraint violations.

LOCKED

3. Rollout

Incremental expansion to active control. Policies tighten as confidence grows.

LOCKED

4. Govern

Continuous logging & audit trails. Management oversight via dashboards.

Typical outputs: Technical brief, deployment plan, and evaluation criteria scoped to the pilot.

Public Documentation

Available Now

  • Foundation model overview
  • Architecture direction
  • Physical AI operating concepts

In Development

  • Deterministic safety and enforcement layer
  • Edge runtime
  • Partner integration materials
Glossary

World model: A persistent representation of physical state that evolves over time and carries uncertainty.

Safe refusal: A designed stop condition where the system halts and escalates instead of taking an unsafe action.

Policy gate: The enforcement boundary that checks whether a proposed action is allowed before execution.

Latency budget: The timing envelope within which the system must interpret, validate, and act safely.

Partner access: Deeper implementation and integration material is shared through technical engagement, not as open public docs.

Documentation Scope

Public now

High-level system architecture, foundation model framing, deployment approach, and key operating concepts.

Private by design

Proprietary implementation detail, sensitive integration specifics, and partner-specific deployment material.

Coming as the stack matures

More detailed technical documentation around enforcement and runtime behavior as those layers move from development into productized surfaces.

FAQ

How is this different from ROS nav?

ROS provides the message bus and tools. Xolver provides the decision boundary. We sit between the planner and the controller to enforce safety.

Do you replace PLCs?

No. We interface with PLCs via standard protocols (Profinet/EtherCAT). We handle spatial reasoning; PLCs handle loop control.

What is available publicly today?

Our public materials cover the foundation model work, architecture direction, deployment approach, and operating concepts. Deeper implementation detail is shared through partner engagement.

What parts of the stack are still in development?

The deterministic safety and enforcement layer is in development. The edge runtime is also in development.

What happens on network loss?

The target architecture keeps critical policy and execution local so the system can complete the current safe move or hold state during network loss. The edge runtime for this is still in development.

How do you prevent hallucinations?

The model is not treated as the final authority over action. Xolver's architecture separates proposal from execution so physical behavior can remain bounded by policy and constraints.

What data leaves the site?

Raw video/lidar stays local. Only execution traces, violation logs, and heartbeat telemetry leave the site.

How do pilots start?

We begin with a scoped technical evaluation, often in shadow mode, to baseline current operations and measure where bounded intervention could add value.