Full requirement coverage

Every requirement in the SimReady Foundation registry at release 2026.08.0 — 202 codes — with what Rigyd does about each. The list is generated from NVIDIA’s own published metadata, vendored verbatim, so a code appears here if and only if it appears in their specification.

Codes that used to be listed here

Earlier versions of this page listed VG.034 and VM.D.001. Neither exists in the SimReady specification — they were ours, and they read like requirement IDs, which is exactly what was wrong with them. They have been removed, along with a family of AR.* codes that scored articulated assets under a profile name that was never published. If you reference either by code, they are gone. (RC.002 was also removed for the same reason and has since reappeared for a real one: release 2026.06.0 defines it. It is listed below, on NVIDIA’s authority rather than ours.) Release 2026.08.0 itself removed the specification’s worked example EX.001–EX.003 and renamed SL.NV.002 to SL.TIME.001; none of those old codes appears in current reports. See the changelog.

How to read this

Profiles — which published profiles pull the requirement in:

Tag	Profile
Prop	Robotics-Prop, as a required code — targeted, and passing
Prop opt: feature	Robotics-Prop, only through the named optional feature(s); see optional features
Body	Robot-Body, required or optional
Grip	Robot-Gripper, required or optional
Pkg	the Package* family
Tax	the Open-Taxonomy-* family
Sen	the Sensor-* family
—	in the registry, but no published profile requires it

Rigyd — whether we have a rule for it:

Value	Meaning
Checked	A rule runs on every conversion. Reports PASS, WARNING, ERROR, or N/A with na_reason: "not-applicable-to-asset" when the requirement is required but vacuous — an untextured asset and a texture colour-space rule, say.
Planned	No rule written yet. If a placeholder check exists it reports N/A with na_reason: "planned"; otherwise the code appears in each relevant profile’s unchecked[], or in optional_unmet[] when only an optional feature asks for it. A planned required code makes that profile INCOMPLETE rather than passing it; a planned optional code leaves its feature unmet.

A requirement outside every profile we target additionally reports N/A with na_reason: "not-in-profile" in the top-level checks[], with the raw finding preserved in measured_status. Those three values are the whole na_reason vocabulary — nothing else appears, and neither instrument may extend it.

Of the 202 codes, 93 are checked and 109 are planned. Robotics-Prop pulls in 97: all 46 of its required codes are checked, which is what lets it report PASS rather than INCOMPLETE, and 19 of the 51 codes reached only through its optional features are checked.

Registry size and report check count differ

The registry contains 202 codes. A current conversion report contains 136 unique entries in checks[]; the remaining 66 — the runtime-variant, MuJoCo, Newton, OpenPBR, display-colour, gripper, sensor, taxonomy and PKG.* codes among them — have no top-level rule record yet. They are not treated as passes: profile scoring lists them in unchecked[] (making that profile INCOMPLETE) or, when only an optional feature asks for them, in optional_unmet[].

A code can be checked without being in any profile

COL.001 (SDF collision approximation) is tagged ”—” below: at 2026.06.0 NVIDIA dropped it from every prop profile in favour of PHYSX.COL.001 / PHYSX.COL.002. We still author SDF colliders and still check it, because the requirement still exists and Isaac’s own documentation still instructs it. A ”—” means no published profile requires the code, not that we ignore it.

Naming & paths (NP)

Code	Requirement	Profiles	Rigyd
NP.001	Prims shall follow consistent naming conventions	—	Checked
NP.002	USD files shall follow consistent naming conventions	Prop · Body · Grip · Tax	Checked
NP.003	Asset directories shall use consistent naming and logical organization	Prop · Body · Grip · Tax	Checked
NP.004	File and directory paths shall not exceed platform limits	Prop · Body · Grip · Tax	Checked
NP.005	Assets must follow a specific folder structure with the asset name as the root folder	Prop · Body · Grip · Tax	Checked
NP.006	Asset metadata must be stored in the USD file or a sidecar JSON file	Prop opt: MuJoCo, Newton, PhysX · Body · Grip · Tax	Checked
NP.007	All references must use relative paths	Prop · Body · Grip · Tax	Checked
NP.008	All asset, reference, and payload paths must resolve to files that exist	Prop · Body · Grip · Tax	Checked

Atomic asset (AA)

