What's covered today

At spec release 2026.08.0 every Rigyd conversion targets one profile, Robotics-Prop, and current output passes it 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. Runtime-specific support — Isaac, PhysX, MuJoCo, Newton — is scored as optional features inside the profile, described below.

Reports scored at 2026.06.0 or earlier name the three profiles that preceded it — Prop-Robotics-Neutral, -Physx and -Isaac — and are not re-scored. See Reports from earlier releases.

What the profile covers

• 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, and invisible colliders marked purpose = "guide" so they don’t render but still simulate.
• SimReady metadata — SR.004: provenance fields in the root layer — author, the source asset’s license, category and Wikidata Q-code — alongside extents, mass and rigid-body count; SR.002: a 256×256 thumbnail at .thumbs/256x256/<name>.usd.png beside the USD file.
• Semantic labels — SL.001–SL.003, SL.MAT.001, SL.QCODE.001, SL.TIME.001: SemanticsLabelsAPI labels on /Root (class and wikidata_qcode) inherited by every renderable prim, a material label on every Material, well-formed Q-codes, and no time samples on label attributes.
• Visual materials, current form — VM.PS.002 (each renderable prim’s material connects a UsdPreviewSurface) and VM.TEX.003 (UsdPreviewSurface colour-space conventions). VM.TEX.002 is deprecated in favour of VM.TEX.005.

The physics-material and grasp checks (PMT.001, GSP.001), the PhysX collider pair and Isaac composition are still checked on every asset; at 2026.08.0 they belong to optional features.

Optional features

Robotics-Prop marks runtime support as optional. An unmet optional feature never fails the profile; its unmet codes are listed in profiles["Robotics-Prop"].optional_unmet, and profiles["Robotics-Prop"].optional_features maps each feature id to its name. A feature is met when none of its codes appears in optional_unmet, so “passes for Isaac” is status === "PASS" with ISA.001 absent from optional_unmet.

Feature	Feature ids	Codes	Today
Isaac	FET_100_ISAAC	ISA.001 (+ PHYSX.COL.001/002)	Met
PhysX	FET_000_PHYSX, FET_003_PHYSX	RV.001–RV.003, RV.010–RV.011, NP.006, SR.001, PHYSX.COL.001–002	Not met — RV.* runtime variants not authored
Newton	FET_000_NEWTON, FET_003_NEWTON	RV.004–RV.006, RV.010–RV.011, NP.006, SR.001, NEWTON.COL.001–002, NEWTON.MAS.001, NEWTON.MAT.001	Not met
MuJoCo	FET_000_MUJOCO, FET_003_MUJOCO	RV.007–RV.009, RV.010–RV.011, NP.006, SR.001, MUJOCO.COL.001–002	Not met
Multi-body	FET_004_STANDARD	JT.001–JT.003, JT.ART.002–JT.ART.004, RB.MB.001	N/A on a single-body prop; checked on articulated ones
MDL	FET_006_MDL	VM.BIND.002, VM.MDL.001–VM.MDL.003, VM.TEX.005	Not met — VM.MDL.003, VM.TEX.005

The profile also lists OpenPBR, display colour, non-visual materials and grasp as optional features; their codes appear in optional_unmet the same way. On today’s delivered props optional_unmet holds 32 codes, all from those features and the PhysX, Newton, MuJoCo and MDL rows above.

This asset still runs in MuJoCo

An unmet MuJoCo feature means the USD does not carry the MuJoCo-specific schemas and runtime variant the specification defines. It does not describe the MJCF package we ship beside the USD, which is a separate file built for MuJoCo directly.

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 PhysX and Isaac Sim 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, and so do parts that fit another part (a battery slot’s walls, a connector’s nose), which are also decomposed one at a time so no hull bridges the opening between them. 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 sixteen profiles are scored on every conversion, not just the one we target — the ones we do not target are the only thing that says what is left to do. This is a delivered prop at spec release 2026.08.0; a rigid upload and an articulated composition score the same:

Profile	Requirements	Status	Unmet
Robotics-Prop (targeted)	97	PASS	— (32 optional-feature codes in optional_unmet)
Robot-Body	114	PASS	— (56 in optional_unmet)
Robot-Gripper	118	PASS	— (59 in optional_unmet)
Package-Candidate	3	PASS	—
Package	6	INCOMPLETE	5 unwritten
Package-NoBOM	5	INCOMPLETE	4 unwritten
Open-Taxonomy-COCO · -Cityscapes · -ADE20K · -PascalVOC · -SUNRGBD · -ImageNet1K	13 each	INCOMPLETE	1 unwritten each — the dataset-vocabulary rule (COCO.001, …)
Sensor-IMU · -Joint · -Camera · -LiDAR	1 · 1 · 6 · 4	INCOMPLETE	all 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.

Passing Robot-Body does not make a prop a robot

Robot-Body and Robot-Gripper report PASS on a plain prop because, at 2026.08.0, their required checks are a subset of Robotics-Prop’s; driven joints, robot schema and gripper sites are optional features in both. So profiles_passing lists Package-Candidate, Robot-Body, Robot-Gripper and Robotics-Prop. Do not present the first three as achievements or as a claim about what the asset is. Headline targeted_profiles, and show any other profile only with its not_targeted_because — for Robot-Body that is the fact that our joints are passive, with no drive or motor.

VG.001 still misfires, outside every profile

Our VG.001 rule (“assets must contain at least one imageable geometry”) counts meshes that are not colliders. Under the default sdf variant the visual mesh is itself the collider, so the count comes out zero on an asset that plainly renders. At 2026.08.0 no published profile requires VG.001, so the check reports N/A with na_reason: "not-in-profile", but its measured_status is still ERROR. It is a defect in our check and it is on the fix list.

Status is per profile, always

The same requirement can be a different answer under different profiles, and a requirement outside every profile we target reports N/A with na_reason: "not-in-profile" in the top-level checks[]. 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. The Open-Taxonomy and Sensor profiles are INCOMPLETE for the same reason: we label in our own category list plus Wikidata, not in COCO or ADE20K vocabularies, and a prop is not a sensor.

`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 (the prop profiles before 2026.08.0) 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 at 2026.06.0, 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.

At 2026.08.0 RB.MB.001 belongs to the optional multi-body feature of Robotics-Prop, so it can no longer block the profile in either tool. We keep the N/A on single-body props so the code does not appear in optional_unmet for a feature that does not apply.

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. At 2026.06.0 both verification assets agreed across all three Prop profiles, with RB.MB.001 above the single known and intentional exception. At 2026.08.0 the comparison ran on 25 assets (15 uploaded models, 10 compositions): every one passes Robotics-Prop 4.0.0 in both tools, with no real disagreement and no errors. It is re-run each time the pin moves.

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.