What's coming next

The SimReady Foundation specification is itself young — the team’s stated position is that it “currently covers basic static props (ones that don’t move or articulate)”, with the broader profile set being filled in as the foundation grows. Rigyd’s coverage moves with it.

Where we are

At spec release 2026.08.0 the foundation folds the three prop profiles into one, Robotics-Prop, and moves runtime support into optional features inside it. Rigid and articulated conversions target it, and current output passes it with the Isaac feature met. Everything below is what it would take to claim the next feature or profile: named requirements, not aspirations.

Delivered for 2026.08.0, and no longer planned: SimReady provenance metadata including the source asset’s license (SR.004), a thumbnail (SR.002), a category with a Wikidata Q-code (SL.QCODE.001), and SemanticsLabelsAPI labels on /Root and every material (SL.001–SL.003, SL.MAT.001, SL.TIME.001).

Profile family	Foundation profiles	Rigyd
Props	Robotics-Prop	Live — targeted and passing
	↳ Isaac feature	Live — met
	↳ PhysX · Newton · MuJoCo features	Next — needs runtime variant sets (RV.001–RV.011) and the Newton and MuJoCo collider schemas
	↳ MDL feature	Next — VM.MDL.003, VM.TEX.005
Robots	Robot-Body · Robot-Gripper	Scored PASS, not targeted — a prop is not a robot; see below
Packaging	Package · -NoBOM · -Candidate	Scored; Package and -NoBOM report INCOMPLETE, -Candidate passes. These describe a distribution package rather than a single asset file
Open taxonomies	Open-Taxonomy-COCO · -Cityscapes · -ADE20K · -PascalVOC · -SUNRGBD · -ImageNet1K	Scored, INCOMPLETE. We label in our own category list plus Wikidata; mapping onto a dataset vocabulary is not planned yet
Sensors	Sensor-IMU · -Joint · -Camera · -LiDAR	Scored, INCOMPLETE. These describe sensor assets, not props

The two requirements that used to block PhysX and Isaac

Both shipped in August 2026. They are recorded here because reports issued before then name them as failures, and because the shape of what changed matters if you built against the old output. At 2026.08.0 both belong to optional features of Robotics-Prop — the PhysX collider pair to the PhysX and Isaac features, ISA.001 to Isaac — and both are still authored and checked on every asset.

• SDF collision approximation. We authored convex-hull colliders only. The USD now carries a collision_mode variantSet on /Root — sdf selected by default, convexHull still present and still authored outside the variantSet so a plain viewer can draw the hulls. Nothing was taken away; a second answer was added, and it is the one the PhysX and Isaac profiles ask for.

  At spec release 2026.06.0 the code that asked for this, COL.001, was dropped from every prop profile in favour of the structural pair PHYSX.COL.001 / PHYSX.COL.002. We still author SDF regardless — the requirement still exists, is still tagged essential, and Isaac’s own prose still instructs physics:approximation = "sdf" under a heading marked (required).

• ISA.001 — Isaac composition layout. We shipped one flattened USD. The asset is now a kind = "component" entry point composing payloads/<name>_base.usd → <name>_meshes.usd, with physics deferred behind payloads/<name>_physics.usd. Collision geometry and the collision variantSet live in the physics layer, so a render-only consumer can skip them.

If you address a single USD file, that changed

Before the composition work, usd/<name>.usd was the whole asset. It is now an entry point that composes its payloads/ siblings, and opening it on its own yields an empty stage. Consume the directory, not the file — Download result shows the tree your archive contains.

Articulation

The pipeline builds articulated assets — ArticulationRootAPI, UsdPhysics revolute and prismatic joints with real limits, per-link mass and inertia — and scores them exactly like rigid props. Request one with POST /api/compositions/generate by setting asset_class: "articulated"; set auto_submit: true to continue directly into SimReady conversion.

Articulated assets are scored with the same requirement set as everything else. There is no separate articulated profile in the specification and no separate family of codes on our side; joint and articulation requirements are simply part of the registry, and an asset either meets them or does not:

	Status
JT.001–JT.003, JT.ART.001–JT.ART.004 (joints, articulation roots)	Checked
BA.001 (at least one ArticulationRootAPI)	Checked
BA.002 (non-adjacent colliders don’t clash at the default pose)	Planned — needs a simulation step a structural validator doesn’t run
HI.009 (hierarchy reflects the kinematic chain)	Planned

A correction, if you built against an earlier version of this page

This page previously described articulation support in terms of an AR.* family of codes and a profile called Articulated-Robotics-Neutral. Neither exists in the SimReady specification. They were ours: sixteen invented codes under a profile name that was never published, and routing articulated assets to them meant those assets skipped every naming, packaging, material, texture and path check in the real registry. They are gone, and articulated assets are now scored against NVIDIA’s requirements like everything else. The name can still appear as profile on reports from older authored jobs, which are not re-scored; branch on spec_release rather than on the name.

Robot bodies

A robot body is a different product from a manipulable prop: it needs driven joints — actuated joints carrying drive specifications and joint-state APIs. Rigyd’s joints are passive: damping and friction sourced from real mechanism profiles, with no target or motor.

At 2026.08.0 the Robot-Body-Neutral, -Runnable and -Isaac profiles became one Robot-Body profile (114 requirements), joined by Robot-Gripper (118). In both, driven joints, robot schema and gripper sites are optional features, and the required checks are a subset of Robotics-Prop’s. A delivered prop therefore reports PASS on both, with 56 and 59 codes in their optional_unmet — the DJ.* driven-joint and RC.* robot-core rules among them. That PASS is not a claim that the asset is a robot, which is why neither profile is targeted and each carries a not_targeted_because. See What’s covered today.

Tracking the specification itself

We validate against spec release 2026.08.0, the current SimReady Foundation release, and check against NVIDIA’s own validator at the matching wheel version (simready-validate 2026.8.0) so every verdict of ours can be checked against theirs. The pin moved from 2026.04.1 to 2026.06.0 in August 2026, and from 2026.06.0 to 2026.08.0 with SimReady 2026.08.0 — each time only once a working wheel was published, because validating against a release we cannot run their tool on would mean we could no longer check our answers.

Moving the pin is a deliberate act with a checklist: re-vendor their metadata, diff the requirement set, re-run the verification assets through our validator and theirs. 2026.06.0 added four requirement codes (140, up from 136), swapped COL.001 for the PHYSX.COL.* pair in the prop profiles, and turned the “optional feature” marker from a TOML comment into a real field. 2026.08.0 added 66 codes and removed four (202, up from 140), replaced the three Prop-Robotics-* profiles with Robotics-Prop, merged Robot-Body-* into Robot-Body, and added the Robot-Gripper, Open-Taxonomy-* and Sensor-* profiles. A new requirement we fail is a report change, not an emergency, because conformance never fails a job.

report.validation.spec_release always names the release a given verdict was scored against, so a report never has to be guessed at after the fact. Stored jobs are not re-scored when the pin moves.

When the foundation publishes additional profiles — vehicles, characters, environments, all signposted as future work in the SimReady overview — our coverage tracks them. The profile map is joined from their metadata rather than transcribed, so adding a profile means adding a target, not rewriting the engine.