Overview

Every asset that comes out of a Rigyd conversion is scored against the SimReady Foundation specification, and the result ships with the asset in report.validation.

If you have ever opened a USD in Isaac Sim and watched it fall through the floor, intersect itself, or refuse to articulate, you already know what this is for. Validation is the line between “loads in a viewer” and “drops into a simulator and behaves.”

Conformance is reported, never enforced

A conformance failure does not fail your job or affect billing. The asset is delivered either way, with the report attached.

That is deliberate. A non-conformant asset is still a usable asset, and you are better served by getting it with a red report than by getting nothing. Conformance describes our output against someone else’s specification; it is a description, not a gate.

What does fail a conversion is a different class of problem entirely — a statement about our own correctness rather than about the spec:

Fails the job	Why
USD/MJCF parity disagreement	The two files we hand you must describe one asset
An internal invariant violation	e.g. the centre of mass does not resolve to the point we declared for it
A missing or unwritable export	There is no asset to deliver
A rejected input manifest	The description does not match the mesh

When one of those trips, the conversion goes to failed and error is populated. A failed paid conversion refunds its recorded conversion charge once. Uploaded and authored conversions are priced separately. If Asset Composer created the prototype, its earlier generation charge is separate and is not reversed by a later conversion failure. A completed job always has a downloadable asset, whatever its conformance verdict.

What we conform to

The SimReady Foundation is an open specification layer on top of OpenUSD that defines what a simulation-ready asset must contain — naming and folder structure, units, hierarchy, geometry, visual and non-visual materials, semantic labels, rigid-body and collision physics, joints and articulation, and runtime-specific requirements for PhysX, NVIDIA Isaac Sim, MuJoCo and Newton.

The foundation groups requirements into features and rolls features up into profiles — concrete bundles you can target. Rigyd’s validator does not keep its own list of requirements: the profile → feature → requirement map is joined at runtime from NVIDIA’s published metadata, so a requirement that moves between features, or a profile that gains one, moves here without anybody transcribing it.

We are not an authority on SimReady — NVIDIA is. Every check traces to a requirement they define.

Scored against spec release 2026.08.0

report.validation.spec_release names the release every verdict is scored against. We are pinned to 2026.08.0, the current SimReady Foundation release, and check our answers against NVIDIA’s own simready-validate wheel at the matching version (2026.8.0): on our 25 verification assets (15 uploaded models, 10 compositions) both report Robotics-Prop 4.0.0 passing, with no real disagreement. Older reports name 2026.06.0 or, before 19 August 2026, 2026.04.1. The field is on every report so an older verdict never has to be guessed at — see Reports from earlier releases.

Reading the result

Scoring is per profile, and the same requirement is a different answer under each one. There is no single global verdict that means anything.

The profiles to headline are targeted_profiles — at 2026.08.0 that is one, Robotics-Prop (profile version 4.0.0, in profiles["Robotics-Prop"].version) — read through each one’s status:

const v = job.report.validation;

for (const name of v.targeted_profiles) {          // ["Robotics-Prop"]
  const p = v.profiles[name];
  badge(`SimReady ${name}: ${p.status}`);           // "PASS" | "FAIL" | "INCOMPLETE"
}

profiles_passing is not a list of achievements

At 2026.08.0 a plain prop also passes Robot-Body, Robot-Gripper and Package-Candidate, so profiles_passing reads ["Package-Candidate", "Robot-Body", "Robot-Gripper", "Robotics-Prop"]. That is not a claim that the asset is a robot or a gripper: in this release those profiles’ required checks are a subset of Robotics-Prop’s, and everything that makes a robot a robot — driven joints, robot schema — sits in their optional features. Headline only targeted_profiles. If you show other profiles at all, show them with their not_targeted_because, which says why we do not aim at them.

report.validation.overall still exists, but it is scoped to the profiles we target and is not a conformance claim about any particular one. It can be WARN while every targeted profile is PASS, because advisory findings remain visible.

Optional features: Isaac, PhysX, MuJoCo, Newton

Robotics-Prop is runtime-neutral. Runtime support is expressed as optional features inside it: an unmet optional feature never fails the profile, and its unmet requirement codes are listed in profiles["Robotics-Prop"].optional_unmet, with the feature ids and names in profiles["Robotics-Prop"].optional_features. “Passes for Isaac” therefore means two things together:

const rp = v.profiles['Robotics-Prop'];
const isaacReady = rp.status === 'PASS' && !rp.optional_unmet.includes('ISA.001');

The feature-to-code map is on What’s covered today. Today Isaac is met; PhysX, Newton, MuJoCo and MDL are not, because their runtime-variant (RV.*) and runtime-specific collider codes are not authored yet.

Where a Rigyd asset lands today

Rigyd produces simulation props made from one or more rigid bodies. They may be rigid or articulated, and the automated composition endpoint supports both. Every prop, rigid or articulated, targets Robotics-Prop, and current output passes it with zero errors and the Isaac optional feature met.

To pass Robotics-Prop, every asset now also carries SimReady provenance metadata (SR.004), a thumbnail (SR.002), a category with a Wikidata Q-code, and SemanticsLabelsAPI labels on /Root and on every material. The report exposes what was written — see Retrieve a job.

Two earlier changes from August 2026 are what made the Isaac answer possible:

• Colliders. The USD carries a collision_mode variantSet on /Root with two variants — sdf (the default selection, a signed-distance field over the visual mesh, which is what PhysX and Isaac Sim ask for) and convexHull (the convex decomposition, which is what a CPU-dynamics scene can actually run, since PhysX simulates SDF colliders on GPU only). The file states both; you pick.
• Composition. The asset is no longer one flattened file. usd/<name>.usd is kind = "component" and composes payloads/<name>_base.usd (which references <name>_meshes.usd) plus a deferred payloads/<name>_physics.usd. Load base + meshes for a render-only view; the payload brings the physics.

Keep the `usd/` directory together

usd/<name>/<name>.usd is an entry point, not the whole asset: opening it without its payloads/ siblings gives you an empty stage. Your download ships the complete tree — see Download result — so unzip it and point your loader at the root layer, don’t extract a single file.

skip_validation no longer does what its name suggests

The skip_validation field is still accepted on the 3D → SimReady request, but it no longer skips conformance scoring. Every conversion is scored and every completed job carries a report.validation block, whether you send it or not.

On this route it only stops invariant findings from rejecting the job. It does not bypass required exports, and the authored articulated path always enforces USD/MJCF parity and articulation invariants. Leave it unset unless Rigyd support asks you to use it.

Reports from earlier releases

Jobs are not re-scored. A report keeps the profile names of the release it was scored against, so stored reports come in two shapes:

spec_release	profile	targeted_profiles / profiles_passing
2026.08.0	Robotics-Prop	["Robotics-Prop"] / see the caution above
2026.06.0, 2026.04.1	Prop-Robotics-Neutral (Articulated-Robotics-Neutral on some older authored jobs)	Prop-Robotics-Neutral, -Physx, -Isaac

Articulated-Robotics-Neutral was never a SimReady profile; it only appears on old reports. Branch on spec_release or read targeted_profiles, and never hard-code a profile name. Reports from before 2026.08.0 also lack the metadata, label and thumbnail fields; treat an absent field as not recorded.

Where to go next

• What’s covered today — the profile we target, its optional features, what a delivered asset scores against each profile, and the one place we read the specification differently from NVIDIA’s own tool.
• What’s coming next — how our coverage tracks the foundation’s published profile families.
• Full requirement coverage — all 202 requirement codes at 2026.08.0 and our status against each.