Built-in Validation for Simulation Assets: Stop Checking Every Asset by Hand

Hardware companies and physical AI teams do not want to spend their simulation engineers on checking assets. They want to spend them on the robot. Yet almost every team that scales simulation hits the same wall: the assets arrive faster than anyone can verify them, and an unverified asset is a liability in a training run. This guide explains why simulation assets fail in ways manual review cannot catch, what validation built into the asset pipeline should check, how to read the result, and where validation stops.

Quick answer: Built-in validation means every simulation asset is checked by the pipeline that produced it, before export, and ships with a report of what passed. It should separate correctness (the asset is internally consistent and its OpenUSD and MJCF describe one object; a failure stops the build) from conformance (it meets a published standard such as NVIDIA's SimReady Foundation profiles; a failure is reported). It should run physics, not only parse files. For teams building on real hardware, it is what lets asset volume grow without the simulation team turning into a QA team.

Simulation assets fail quietly

A broken web page shows you it is broken. A broken simulation asset usually does not.

An asset can load in Isaac Sim or MuJoCo without a single warning and still be wrong in ways that matter to a robot:

• The mass is plausible but wrong. A ceramic mug modelled as a solid block is several times too heavy. It renders the same.
• The centre of mass sits in the wrong frame. The object tips when it should stand, or stands when it should tip.
• A collision hull penetrates the floor. The object jitters or pops at the start of every episode.
• A joint is authored outside its own limits. The first physics step snaps the door, and the policy learns from a violent reset.
• The OpenUSD and MJCF versions disagree. A policy trained in MuJoCo and evaluated in Isaac Sim is quietly tested against a different object.

None of these is visible in a viewport. All of them surface later, as a training run that will not converge, a policy that behaves strangely on one object, or an evaluation number nobody trusts. By then the asset is buried in a scene with hundreds of others, and finding it costs far more than checking it would have.

Why manual review does not scale for hardware teams

The honest way to verify an asset by hand is to load it into the simulator, inspect its physics values, drop it, watch it settle, open its joints to their limits, and compare its formats. That is real engineering work, and it has to be repeated for every object.

For a team building a real robot, the object count is set by the world the robot works in: every SKU on a shelf, every appliance in a kitchen, every part on a line, and every variant generated for domain randomization. The review load grows with that count. The simulation team does not.

The result is a familiar pattern:

1. Assets queue behind review, so training waits.
2. Review gets lighter to keep up, so bad assets get through.
3. Bad assets surface as training bugs, which are slower to diagnose than asset bugs.
4. The team stops trusting generated or third-party assets and goes back to building by hand.

Built-in validation breaks that loop by moving the check to where the asset is made. Nobody reviews the asset; everybody can read its report.

What "built-in" actually means

Plenty of pipelines let you run a validator. That is not the same thing.

The key property is that the asset and its evidence arrive together. A reviewer who wants to know whether an asset is usable reads a report; they do not open a file.

Correctness: the checks that stop the build

Some failures make an asset unusable, and a pipeline should refuse to ship it rather than report it. At Rigyd these are treated as invariants of the export, not as scores:

• One asset, two formats. The OpenUSD and MJCF outputs are checked against each other before anything is delivered, so both simulators see the same object.
• Scale is baked. Unit scale is applied to the geometry rather than left on a transform, so joint frames compose the same way in every runtime.
• The authored pose is legal. Every articulated part starts inside its own joint limits.
• The centre of mass means what the format says. It is placed in the frame OpenUSD expects, so the body balances where it should.
• Z-up and metric. Every asset is normalized before it is scored, so orientation and units are never a per-asset surprise.

If any of these fails, the job fails. There is no partially correct asset to review.

Physics: run it, do not just parse it

A file can be syntactically perfect and physically wrong. The only way to know how an asset behaves is to simulate it.

Two things make the physics trustworthy. The first is where the numbers come from. Density and friction are taken from engineering references for the identified material; mass is built from the geometry rather than assumed solid, so a thin-walled shell weighs what a shell weighs; centre of mass and inertia are derived from the same geometry; collision comes from convex decomposition rather than a bounding box. Our guide to estimating physics properties automatically covers that in detail. Nothing is invented to make a check pass.

The second is testing the result. Every asset is dropped and allowed to settle in a headless MuJoCo run. A hull that penetrates the floor is corrected automatically and the test re-runs. An asset that does not settle does not ship as though it did.

Collision geometry is also where speed is decided. Hulls are kept detailed where the robot manipulates and simplified elsewhere, because hull count is what a physics engine pays for at scale. Our parallel-environment benchmark measured exactly that: a Rigyd Rubik's cube with 310 hulls and six hinges ran 8,192 environments on one A100 in both MuJoCo Warp and Isaac Lab, with no NaN environments in 10,000 steps at 4,096 environments. See collision mesh best practices for how to set that trade-off.

Conformance: score against a public standard

Validation should not be a vendor's private opinion. NVIDIA's SimReady Foundation defines open, testable requirements for simulation-ready OpenUSD content, grouped into features and bundled into profiles that act as a contract between whoever makes an asset and whoever uses it.

Rigyd scores every asset per profile:

Three details separate a useful conformance check from a checkbox:

• The requirements are read from the specification's own metadata, not from a list someone keeps by hand, so the check moves when the standard does. The report names the release it was scored against.
• Non-applicable requirements say so, with a reason. A rigid prop is not failed for lacking joints.
• Non-conformance is reported, not quietly patched. A non-conformant asset can still be a usable one, and you are better served by getting it with a red line in its report than by getting nothing, or by getting something silently altered.

We are keeping the validator current with the latest SimReady Foundation releases so assets stay usable in current versions of Isaac Sim. For the simulator's own expectations, see Isaac Sim asset requirements and best practices.

The report is the review

The validation report is the artifact that replaces manual review. It travels with every asset and answers the questions a reviewer would otherwise answer by hand:

• Which correctness gates the asset passed
• How it behaved in the drop-and-settle test, and whether anything was corrected
• Its status per SimReady profile, with each failing requirement named
• Which requirements did not apply, and why
• Which release of the specification it was scored against

That turns asset intake from inspection into triage. A green asset goes straight into the scene. A red one comes with the exact requirement it missed, so the decision to use it, fix it, or regenerate it takes minutes, not an afternoon in a simulator.

What validation proves, and what it does not

It is worth being precise here, because overclaiming is how teams lose trust in a pipeline.

Validation proves that an asset behaves the way its numbers claim, in simulation: its mass and inertia are consistent with its geometry, its surface values come from material data, it settles stably under gravity, its joints respect their limits, and its formats agree.

It does not prove that a policy trained on the asset will transfer to your robot. That depends on your hardware, your task, and how you measure transfer, and your robot is the only reference that can answer it. For more on where the sim-to-real gap actually comes from, see why physics accuracy matters more than visual fidelity.

Questions to ask any asset pipeline

If you are evaluating a generator, a library, or a contractor for simulation assets, these questions separate built-in validation from a claim:

1. Does validation run before export, or is it something we run afterwards?
2. Is the asset simulated, or only parsed?
3. Are the OpenUSD and MJCF versions checked against each other?
4. Which failures stop the build, and which are reported?
5. Which standard is conformance scored against, and which release?
6. Does the report travel with the asset, and does it say what did not apply?
7. When an asset fails a requirement, is that reported, or silently patched?
8. What does the vendor say validation does not prove?

A pipeline that answers all eight clearly is one your simulation team can stop reviewing.

How Rigyd approaches it

Rigyd generates validated OpenUSD and MJCF SimReady assets from text, images, or existing 3D files. Validation is part of the pipeline, not an add-on: correctness gates stop the build, every asset is drop-and-settle tested in headless MuJoCo, conformance is scored per SimReady Foundation profile, and the report ships with the asset. The point is simple. Your team should be training and testing robots, not opening files to check whether the mug weighs what a mug weighs.