Contract-first physical AI runtime

Xolver Runtime

A research stack for taking VLA systems from probabilistic model output to contract-bound, safety-enforced, evaluated, and auditable deployment paths. Today, the public surface is strongest as local inspection, preview, safety, blueprint, and evidence tooling; hardware execution remains path-specific.

$uv sync
$xolver skills list
$xolver skills preview pick_and_place \
--arg object=strawberry \
--arg destination=bowl
$xolver blueprints inspect panda_edge_runtime
$xolver safety demo-clip
# Preview control flow before hardware paths.

Getting Started

New to Xolver? Install the workspace, inspect previewable skills, then follow the safety and blueprint paths before discussing hardware execution.

1

Install workspace

Use uv to resolve the Python stack and local packages.

Quickstart
2

Preview skills

Run read-only and proposal-only skills without actuating hardware.

Skills
3

Inspect blueprints

Resolve deployment composition and hashes before runtime.

Blueprints
4

Check evidence

Review replay, certification records, and maturity claims.

Evidence

Accessible Today

These are the parts a developer or evaluator can inspect and run locally without claiming live robot deployment.

CLI Previews

List skills, preview actuation intents, run policy-mediated demos, inspect blueprints, and create local replay records.

AvailableNo hardware

Safety Demos

Send intentionally unsafe sample actions through the shield and inspect refined or rejected intents.

AvailableLocal demo

Xolver Console

Native desktop UI for contracts, safety snapshots, skills, blueprints, orchestration proposals, interventions, and replay data.

AvailableInspect & Preview

Quickstart

The first usable path is local preview and inspection. It does not launch hardware actuation.

$uv sync
$xolver skills list
$xolver skills preview pick_and_place --arg object=strawberry --arg destination=bowl
$xolver blueprints inspect panda_edge_runtime
$xolver safety demo-clip
$xolver replay demo
LOG_INFODemo records are written to .xolver/demo-control-plane/ by default. They are local control-plane artifacts, not certification evidence by themselves.

Skills

Skills are loaded from contracts/agent_v1.yaml through SkillRegistry and executed through SkillActioner.

Read-only

Local inspection helpers such as scene description, object metadata, workspace checks, deployment summaries, and safety intervention explanations.

Inspectable

Proposal-only

Non-executable previews such as trajectory proposals. These make intent visible before any runtime or policy handoff.

Preview

Actuation Skills

Skills such as move_to and pick_and_place stay preview-only unless explicitly policy-mediated. They do not directly execute hardware.

Policy-mediated only

Blueprints

Blueprints compose deployments from contracts, features, adapters, safety gates, watchdogs, evaluators, evidence writers, and optional orchestration tools.

$xolver blueprints list
$xolver blueprints inspect panda_edge_runtime --json
$xolver blueprints snapshot panda_edge_runtime \
--output .xolver/panda_edge_runtime.json

Critical Path Stays Gated

Model output must pass through the model adapter, action schema validator, safety shield, watchdog latency gate, and hardware adapter. A blueprint records the chosen path; it does not certify every possible path in the repository.


Evidence And Replay

Replay gives developers a local record of previewed control-plane behavior. Certification-sensitive evidence remains deployment-specific.

Replay Demo

xolver replay demo writes a local SkillInvocation, RunEvent, and ReplayBundle through the JSONL control-plane store.

Available

Evidence Records

Runtime contracts, feature sets, robot profiles, safety policies, model artifacts, evaluators, adapters, and manifests can be hashed into path-specific records.

Path-specific

Certification Claims

Certification requires complete contracts, safety controls, evaluator reports, evidence hashes, logs, and approval or rejection records for the deployment path being discussed.

Not repo-wide

Understanding the Ecosystem

Xolver is organized around explicit contracts, runtime gates, and evidence. The stack is strongest where model actions must cross a typed boundary before they can become physical behavior.

Contracts

Typed robot, action, observation, safety, task, and runtime contracts define the source of truth.

Implementedsrc/xolvervla/contracts

Enforcement Layer

Contract-driven enforcement checks refine or reject actions before they reach hardware-facing adapters.

Implementedxolver-safety-shield

Blueprints

Deployment composition records models, features, adapters, evaluators, safety controls, and resolved hashes.

ImplementedResolved snapshots

Model Runtime

VLA adapters normalize model outputs to action schemas and make generation backend choice explicit.

ExperimentalResearch backends

Data Factory

Episode manifests, loaders, synthetic promotion checks, and provenance gates keep training data claims traceable.

ImplementedProvenance tests

Orchestration

MCP, reflection, reward, and layout tools can propose changes, but do not directly mutate certified runtime behavior.

Proposal boundaryExperimental tools

Actuation Architecture

The intended actuation path is explicit. Non-critical streams may be composed more flexibly, but hardware paths must pass through contracts, shields, watchdogs, and adapters.

FLOW_DIAGRAM

Model Action

Probabilistic VLA output.

Model Adapter

Normalize to runtime contracts.

Action Schema Validator

Check structure and limits.

Enforcement Layer

Refine, clip, or reject action.

Watchdog & Latency Gate

Fail closed on runtime drift.

Hardware Adapter

Only after gated validation.

Certification is Path-Specific

Do not treat the repo as certified by default. A deployment path needs a resolved blueprint, matching contracts, feature validation, safety controls, evaluator reports, evidence records, and path-specific tests.

model action
-> model adapter
-> action schema validator
-> safety shield
-> watchdog / latency gate
-> hardware adapter

Maturity Labels

Public claims should distinguish implemented surfaces from research paths. This page follows the labels used in the repo README.

Implemented

Contracts, scoped feature sets, shield construction, blueprints, evidence hashing, adapters, provenance tests, and package boundary checks.

Stable Story

Experimental

Diffusion and FACT-style backends, model extensions, synthetic co-improvement, reflection, layout proposals, HIL paths, hardware/OEM adapters, and backend switching.

Research

Planned

Deeper extension extraction, backend-specific evidence, broader blueprint examples, artifact cleanup, and pytest conversion.

Roadmap

Certification-ready

Only a resolved deployment path with matching contract, shield, watchdog, evaluator reports, evidence hashes, logs, and path-specific tests.

Path Only

Common Commands

Start with preview and inspection commands. Hardware-facing paths should only be discussed after the deployment path is resolved.

$xolvervla-serve
$xolvervla-train
$xolvervla-compute-stats
$xolvervla-convert
$xolvervla-eval-sim
$xolver replay demo
$xolver --help