What's covered today

Every Rigyd conversion targets three profiles — Prop-Robotics-Neutral, Prop-Robotics-Physx and Prop-Robotics-Isaac — and current output passes all three with zero errors. This includes both rigid and articulated simulation props: runtime-neutral enough to use in Isaac Sim, Isaac Lab, MuJoCo, Gazebo, or another OpenUSD-aware simulator, with PhysX collider and Isaac composition layers on top.

What the profiles cover

• Stage-level conformance — defaultPrim, upAxis = Z, metersPerUnit = 1.0, kilogramsPerUnit, and a single root UsdGeomXform.
• Naming and on-disk layout — prim, file, and folder names that survive a round-trip through Linux, Windows, and the Omniverse Nucleus path resolver, with no absolute paths in references.
• Geometry — valid topology, indexed primvars, consistent face winding, normals on non-subdivided meshes, points within 32-bit float precision, and sane RTX world-space bounds.
• Visual materials — UsdPreviewSurface bindings that resolve, texture colour spaces set correctly, dimensions within RTX limits.
• Rigid-body physics — UsdPhysics RigidBodyAPI and MassAPI applied correctly, mass and inertia coherent with collision volume, no skewed transforms.
• Collision — CollisionAPI and MeshCollisionAPI on the right prims, invisible colliders marked purpose = "guide" so they don’t render but still simulate, and the PhysX structural pair PHYSX.COL.001 / PHYSX.COL.002.
• Physics materials and grasp — friction and restitution bound on every collider, and a grasp vector for manipulation planning.
• Isaac composition — ISA.001: the asset is a kind = "component" entry point composing a payloads/ tree rather than one flattened file.

Colliders: two, and you pick

/Root carries a collision_mode variantSet with two variants:

Variant	Geometry	Use it when
sdf (default selection)	A signed-distance field over the visual mesh itself	You are running PhysX on GPU. This is what the PhysX and Isaac profiles ask for, and it gives stable contact on fine features.
convexHull	The convex decomposition (CoACD hulls under /Root/Collisions)	You are running CPU dynamics, or any runtime without SDF support — PhysX simulates SDF colliders on GPU only.

