Full requirement coverage

View Markdown llms-full.txt

Every requirement in the SimReady Foundation registry at release 2026.04.1 — 136 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.

How to read this

Profiles — which published profiles pull the requirement in:

Tag	Profile
`N`	`Prop-Robotics-Neutral` — the profile every Rigyd conversion targets
`Px`	`Prop-Robotics-Physx`
`Is`	`Prop-Robotics-Isaac`
`RB`	the `Robot-Body-*` family
`Pkg`	the `Package*` 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. Always reports `N/A` with `na_reason: "planned"`, and counts toward a profile’s `INCOMPLETE` status rather than passing it.

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 136 codes, 80 are checked and 56 are planned. All 50 requirements of Prop-Robotics-Neutral are checked, which is what lets that profile report PASS rather than INCOMPLETE.

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	`N` · `Px`	Checked
`NP.003`	Assets shall follow consistent directory structure	`N` · `Px`	Checked
`NP.004`	File and directory paths shall not exceed platform limits	`N` · `Px`	Checked
`NP.005`	Assets must follow a specific folder structure with the asset name as the root folder	`N` · `Px`	Checked
`NP.006`	Asset metadata must be stored in the USD file or a sidecar JSON file	`N` · `Px`	Checked
`NP.007`	All references must use relative paths	`N` · `Px`	Checked
`NP.008`	All asset, reference, and payload paths must resolve to files that exist	`N` · `Px`	Checked

Atomic asset (AA)

Code	Requirement	Profiles	Rigyd
`AA.001`	Asset references should use anchored paths	`N` · `Px` · `Is` · `RB` · `Pkg`	Checked
`AA.002`	Asset must use only supported file types	`N` · `Px` · `Is` · `RB`	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	`N` · `Px`	Checked
`SR.002`	The SimReady asset file should contain a thumbnail that is representative of the asset	`Pkg`	Planned

Units (UN)

Code	Requirement	Profiles	Rigyd
`UN.001`	Stage must specify upAxis to define the orientation of the stage	`Is` · `RB`	Checked
`UN.002`	Stage must specify metersPerUnit to define the linear unit scale	`Is` · `RB`	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	`N` · `Px`	Checked
`UN.007`	Stage must specify metersPerUnit = 1.0 to define the linear unit scale	`N` · `Px` · `Is` · `RB`	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	`N` · `Px`	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	`N` · `Px`	Checked
`HI.004`	Stage must specify a default prim to define the root entry point	`N` · `Px` · `Is` · `RB`	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)	`N` · `Px`	Checked

Visual geometry (VG)