Code	Requirement	Profiles	Rigyd
AA.001	Asset references should use anchored paths	Prop · Body · Grip · Pkg	Checked
AA.002	Asset must use only supported file types	Prop · Body · Grip	Checked
AA.OV.001	Texture UDIMs are not supported in USDZ files in NVIDIA Omniverse	—	Checked

SimReady metadata (SR)

Code	Requirement	Profiles	Rigyd
SR.001	The asset stage must contain all required metadata fields in root-layer customLayerData	Prop opt: MuJoCo, Newton, PhysX · Body · Grip · Tax	Checked
SR.002	The SimReady asset file should contain a thumbnail that is representative of the asset	Prop · Body · Grip · Pkg	Checked
SR.003	Required SimReady provenance fields must be authored inside the root-layer SimReady_Metadata dictionary	—	Planned
SR.004	Required SimReady provenance fields must be present in the union of USD custom layer data and an optional sidecar JSON file	Prop · Body · Grip · Pkg	Checked

Units (UN)

Code	Requirement	Profiles	Rigyd
UN.001	Stage must specify upAxis to define the orientation of the stage	—	Checked
UN.002	Stage must specify metersPerUnit to define the linear unit scale	—	Checked
UN.003	Stage must specify kilogramsPerUnit to define the mass unit scale, if physics objects are present in the stage	—	Checked
UN.004	Must apply corrective transforms for different units	—	Checked
UN.005	Stage must specify timeCodesPerSecond, if timesamples are present in the stage	—	Checked
UN.006	Stage must specify upAxis = “Z” to define the orientation of the stage	Prop · Body · Grip	Checked
UN.007	Stage must specify metersPerUnit = 1.0 to define the linear unit scale	Prop · Body · Grip	Checked

Hierarchy (HI)

Code	Requirement	Profiles	Rigyd
HI.001	All prims in the hierarchy must be direct or indirect descendents of a single root root prim, preventing scattered or disconnected Xform hierarchies	Prop · Body · Grip	Checked
HI.002	Every UsdGeomGprim must have a parent Xform with specific transform operations and hierarchy constraints	—	Checked
HI.003	The root prim of a hierarchy must be transformable, meaning its’ prim type must inherit from UsdGeomXformable and be capable of receiving transform operations	Prop · Body · Grip	Checked
HI.004	Stage must specify a default prim to define the root entry point	Prop · Body · Grip	Checked
HI.005	Transformations (translate, rotate, scale, pivot) on prims that are intended to be translated, rotated or scaled by users (e.g. the root prim of an asset) should conform to the UsdGeomXformCommonAPI	—	Checked
HI.006	All prims representing distinct objects or groups that require placement, posing or animation shall inherit from UsdGeomXformable	—	Checked
HI.007	This is a placeholder requirement to maintain sequential numbering in the hierarchy requirements	—	Checked
HI.008	Geometry should be grouped under parent Xforms in a way that is logical for the object’s structure and intended use in layouts or simulations	—	Checked
HI.009	For assets (e.g., a robot with multiple articulated joints), the hierarchy should reflect the kinematic chain, with appropriate Xforms for each transformable link	—	Planned
HI.010	Assets must not contain undefined prims (overs)	Prop · Body · Grip · Tax	Checked

Visual geometry (VG)

