The proving layer

The sim-to-real gap is not a policy problem. It is a fidelity problem. Veron measures how far a simulator has drifted from the robot in front of it, routes the correction to the parameter responsible, and refuses to certify a policy the physics does not support.

A simulator will grade whatever you give it. It has no way of knowing that the friction it was handed was typed in by a person who was guessing, and it will return a confident number either way. Every policy that ships on that number inherits the guess.

What is missing is not a better policy or a faster simulator. It is a grade that is answerable to the hardware. That is what Veron produces, and the rest of this page is the evidence that it does.

The probe and the cockpit

Veron ships in two parts: one that lives in your stack and one that does the work.

Veron SDK: the probe

The SDK is a probe you embed in the stack you already run. It streams the logs your robot already produces, watches for divergence between what simulation predicted and what the hardware did, and connects your simulators and your deployment pipeline over MCP. It is a few lines, not a migration.

import veron

# Stream what the robot is already logging.
veron.watch(joint_states, force_torque)

Veron Agent: the cockpit

The Agent is where the engine runs. It reads what the probe streams and drives the loop end to end, each step handled by an agent responsible for that step alone:

• Measure: recover the physical parameter from the logs rather than accepting the authored value.
• Diagnose: route the divergence to the parameter responsible, deterministically.
• Cross-check: re-run the task in simulation under the measured value before anything is trusted.
• Sign: commit the result as a signed calibration with its provenance attached.
• Redeploy: push the corrected physics back to the stack the robot actually runs on.

The chain stays traceable end to end. When the evidence does not clear the bar, the Agent blocks the deploy instead of shipping a result it cannot stand behind.

Simulation orchestration

Veron loads qualified assets from Realm and spawns training environments in Isaac Lab. Domain randomisation is available but it is not the default; randomisation masks the exact failures that matter. Variants run against calibrated physics first, and randomisation tests robustness once the baseline holds.

Every run is tracked to its source asset version. If a training run used lighter_v3 at commit a3f8e1, that provenance is recorded. When the asset updates, Veron knows which policies were trained against stale physics and which are current.

Lighter asset loaded in Isaac Lab: geometry, physics, and articulation ready for training.

Structured correction

When a run fails, Veron does not wait for an engineer to read a log. It classifies the failure, routes the correction to the responsible component, and queues the appropriate action. Each failure produces a typed correction record: what failed, what was observed against what was expected, the confidence of that observation, and what to fix. Every correction is append-only and traceable back to the run that produced it.

The classification is deterministic. An LLM handles the user-facing interface only: turning correction records into plain English and accepting task descriptions in plain English. It has no role in the routing decision itself.

Why the routing is not left to a language model

The same controlled task, the same simulator, the same PPO implementation, five seeds. The only variable is where the shaping signal comes from. A reward a language model proposed trains nothing at all; a reward derived from the measured physics trains the task to completion.

Reward that comes from a measurement trains a policy. Reward that comes from an opinion does not, however fluent the opinion.

Proof, on real robot data

The three results below come from real robot logs, not from a simulator standing in for one. Where a number is a proxy rather than an SI measurement, it says so.

The grade flip

One cabinet, one hinge task. The shipped simulator graded the policy at 100 percent and would have sent it to hardware. Graded against physics measured from the robot’s own logs, the same policy scored zero. Re-budgeted for the measured value, it passed again.

The simulator was confidently wrong, and nothing in the run would have told you. The middle bar is the one that does not exist without Veron.

The honest no

A second dataset, a different robot, and a result that went the other way. On 50 real xArm6 button-press episodes, calibration improved the twin but cleared neither gate: error reduction landed four hundredths of a point below the threshold, and the improvement held on six seeds where eight were required.

Blocking the deploy is the feature, not the failure. A grade is worth nothing if it cannot come back negative.

The measurement underneath

Both results rest on a single recovered quantity. Hinge resistance estimated from 85 real episodes came out roughly ten times higher than the value that had been authored by hand.

The correction was not guessed and it did not need new instrumentation. It came out of logs the robot was already producing.

Method check

Separately from the real-data results, a known-answer test of the method itself. A coffee maker in simulation, with a friction mismatch planted deliberately and hidden from the router. Baseline was 2 from 20. After one routed correction, 10 from 10.

Continuous calibration

Structured correction handles individual failures. Continuous calibration is what happens across runs. Every time Veron surfaces a physics mismatch and records it as a calibration event, that observation accumulates. Successive training runs start from progressively more accurate physics, not from the same initial approximation every time.

A door hinge has physics that matter: resistance through the swing, the point where the latch releases, how much of that the arm has to budget for. When a run surfaces a divergence between simulation and what the hardware did, that observation is recorded as a calibration event and the next run incorporates it. Physics parameters converge toward real-world values across successive runs.

Deploy: signed, native to your stack

A calibration is only worth something where the robot actually runs. Veron exports one signed bundle and writes it out natively for each target: files you drop into MuJoCo, Isaac Lab, ROS, or your own code. Nobody re-authors physics by hand, and nobody transcribes a number between two formats.

One measurement, one signature, and it stays checkable. Months later you can still ask which physics a given policy was trained against and get an answer.

The real-world loop

Simulation calibration is the first loop. The second is harder: getting real-world deployment signals back into Veron in a structured way.

When a policy deploys to a real robot, the probe tracks the run against what simulation predicted: force-torque readings, end-effector trajectories, grasp events, contact geometry. When the robot fails, those signals flow back. The same classification logic runs. Corrections are routed to the responsible component: object physics updated, retraining queued, hardware issues flagged, new environments requested.

Each deployment cycle returns structured evidence to both the policy and the simulation it trained in. Teams onboarding an asset with an existing deployment history start from a more accurate baseline than the first team that deployed it.

The hard problem is ingestion: parsing structured sensor data from heterogeneous robot stacks into typed calibration signals without asking every team to build a custom integration. This is the frontier of what we are building. The routing logic downstream is defined. What we are solving now is the transport.

Status

Veron is the point where simulation fidelity is checked against real-world outcomes. Every run is versioned and traceable. Every failure produces a structured correction with a defined action. Every certification can come back negative.

Get in touch to explore Veron.