Code	Requirement	Profiles	Rigyd
`VG.001`	Assets must contain at least one Imageable Geometry	`Is` · `RB`	Checked
`VG.002`	Boundable geometry primitives must have valid extent values	`N` · `Px`	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	—	Planned
`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	`N` · `Px`	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)	`N` · `Px`	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	`N` · `Px`	Checked
`VG.028`	Mesh normals values must be valid to produce correct shading	`N` · `Px`	Checked
`VG.029`	The winding order of faces in a mesh must correctly represent the orientation (front/back) of the face	`N` · `Px`	Checked
`VG.MESH.001`	All geometry shall be represented as non-subdivided mesh primitives using the UsdGeomMesh schema	`N` · `Px`	Checked
`VG.RTX.001`	World space bounds must not exceed RTX limit	—	Checked

Visual materials (VM)

Code	Requirement	Profiles	Rigyd
`VM.BIND.001`	Material bindings must use appropriate scope to ensure proper material assignment and inheritance	`N` · `Px`	Checked
`VM.BIND.002`	Shader inputs must have correct types matching their shader specification to ensure proper material behavior and prevent runtime errors	`N` · `Px`	Checked
`VM.MAT.001`	Each renderable GPrim must have a computed material bound to it	`N` · `Px`	Checked
`VM.MDL.001`	MDL material source assets must be properly referenced and accessible to ensure material loading and rendering	`N` · `Px`	Checked
`VM.MDL.002`	MDL Shaders must standard OpenUSD shader source attributes to ensure compatibility	`N` · `Px`	Checked
`VM.PS.001`	Material attributes must comply with the UsdPreviewSurface specification to ensure consistent rendering and viewer compatibility	—	Checked
`VM.TEX.001`	Texture dimensions must not exceed 16,384 pixels on either axis to ensure optimal performance and memory usage in simulation environments	`N` · `Px`	Checked
`VM.TEX.002`	Each PBR texture channel must use the correct color space	`N` · `Px`	Checked

Non-visual materials (NVM)

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

Semantic labels (SL)

Code	Requirement	Profiles	Rigyd
`SL.001`	All geometry prims must be semantically labeled	—	Planned
`SL.003`	Semantic labels must use the SemanticsLabelsAPI schema	—	Planned
`SL.NV.002`	Semantic label attributes must not contain time samples	—	Planned
`SL.QCODE.001`	If the Wikidata ontology is used, Q-Codes must be valid, properly formatted, and retrievable from wikidata.org	—	Planned

Physics — rigid bodies (RB)

Code	Requirement	Profiles	Rigyd
`RB.001`	Assets must contain at least one rigid body	`N` · `Px` · `Is` · `RB`	Checked
`RB.003`	Rigid bodies have to be UsdGeomXformable prims	`N` · `Px` · `Is` · `RB`	Checked
`RB.005`	Rigid bodies cannot be part of a scene graph instance	`N` · `Px` · `Is` · `RB`	Checked
`RB.006`	Rigid bodies can not be nested unless xformOp reset xform stack is used	`N` · `Px` · `Is` · `RB`	Checked
`RB.007`	Rigid bodies or their descendant collision shapes must have a mass specification	`N` · `Px` · `Is` · `RB`	Checked
`RB.008`	Rigid bodies or their descendent collision shapes may have detailed mass properties including density, center of mass, and inertia tensor	—	Checked
`RB.009`	Rigid bodies have to be UsdGeomXformable prims without skew matrix	`N` · `Px` · `Is` · `RB`	Checked
`RB.010`	Invisible collision meshes must have their purpose attribute set to ‘guide’ to be properly excluded from rendering	`N` · `Px` · `Is` · `RB`	Checked
`RB.011`	Rigid bodies must have an explicit mass specification, or their descendant collision shapes must have non-zero volume to allow mass auto-computation. Nested rigid body subtrees are excluded from the traversal	`RB`	Checked
`RB.012`	Rigid bodies should not be nested unless they are connected by a joint	`RB`	Checked
`RB.COL.001`	Colliding Gprims must apply the Collision API	`N` · `Px` · `Is` · `RB`	Checked
`RB.COL.002`	UsdPhysicsMeshCollisionAPI may only be applied to UsdGeom.Mesh prims, and any prim with MeshCollisionAPI must also have UsdPhysicsCollisionAPI applied	`N` · `Px` · `Is` · `RB`	Checked
`RB.COL.003`	The Mesh Collision API can only be assigned to Mesh Prims	`N` · `Px` · `Is` · `RB`	Checked
`RB.COL.004`	The collision shape scale must be uniform for the following geometries: Sphere, Capsule, Cylinder, Cone & Points	`N` · `Px` · `Is` · `RB`	Checked
`RB.MB.001`	Assets must contain at least two rigid bodies	`N` · `Px` · `Is` · `RB`	Checked

Physics — joints (JT)

Code	Requirement	Profiles	Rigyd
`JT.001`	Rigid bodies which are not free floating should be connected using joints	`N` · `Px` · `Is` · `RB`	Checked
`JT.002`	Targets set to Body0 and Body1 relationships must exist	`N` · `Px` · `Is` · `RB`	Checked
`JT.003`	Body0 and Body1 relationships must not have more than one target	`N` · `Px` · `Is` · `RB`	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	`N` · `Px` · `Is` · `RB`	Checked
`JT.ART.003`	Articulations are not allowed on kinematic bodies	`N` · `Px` · `Is` · `RB`	Checked
`JT.ART.004`	Articulations are not allowed on static bodies	`N` · `Px` · `Is` · `RB`	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	`RB`	Planned
`DJ.002`	Driven joints must implement proper joint state API for simulation state management	`RB`	Planned
`DJ.003`	Driven joints must maintain correct transform relationships and state consistency	`RB`	Planned
`DJ.004`	PhysX driven joints must implement drive API or mimic functionality for controlled motion	`RB`	Planned
`DJ.005`	PhysX driven joints must have appropriate maximum velocity limits configured	`RB`	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	`RB`	Planned
`DJ.007`	Mimic API configuration must be properly validated for coordinated joint motion	`RB`	Planned
`DJ.008`	Robot schema joints must exist and be properly defined for Isaac Sim integration	`RB`	Planned
`DJ.009`	Robot schema links must exist and be properly connected to joints for kinematic chain definition	`RB`	Planned
`DJ.010`	Robot joint and link relationships must be validated for proper kinematic tree structure	`RB`	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	`RB`	Planned

Physics — base articulation (BA)

Code	Requirement	Profiles	Rigyd
`BA.001`	The USD stage must contain at least one prim with the UsdPhysicsArticulationRootAPI applied	`RB`	Checked
`BA.002`	Collision meshes on non-adjacent links in the articulation hierarchy must not overlap or intersect	`RB`	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	`Px` · `Is` · `RB`	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	`RB`	Planned
`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	`RB`	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	`N` · `Px` · `Is`	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	`N` · `Px` · `Is`	Checked

Runtime — Isaac Sim (ISA)

Code	Requirement	Profiles	Rigyd
`ISA.001`	The asset must be composed correctly for Isaac Sim using a structured payload and reference system with proper file organization	`Is` · `RB`	Checked

Robot materials (RM)

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

Robot core (RC)

Code	Requirement	Profiles	Rigyd
`RC.001`	named by a feature manifest; ships no requirement document at this release	`RB`	Planned
`RC.003`	named by a feature manifest; ships no requirement document at this release	`RB`	Planned
`RC.004`	named by a feature manifest; ships no requirement document at this release	`RB`	Planned
`RC.005`	named by a feature manifest; ships no requirement document at this release	`RB`	Planned
`RC.006`	named by a feature manifest; ships no requirement document at this release	`RB`	Planned
`RC.007`	named by a feature manifest; ships no requirement document at this release	`RB`	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”	`RB`	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	`RB`	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