Code	Requirement	Profiles	Rigyd
VG.001	Assets must contain at least one Imageable Geometry	—	Checked
VG.002	Boundable geometry primitives must have valid extent values	Prop · Body · Grip	Checked
VG.003	Only include geometry that contributes to visualization or simulation	—	Planned
VG.004	Use efficient mesh boundaries for performance	—	Planned
VG.005	Meshes should maintain appropriate scale and boundary volumes	—	Planned
VG.006	Meshes should not overlap unnecessarily	—	Planned
VG.007	Mesh geometry must be manifold	—	Planned
VG.008	Meshes should not share the exact same space	Prop · Body · Grip	Checked
VG.009	Use indexed primvars when values are repeated	—	Checked
VG.010	Use subdivision only when needed for smooth surfaces or displacement	—	Checked
VG.011	Only include primvars that are actively used	—	Checked
VG.012	Combine small meshes into larger ones where appropriate	—	Planned
VG.013	Use appropriate tessellation density for geometry	—	Planned
VG.014	Mesh topology must be valid	Prop · Body · Grip	Checked
VG.015	Use time samples only when attribute values change	—	Checked
VG.016	Each vertex position should be unique	—	Planned
VG.017	Avoid tessellating primitive shapes	—	Checked
VG.018	Mesh topology should be without unused vertices, edges, or faces	—	Planned
VG.019	Faces should have non-zero area	—	Planned
VG.020	The values of points must not exceed the limit at which a given precision can be represented using 32-bit floats	—	Checked
VG.021	Meshes must be triangulated for optimal rendering performance and compatibility when considering automatic collider creation (convex-hull, convex-decomposition, etc…). Triangulating mesh will provide predictable results versus n-gons	—	Checked
VG.022	Transparent physical bodies should be watertight to allow for simulation of light transmission and refraction	—	Planned
VG.023	Meshes should be positioned with xform ops rather than by “baking” transformations into point positions	—	Checked
VG.024	Repeated occurrences of identically shaped objects should have identical mesh connectivity	—	Planned
VG.025	Geometry shall be defined as such that the asset is correctly positioned and oriented at the origin (0,0,0)	Prop · Body · Grip	Checked
VG.026	The pivot point of an asset should be positioned logically: at the center of the object’s base for ground plane objects, and at the center of rotation for objects that rotate around specific points	—	Planned
VG.027	All non-subdivided meshes must have normals	Prop · Body · Grip	Checked
VG.028	Mesh normals values must be valid to produce correct shading	Prop · Body · Grip	Checked
VG.029	The winding order of faces in a mesh must correctly represent the orientation (front/back) of the face	Prop · Body · Grip	Checked
VG.MESH.001	All geometry shall be represented as non-subdivided mesh primitives using the UsdGeomMesh schema	Prop · Body · Grip	Checked
VG.RTX.001	World space bounds must not exceed RTX limit	—	Checked

Display colour (DISP)

Code	Requirement	Profiles	Rigyd
DISP.001	Every renderable geometry prim must resolve a display colour, authored on the prim or inherited from an ancestor	Prop opt: Display color · Body · Grip	Planned
DISP.002	Authored display colour values must lie within the range a consumer can interpret	Prop opt: Display color · Body · Grip	Planned
DISP.003	Display opacity, where authored, must lie within its valid range and agree with its declared interpolation	Prop opt: Display color · Body · Grip	Planned

Visual materials (VM)

Code	Requirement	Profiles	Rigyd
VM.BIND.001	A material binding inside a payload must target a material inside that payload	Prop · Body · Grip	Checked
VM.BIND.002	Shader inputs must use the type their specification declares and hold a finite value	Prop opt: MDL, OpenPBR · Body · Grip	Checked
VM.MAT.001	Each renderable GPrim must have a computed material bound to it	Prop · Body · Grip	Checked
VM.MDL.001	An MDL shader’s info:mdl:sourceAsset must name an existing .mdl file by an anchored path	Prop opt: MDL · Body · Grip	Checked
VM.MDL.002	An MDL shader must use the current schema attributes, not the deprecated mdlMaterial form	Prop opt: MDL · Body · Grip	Checked
VM.MDL.003	A renderable GPrim’s material must connect an MDL surface on outputs:mdl:surface	Prop opt: MDL · Body · Grip	Planned
VM.PBR.001	A renderable GPrim’s material must provide a physically based final surface	Prop opt: OpenPBR · Body · Grip	Planned
VM.PBR.002	OpenPBR input attributes must hold values within their defined min/max	Prop opt: OpenPBR · Body · Grip	Planned
VM.PBR.003	Shader ids must name a declared node, connections must have an existing target, and the material must connect a surface terminal	Prop opt: OpenPBR · Body · Grip	Planned
VM.PS.001	UsdPreviewSurface inputs must use the types and token values the specification declares	Prop · Body · Grip	Checked
VM.PS.002	A renderable GPrim’s material must connect a UsdPreviewSurface on outputs:surface	Prop · Body · Grip	Checked
VM.TEX.001	Texture dimensions must not exceed 16,384 pixels on either axis	Prop · Body · Grip	Checked
VM.TEX.002	Deprecated. See VM.TEX.005 for the current requirement	—	Checked
VM.TEX.003	UsdPreviewSurface materials and textures must use correct color space conventions	Prop · Body · Grip	Checked
VM.TEX.004	OpenPBR materials and textures must use correct color space conventions	Prop opt: OpenPBR · Body · Grip	Planned
VM.TEX.005	MDL materials and textures must use correct color space conventions	Prop opt: MDL · Body · Grip	Planned