The hull geometry itself is authored outside the variantSet, so a viewer can draw /Root/Collisions/* with no variant selection and no payload support. Only the physics opinions are variant-scoped. The SDF variant costs no extra geometry: its collider is an internal reference to /Root/Visual, so the points are stored once and resolve through composition.

For articulated assets, collision detail follows each part’s declared role. Graspable surfaces receive the finest SDF resolution, structural parts use the measured default, and incidental contact can use a smaller budget. Decorative parts remain in the visible model but are excluded from mass and collision generation. This keeps handles and controls precise without spending the same collision budget on trim.

The asset is composed, not flattened

usd/<name>.usd references payloads/<name>_base.usd (which references <name>_meshes.usd) and payloads payloads/<name>_physics.usd. Opening the entry-point file without its payloads/ siblings gives you an empty stage — keep the directory together, and your download ships all of it. Collision geometry and the collision_mode variantSet live in the physics layer, which is exactly the part a render-only consumer can defer.

What a delivered asset scores

All nine profiles are scored on every conversion, not just the three we target — the ones we do not target are the only thing that says what is left to do. This is a representative delivered prop at spec release 2026.06.0:

Profile	Requirements	Status	Unmet
Prop-Robotics-Neutral (targeted)	50	PASS	—
Prop-Robotics-Physx (targeted)	52	PASS	—
Prop-Robotics-Isaac (targeted)	37	PASS	—
Robot-Body-Neutral	37	INCOMPLETE	4 driven-joint rules unwritten
Robot-Body-Runnable	48	INCOMPLETE	13 unwritten
Robot-Body-Isaac	48	FAIL	VG.001, plus 20 unwritten
Package	6	INCOMPLETE	5 unwritten
Package-NoBOM	5	INCOMPLETE	4 unwritten
Package-Candidate	2	INCOMPLETE	SR.002 unwritten

Each entry in report.validation.profiles carries a one-line note describing where a passing asset can be used, plus targeted and — when we do not aim at it — not_targeted_because.

The one FAIL above is ours, not the asset's

Robot-Body-Isaac is the only profile that pulls in VG.001 (“assets must contain at least one imageable geometry”). Our rule counts meshes that are not colliders — and under the default sdf variant the visual mesh is itself the collider, so the count comes out zero on an asset that plainly renders. It is a defect in our check, scoped to a profile we do not target, and it is on the fix list. If you are reading Robot-Body-* verdicts, read them with that in mind.

Status is per profile, always

The same requirement is a different answer under different profiles. ISA.001 is not part of Prop-Robotics-Neutral, so it reports N/A there with na_reason: "not-in-profile" — while Prop-Robotics-Isaac requires it and records a real PASS. If you re-score anything yourself, read checks[].measured_status (the raw finding) rather than checks[].status (what to act on, given the profiles we target).

PASS and INCOMPLETE are different claims

Status	Means
PASS	Every requirement in the profile was checked, and none failed
FAIL	At least one requirement failed — failing[] names them
INCOMPLETE	Nothing failed, but some requirements have no rule written yet — unchecked[] names them

INCOMPLETE is not a soft pass. It means we do not know. PASS is a claim about what we checked, so we only make it when we checked all of it — the Package profiles above report INCOMPLETE because they describe a distribution package rather than a single asset file, and we have a rule for only one of their requirements.

`failing_deferred` is empty now, and the field stays

failing_deferred[] and deferred_reasons marked failures that were a decision with an owner rather than a surprise. Both held COL.001 and ISA.001; both shipped in August 2026, so both fields are now empty on every conversion. They remain in the schema — a future deferral would use them again — so keep handling them, and keep treating anything they contain as a genuine failure rather than hiding it.

Where we disagree with NVIDIA’s own validator

Exactly one place, deliberately, and it is a reading of their prose rather than of their tooling.

RB.MB.001 asks that an asset contain at least two rigid bodies. A prop has one. NVIDIA’s own profile pages for Prop-Robotics-Neutral and -Physx carry a section headed “Multi-body physics (conditional)” which settles it:

Single-rigid-body props are valid for this profile when they satisfy FET003_BASE_NEUTRAL. […] For props with exactly one rigid body, multi-body physics is not applicable and must not block profile conformance.

Their validator does not read that clause. Measured on our verification asset, it fails Prop-Robotics-Neutral on RB.MB.001 while passing Prop-Robotics-Physx and -Isaac, which reach the same feature through a dependency it does not evaluate — so the tool contradicts both their prose and itself. The prose is the authority, so we honour it: on an asset stamped as a Prop, RB.MB.001 reports N/A with na_reason: "not-applicable-to-asset" and the sentence quoted in the message.

The exemption is narrow. A multi-body asset gets a real answer either way, and an articulated asset that somehow shipped a single body still fails — this is for props that are single-body by design, not for a plan that collapsed.

Two instruments, one answer

Ours is a fast, offline pre-flight instrument that runs on every conversion. NVIDIA’s is the authority, and we run their simready-validate wheel at the version matching the spec release we score against. Where they disagree, theirs is right and ours is the bug — that is how four of our own checks were found to be wrong. Verified on both verification assets across all three Prop profiles, with RB.MB.001 above the single known and intentional exception.

Warnings are advisory

counts.warnings never affects a profile verdict — ours counts only errors against a profile, and NVIDIA’s filters to errors before computing a pass. Label warnings advisory if you surface them, and don’t let them colour a pass/fail badge.

One warning appears on essentially every asset and is expected: VG.MESH.001 wants all geometry to be non-subdivided meshes, while GSP.001 requires the grasp vector to be a BasisCurves line. Those two requirements cannot both be satisfied literally. NVIDIA’s validator raises the same warning on the same assets.

For the per-requirement status of every code in the registry, see Full requirement coverage.