Skip to content
for robotics & physical ai teams

The robot did something surprising. What, exactly, was it running?

Teleop demos, fleet logs, sim rollouts, VLA fine-tunes — every policy you deploy is the product of a data mixture somebody curated and a recipe somebody remembers. roar records that recipe automatically, at runtime. GLaaS resolves any deployed checkpoint's hash back to the data, code, sim build, and environment that made it.

no code changes · works with your training stack · <3% overhead, measured
$ roar show policy_v41.ckpt
artifact·7c3a8de…train.py --mixture v12·commit 726f617
inputs·teleop_2026q2 ad9c125…+sim_rollouts b2f44ac… (isaac-sim @ 4f19e01)+base_vla 3e19f01…
env·pytorch-2.11 · cuda-12.2 · 8×H100
built for the physical-ai data economy

Four questions your team answers weekly. Now they're lookups.

"Which sim generated this data?"

Sim and real, one graph.

Sim rollouts carry the simulator's code, commit, and parameters in their lineage; teleop and fleet data are hashed at ingestion. Real and synthetic data live in the same graph, so mixture provenance is one hop — not a spreadsheet.

"What trained the policy on that robot?"

Deployed checkpoint → full recipe.

An incident review starts from the checkpoint's hash — not from Slack archaeology. roar show <hash> returns the data mixture, code, environment, and every upstream job. The chain of custody survives the copy to the robot.

"Did eval episodes leak into training?"

Membership is a hash query.

Composite artifacts treat a 5M-file dataset as one addressable node — with membership queries. "Was this episode in the training set?" gets a yes/no from the record, not a shrug.

"Only Jane knows how v41 was trained."

Recipes that survive departures.

The curation decisions, mixture versions, and hyperparameters that produced your best policy are recorded as a byproduct of running the job. The team inherits the record, not a four-bullet handoff doc.

"We can't reproduce a model from three months ago. Would be great to have the recipe & datasets stashed."

— CTO, Series B robotics company
where it sits

Your stack stays. One prefix changes.

-torchrun --nproc 8 train_policy.py
+roar run torchrun --nproc 8 train_policy.py

That prefix is the entire adoption cost — for one researcher or the whole lab.

PyTorch · JAX Isaac Sim · MuJoCo · your sim Ray · Kubernetes · Slurm S3 / GCS fleet buckets W&B · MLflow no wrappers · no declarations

roar observes at the syscall level — if the job read it or wrote it, it's in the graph.

built for teams that ship into the physical world

Evidence for the day someone asks.

Incident-ready by default.

When a deployed policy misbehaves, the investigation is a lineage walk — and when a customer, regulator, or safety review asks how a model was built, the answer is a generated document, not a quarter of archaeology.

  • CycloneDX 1.7 AI-BOM from any registered lineage
  • scored against G7 / CISA / NTIA guidance
  • mapped to EU AI Act Annex IV
How the AI-BOM works →

Your fleet data never leaves.

GLaaS stores the recipe, not the ingredients. Sensor logs, teleop sessions, checkpoints, and datasets stay in your buckets and on your infra — the registry holds hashes, commands, and graph edges, published under your private scope.

  • secret values redacted before publish, with confirmation
  • private-by-default for teams · export as open JSON
  • self-hosted GLaaS on Enterprise
What leaves your machines →
next step

Try it on your next policy run.

if you run the team

Hand it to whoever trains next.

The fastest evaluation: one researcher, one training job, thirty seconds. Or talk to us about a pilot — we work with robotics teams from seed to Series B and beyond.

Platform overview Talk to us
if you train policies

Point roar at your next run.

No account, no code changes. Works the same on a laptop fine-tune or a multi-node Ray job.

$uv tool install roar-cli
or: pipx install roar-cli  ·  pip install roar-cli  ·  read the docs →