Non-visual materials (NVM)

Code	Requirement	Profiles	Rigyd
NVM.001	Materials must specify additional “non-visual” material attributes	Prop opt: Non-visual materials	Planned
NVM.002	Materials must specify a base material type	Prop opt: Non-visual materials	Planned
NVM.003	Materials must specify surface coating	Prop opt: Non-visual materials	Planned
NVM.004	Attributes must be on bound materials	Prop opt: Non-visual materials	Planned
NVM.005	Properties must be consistent with visual materials	Prop opt: Non-visual materials	Planned
NVM.006	Properties must not be time-varying	Prop opt: Non-visual materials	Planned

Semantic labels (SL)

Code	Requirement	Profiles	Rigyd
SL.001	All renderable geometry must be semantically labeled	Prop · Tax	Checked
SL.002	Deprecated SemanticsAPI labels must be migrated to the SemanticsLabelsAPI schema	Prop · Tax	Checked
SL.003	Semantic labels must use the SemanticsLabelsAPI schema	Prop · Tax	Checked
SL.MAT.001	Material prims must be labeled with a non-empty SemanticsLabelsAPI:material label	Prop	Checked
SL.QCODE.001	If the Wikidata ontology is used, Q-Codes must be well-formed (Q followed by one or more digits). Values should reference a real Wikidata entity, but the validator checks format only — it does not contact wikidata.org	Prop	Checked
SL.TIME.001	For the NVIDIA RTX perception pipeline, semantic label attributes must use static (non-time-varying) values	Prop	Checked

Open taxonomies

Each Open-Taxonomy-* profile asks that labels in one public dataset’s vocabulary be members of that vocabulary. We label in our own category list plus Wikidata, so these are planned rather than failing.

Code	Requirement	Profiles	Rigyd
ADE.001	Every SemanticsLabelsAPI:ade20k label value must be a member of the ADE20K (150) taxonomy	Tax	Planned
CITY.001	Every SemanticsLabelsAPI:cityscapes label value must be a member of the Cityscapes (fine) taxonomy	Tax	Planned
COCO.001	Every SemanticsLabelsAPI:coco label value must be a member of the COCO (instances) taxonomy	Tax	Planned
IN1K.001	Every SemanticsLabelsAPI:imagenet_1k label value must be a member of the ImageNet-1K taxonomy	Tax	Planned
SUN.001	Every SemanticsLabelsAPI:sunrgbd label value must be a member of the SUN RGB-D (10) taxonomy	Tax	Planned
VOC.001	Every SemanticsLabelsAPI:pascal_voc label value must be a member of the PASCAL VOC (20) taxonomy	Tax	Planned

Physics — rigid bodies (RB)

Code	Requirement	Profiles	Rigyd
RB.001	Assets must contain at least one rigid body	Prop · Body · Grip	Checked
RB.003	Rigid bodies have to be UsdGeomXformable prims	Prop · Body · Grip	Checked
RB.005	Rigid bodies cannot be part of a scene graph instance	Prop · Body · Grip	Checked
RB.006	Rigid bodies can not be nested unless xformOp reset xform stack is used	Grip	Checked
RB.007	Rigid bodies or their descendant collision shapes must have a mass specification	Prop · Body · Grip	Checked
RB.008	Rigid bodies or their descendent collision shapes may have detailed mass properties including density, center of mass, and inertia tensor. When authored, these detailed mass properties must be internally consistent	—	Checked
RB.009	Rigid bodies have to be UsdGeomXformable prims without skew matrix	Prop · Body · Grip	Checked
RB.010	Invisible collision meshes must have their purpose attribute set to ‘guide’ to be properly excluded from rendering	Prop · Body · Grip	Checked
RB.011	Every rigid body must have a valid (positive) physics:mass on itself or on at least one of its child colliders. Nested rigid body subtrees are excluded from the traversal. Negative mass is always a failure	Prop opt: MuJoCo multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
RB.012	Rigid bodies should not be nested unless they are connected by a joint	Prop opt: MuJoCo multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
RB.013	Enabled rigid bodies must have collision geometry	—	Planned
RB.COL.001	Colliding Gprims must apply the Collision API	Prop · Body · Grip	Checked
RB.COL.002	UsdPhysicsMeshCollisionAPI may only be applied to UsdGeom.Mesh prims, and any prim with MeshCollisionAPI must also have UsdPhysicsCollisionAPI applied	Prop · Body · Grip	Checked
RB.COL.003	The Mesh Collision API can only be assigned to Mesh Prims	Prop · Body · Grip	Checked
RB.COL.004	The collision shape scale must be uniform for the following geometries: Sphere, Capsule, Cylinder, Cone & Points	Prop · Body · Grip	Checked
RB.MB.001	Assets must contain at least two rigid bodies	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked

