What's covered today

Every Rigyd conversion targets the Prop-Robotics-Neutral profile, and passes it: rigid-body props built for robotics simulation, runtime-neutral so they drop cleanly into Isaac Sim, Isaac Lab, MuJoCo, Gazebo, or any other OpenUSD-aware simulator.

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, invisible colliders marked purpose = "guide" so they don’t render but still simulate.
• Physics materials and grasp — friction and restitution bound on every collider, and a grasp vector for manipulation planning.

What a delivered asset scores

All nine 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 representative rigid prop:

Profile	Requirements	Status	Unmet
Prop-Robotics-Neutral (targeted)	50	PASS	—
Prop-Robotics-Physx	51	FAIL	COL.001
Prop-Robotics-Isaac	29	FAIL	COL.001 · ISA.001 · RB.MB.001
Robot-Body-Neutral	30	FAIL	RB.MB.001
Robot-Body-Runnable	42	FAIL	RB.MB.001
Robot-Body-Isaac	52	FAIL	COL.001 · ISA.001 · RB.MB.001
Package	6	INCOMPLETE	—
Package-NoBOM	5	INCOMPLETE	—
Package-Candidate	2	INCOMPLETE	—

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.

Status is per profile, always

The same requirement is a different answer under different profiles. COL.001 is not part of Prop-Robotics-Neutral, so it reports N/A there with na_reason: "not-in-profile" — while Prop-Robotics-Physx requires it and records it as a genuine FAIL. 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 two we knowingly fail

Prop-Robotics-Physx and Prop-Robotics-Isaac are Prop-Robotics-Neutral plus these, and nothing else:

Code	What it asks for	Why we don’t meet it yet
COL.001	SDF collision approximation	We author convex-hull colliders. Moving to SDF changes contact behaviour for every asset already delivered, so it is an acceptance run of its own, not a flag flip.
ISA.001	Isaac composition layout	We ship one flattened USD. Isaac composition is a packaging architecture — kind='component', a payloads/ tree, the asset split into _base.usd + _physics.usd — rather than stricter physics.

Both are scheduled work. They appear in failing[] and in failing_deferred[], which is a subset rather than a replacement: the profile still fails and the requirement is still unmet. deferred_reasons carries the reason for each. Rendering deferred failures in a quieter style is the intended use — do not hide them.

Where we disagree with NVIDIA’s own validator

Exactly one place, deliberately.

NVIDIA’s profiles.toml marks the multi-body feature “(This is an optional feature for this profile)” under Prop-Robotics-Neutral and Prop-Robotics-Physx, and marks nothing of the sort under Prop-Robotics-Isaac. That sentence is a TOML comment, and their own tool parses the file with a reader that discards comments — so their validator reports every single-body prop as failing RB.MB.001 (“asset contains at least two rigid bodies”), which is simply what a prop is.

The spec text is the authority, so we honour it. RB.MB.001 lands in optional_unmet rather than failing, and optional_features quotes their sentence verbatim so you can check the reading yourself. Not satisfying an optional feature is less capability, not non-conformance.

Under Prop-Robotics-Isaac, where nothing is marked optional, the same requirement is a real FAIL — which is exactly why status is per profile.

Two instruments, one answer

Ours is a fast, offline pre-flight instrument that runs on every conversion. NVIDIA’s is the authority. 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, the two agree exactly, 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.

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