Physics — joints (JT)

Code	Requirement	Profiles	Rigyd
JT.001	Rigid bodies which are not free floating should be connected using joints	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
JT.002	Targets set to Body0 and Body1 relationships must exist	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
JT.003	Body0 and Body1 relationships must not have more than one target	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
JT.ART.001	For stable and fast simulations of kinematic chains, an asset should define an articulation	—	Checked
JT.ART.002	Articulation roots cannot be nested	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
JT.ART.003	Articulations are not allowed on kinematic bodies	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked
JT.ART.004	Articulations are not allowed on static bodies	Prop opt: MuJoCo multi-body, Multi-body, Newton multi-body, PhysX multi-body · Body · Grip	Checked

Physics — driven joints (DJ)

Code	Requirement	Profiles	Rigyd
DJ.001	Validate that each driven joint has correct drive configuration and joint state, including required limits and consistency checks against the current joint state values	Body · Grip	Planned
DJ.002	Driven joints must implement proper joint state API for simulation state management	Body · Grip	Planned
DJ.003	Driven joints must maintain correct transform relationships and state consistency	Body · Grip	Planned
DJ.004	PhysX driven joints must implement drive API or mimic functionality for controlled motion	Body · Grip	Planned
DJ.005	PhysX driven joints must have appropriate maximum velocity limits configured	Body · Grip	Planned
DJ.006	Drive joint parameters must be within reasonable ranges for stable simulation. The joint parameters should not be excessively big and should be natural numbers	Body · Grip	Planned
DJ.007	Mimic API configuration must be properly validated for coordinated joint motion	Body · Grip	Planned
DJ.008	Robot schema joints must exist and be properly defined for Isaac Sim integration	Body · Grip	Planned
DJ.009	Robot schema links must exist and be properly connected to joints for kinematic chain definition	Body · Grip	Planned
DJ.010	Robot joint and link relationships must be validated for proper kinematic tree structure	Body · Grip	Planned
DJ.011	The articulation must have no loops and at most one joint between any two bodies. Only joints that participate in the articulation are checked; joints with physics:excludeFromArticulation = true are ignored	Body · Grip	Planned

Physics — base articulation (BA)

Code	Requirement	Profiles	Rigyd
BA.001	An articulated USD stage must contain exactly one prim with the UsdPhysicsArticulationRootAPI applied	Body · Grip	Checked
BA.002	Collision meshes on non-adjacent links in the articulation hierarchy must not overlap or intersect	Body · Grip	Planned

Physics — colliders (COL)

Code	Requirement	Profiles	Rigyd
COL.001	Every mesh collider (Mesh prim with USDPhysics.CollisionAPI and USDPhysics.MeshCollisionAPI) must have an SDF (Signed Distance Field) approximation for efficient collision detection	—	Checked

Physics — PhysX colliders (PHYSX)

Code	Requirement	Profiles	Rigyd
PHYSX.COL.001	CollisionAPI may only be applied to a UsdGeom Gprim or to an Xform that has PhysxMeshMergeCollisionAPI and whose collisionmeshes collection includes at least one Gprim	Prop opt: Isaac, PhysX, PhysX multi-body · Body · Grip	Checked
PHYSX.COL.002	MeshCollisionAPI may only be applied to a UsdGeom Mesh or to a prim that has PhysxMeshMergeCollisionAPI. CollisionAPI is required whenever MeshCollisionAPI is applied	Prop opt: Isaac, PhysX, PhysX multi-body · Body · Grip	Checked

Runtime variants (RV)

New at 2026.08.0: each physics runtime is a variant set on the default prim whose Enabled option composes that runtime’s layer. We do not author these variant sets yet, which is why the PhysX, Newton and MuJoCo features are unmet.

Code	Requirement	Profiles	Rigyd
RV.001	The asset’s default prim must expose a PhysX physics runtime variant set with Disabled and Enabled options, defaulting to Disabled	Prop opt: PhysX · Body · Grip	Planned
RV.002	The PhysX variant set’s Enabled option must compose its runtime layer with an anchored prepend payload that resolves to ./runnables/physics/physx.usd(a)	Prop opt: PhysX · Body · Grip	Planned
RV.003	The PhysX variant set must be documented in customLayerData.SimReady_Metadata.Variants.Physics.PhysX, declaring its prim, variantSetName, and activateOption	Prop opt: PhysX · Body · Grip	Planned
RV.004	The asset’s default prim must expose a Newton physics runtime variant set with Disabled and Enabled options, defaulting to Disabled	Prop opt: Newton · Body · Grip	Planned
RV.005	The Newton variant set’s Enabled option must compose its runtime layer with an anchored prepend payload that resolves to ./runnables/physics/newton.usd(a)	Prop opt: Newton · Body · Grip	Planned
RV.006	The Newton variant set must be documented in customLayerData.SimReady_Metadata.Variants.Physics.Newton, declaring its prim, variantSetName, and activateOption	Prop opt: Newton · Body · Grip	Planned
RV.007	The asset’s default prim must expose a MuJoCo physics runtime variant set with Disabled and Enabled options, defaulting to Disabled	Prop opt: MuJoCo · Body · Grip	Planned
RV.008	The MuJoCo variant set’s Enabled option must compose its runtime layer with an anchored prepend payload that resolves to ./runnables/physics/mujoco.usd(a)	Prop opt: MuJoCo · Body · Grip	Planned
RV.009	The MuJoCo variant set must be documented in customLayerData.SimReady_Metadata.Variants.Physics.MuJoCo, declaring its prim, variantSetName, and activateOption	Prop opt: MuJoCo · Body · Grip	Planned
RV.010	Each physics runtime variant set must isolate all runtime data in its payload: the Enabled option may compose the runtime only through the prepend payload arc and must author no inline prim overrides, and the Disabled option must be empty	Prop opt: MuJoCo, Newton, PhysX · Body · Grip	Planned
RV.011	When a single physics runtime variant is selected, the composed stage must contain only that runtime’s physics schemas and attributes plus the runtime-neutral base. Foreign-runtime schemas and conflicting attribute values are not allowed	Prop opt: MuJoCo, Newton, PhysX · Body · Grip	Planned

Runtime — MuJoCo (MUJOCO)

Code	Requirement	Profiles	Rigyd
MUJOCO.BA.001	MuJoCo articulations must use standard UsdPhysics.ArticulationRootAPI and must not author unsupported MuJoCo-specific articulation-root schemas	Body · Grip	Planned
MUJOCO.COL.001	MuJoCo collision shapes must apply MjcCollisionAPI on valid USD collision geometry	Prop opt: MuJoCo, MuJoCo multi-body · Body · Grip	Planned
MUJOCO.COL.002	MuJoCo mesh collision data must use valid MjcMeshCollisionAPI and convex-hull mesh collision authoring	Prop opt: MuJoCo, MuJoCo multi-body · Body · Grip	Planned
MUJOCO.DJ.001	MuJoCo driven joints must use standard UsdPhysics.Joint prims with MjcJointAPI applied to every non-fixed articulation joint	Body · Grip	Planned
MUJOCO.DJ.002	MuJoCo actuator prims must target valid MuJoCo-driven USD physics joints and author valid actuator parameter values	Body · Grip	Planned
MUJOCO.GR.001	MuJoCo gripper site prims must apply MjcSiteAPI	Grip	Planned

Runtime — Newton (NEWTON)

Code	Requirement	Profiles	Rigyd
NEWTON.BA.001	Newton articulation roots must use standard UsdPhysics.ArticulationRootAPI and author explicit Newton self-collision configuration	Body · Grip	Planned
NEWTON.COL.001	Newton colliders must use a valid Newton collision schema	Prop opt: Newton, Newton multi-body · Body · Grip	Planned
NEWTON.COL.002	Authored Newton SDF attributes must be valid	Prop opt: Newton, Newton multi-body · Body · Grip	Planned
NEWTON.DJ.001	Every actuated Newton articulation joint must be driven by a standard UsdPhysics.DriveAPI, by a NewtonActuator, or be coupled to a leader joint by NewtonMimicAPI, and those actuation values must be valid	Body · Grip	Planned
NEWTON.DJ.002	Authored Newton joint tuning must use NewtonJointAPI (or the equivalent newton:* attributes) on UsdPhysics.Joint prims with valid values	Body · Grip	Planned
NEWTON.DJ.003	When NewtonMimicAPI is applied, it must be on a UsdPhysics.Joint, target a valid leader joint, and author valid mimic coefficients	Body · Grip	Planned
NEWTON.MAS.001	NewtonMassAPI must be applied on an Xformable, and any authored Newton mass attributes must be valid	Prop opt: Newton, Newton multi-body · Body · Grip	Planned
NEWTON.MAT.001	NewtonMaterialAPI must be applied on a physics Material — a UsdShade.Material that also carries PhysicsMaterialAPI	Prop opt: Newton, Newton multi-body · Body · Grip	Planned

Physics materials (PMT)

Code	Requirement	Profiles	Rigyd
PMT.001	Every collider (prim with PhysicsCollisionAPI) must have a material:binding:physics relationship to a physics material	Prop opt: Grasp	Checked

Grasp (GSP)

Code	Requirement	Profiles	Rigyd
GSP.001	In order for an asset to be considered graspable, an asset must have at least 1 line object defined within the asset. A line is at least 2 points in space, and this line must intersect the asset that needs to be grasped by the robotic grippers	Prop opt: Grasp	Checked

Grippers (GR)

Code	Requirement	Profiles	Rigyd
GR.001	Every gripper site prim must be an Xform with token simready:attactment:socketType = "Gripper" authored, positioned at the grasp center between the finger pads	Grip	Planned
GR.002	Every gripper site prim must contain a child BasisCurves prim named gripper_forward_axis with at least 2 points defining the gripper approach direction	Grip	Planned
GR.003	Every gripper site prim must contain a child BasisCurves prim named gripper_grip_line with at least 2 points defining the axis of the imaginary tube the gripper can grasp	Grip	Planned
GR.004	Every gripper site prim must declare a gripper_maxOpening float attribute with a positive value (in meters) recording the maximum jaw separation	Grip	Planned
GR.ISA.001	Every gripper site prim must have IsaacSiteAPI applied and isaac:Description authored so Isaac Sim tooling can discover and configure it automatically	Grip	Planned

Runtime — Isaac Sim (ISA)

Code	Requirement	Profiles	Rigyd
ISA.001	The asset must be composed correctly for Isaac Sim using one of the supported layer layouts and a reference or payload arc to its base layer	Prop opt: Isaac · Body · Grip	Checked

Robot materials (RM)

Code	Requirement	Profiles	Rigyd
RM.001	Materials must not contain nested materials to avoid unexpected rendering behavior	Body	Planned
RM.002	Materials must only be defined in the top-level Looks prim following USD best practices for material organization	Body	Planned

Robot core (RC)

Code	Requirement	Profiles	Rigyd
RC.001	Robot asset folders contain only referenced, required files. No stray or unused content. At the main level of a robot asset, only the interface layer is present. All other required content is bundled on subfolders related to it specific usage	Body · Grip	Planned
RC.002	Robot USDs avoid local override layers that mask upstream schemas or physics	—	Planned
RC.003	Canonical robot and prim naming conventions for stable references and tools	Body · Grip	Planned
RC.004	The robot interface asset file should contain a thumbnail. The thumbnail should be representative of the robot	Body · Grip	Planned
RC.005	Validates that physics attributes are authored in the physics layer	Body · Grip	Planned
RC.006	Validates that physics schema are authored in the physics layer	Body · Grip	Planned
RC.007	Robot USDs declare and use the required schemas and physics attributes	Body · Grip	Planned
RC.008	Robot assets must declare a valid robot type on the default prim. The isaac:robotType attribute must be present, must be one of the schema-defined allowed tokens, and must not be "Default". Allowed values are : “End Effector”, “Manipulator”, “Humanoid”, “Wheeled”, “Holonomic”, “Quadruped”, “Mobile Manipulators”, “Aerial”	Body · Grip	Planned
RC.009	The root joint (the first target of isaac:physics:robotJoints) must be pinned for robot types that require a fixed base (e.g. Manipulator, End Effector) and must not be pinned for other robot types	Body · Grip	Planned

ROS (ROS)

Code	Requirement	Profiles	Rigyd
ROS.001	The stage must contain at least one OmniGraph node whose node:type starts with isaacsim.ros2.bridge.	Body	Planned

Packaging (PKG)

Code	Requirement	Profiles	Rigyd
PKG.BOM.001	The BOM is a metadata file identified by the name com.nvidia.simready.packaging.bom.json. It MUST list all content files in the package with per-item fields, using forward-slash relative paths with no duplicates	Pkg	Planned
PKG.CONF.001	Packages MAY include conformance metadata files recording SimReady Foundations validation results, following defined naming and JSON schema conventions	Pkg	Planned
PKG.CONF.002	Packages MAY include an OpenUSD root layers metadata file declaring the top-level USD entry points that should be validated as self-contained assets	—	Planned
PKG.DEF.001	Each package MUST have exactly one valid package definition with a globally unique, case-insensitive, immutable identity, placed at the package root alongside a .metadata/ folder	Pkg	Planned
PKG.HASH.001	Hash fields MUST be objects containing at least a sha256 key with lowercase hexadecimal value. Implementations SHOULD also include blake3 and/or blake2b when available, for performance. When content_hash or package_hash are present, their sha256 values MUST be computed using the deterministic algorithms defined in this requirement	Pkg	Planned
PKG.META.001	Metadata files MUST be JSON with UTF-8 encoding, use reverse domain naming, and follow write-once semantics	Pkg	Planned

Sensors (PS, RP, LI)

The four Sensor-* profiles describe sensor assets — an IMU, a joint-state sensor, a camera render product, a LiDAR — not props.

Code	Requirement	Profiles	Rigyd
LI.001	LiDAR sensors must be represented as OmniLidar prims with OmniSensorGenericLidarCoreAPI applied. The legacy UsdGeom.Camera with cameraSensorType=“lidar” pattern is not allowed	Sen	Planned
LI.002	Every emitter state array attribute on an OmniLidar prim must have the same length as omni:sensor:Core:numberOfEmitters, and all emitter state arrays must be mutually consistent in length	Sen	Planned
LI.003	The omni:sensor:Core:scanRateBaseHz attribute on an OmniLidar prim must be at least 0.466 Hz	Sen	Planned
LI.004	For solid-state OmniLidar prims, the sum of all elements in omni:sensor:Core:numRaysPerLine must equal omni:sensor:Core:numberOfEmitters	Sen	Planned
PS.001	An IsaacImuSensor prim must be a descendant of a prim that has PhysicsRigidBodyAPI applied	Sen	Planned
PS.002	An IsaacJointStateSensor prim must also have PhysicsArticulationRootAPI applied	Sen	Planned
RP.001	A RenderProduct prim must have a camera relationship targeting a valid prim	Sen	Planned
RP.002	A RenderProduct prim must have an orderedVars relationship containing at least one valid UsdRender.Var prim	Sen	Planned
RP.003	A RenderVar prim must have a non-empty sourceName attribute	Sen	Planned
RP.004	RenderVar prims whose sourceName starts with “semantic” must use BLOSC compression	Sen	Planned
RP.005	The srtx:compression:type attribute on a RenderVar prim, if present, must be one of the four supported codec values: hevc, h264, av1, or blosc	Sen	Planned
RP.006	RenderVar prims with sourceName = "GenericModelOutput" should use BLOSC compression (srtx:compression:type = "blosc")	Sen	Planned

References

• SimReady Foundation — specification home
• SimReady Foundation — features
• SimReady Foundation — profiles
• The SimReady Specification — Omniverse docs
• OpenUSD
• NVIDIA Isaac Sim · Isaac Lab