# SimReady Foundations — process deviations Issues encountered while running the `/simready-report` skill against `yaskawa_local` that require changes in **`simready_foundations`** (or a clearly documented client-side workaround). These are not playbook bugs — the playbook is working around upstream gaps. Source data for each item: paths/codes observed during the validation run on `packages/yaskawa_local/` against `Robot-Body-Isaac` v1.0.0. --- ## 1. `Profile.capabilities` returns an empty list for every profile **Where:** `omni.asset_validator` profile schema (Python registry). **Observed:** ```python profile = oav.ProfileRegistry().find('Robot-Body-Isaac', '1.0.0') profile.capabilities # → [] profile.features # → 2 features, 8 requirements ``` Every profile in the registry returns `[]` for `.capabilities`. Profiles now declare scope through `.features` — each feature owns its requirements directly. The `capabilities` attribute is a leftover from an older schema. **Impact:** `validate_yaskawa.py` and earlier versions of this playbook's `validate.py` filtered the engine's enabled capabilities against `profile.capabilities`. Because the latter is always empty, the filter disabled **every** capability and reported `enabled capabilities: 0` while producing 6,551 issues from rules that ignored the disable calls (see #2). **Required:** remove `Profile.capabilities`, or populate it from the union of the features' capabilities, and update all reference scripts/docs that still use it. --- ## 2. `engine.enable_*` / `disable_*` do not constrain rule execution **Where:** `omni.asset_validator.ValidationEngine`. **Observed:** `engine.enable_feature(f)` and `engine.enable_requirement(r)` update `engine.enabled_features` / `engine.enabled_requirements` counters, but `engine.validate(stage)` still runs every rule registered via `@register_rule`. `engine.enabled_rules` stays at 0 even after enabling features and requirements; rules execute regardless. **Impact:** profile-scoping has to happen post-hoc, by filtering issues against the profile's requirement codes. The current playbook does this in `validate_one()` (filters failures by `code in profile_codes`). **Required:** either 1. make `enable_*` / `disable_*` actually scope rule execution, or 2. document explicitly that they are display-only and that callers must filter results themselves. Today the API name strongly implies (1). --- ## 3. `Robot-Body-Isaac` v1.0.0 silently drops 4 of 6 declared features (TOML ↔ Python registry mismatch) **Where:** `simready_foundations/_build/target-deps/pip_prebundle/simready/foundation/core/profiles/profiles.toml` vs the `Features` enum loaded from `simready.foundation.core.features`. **Observed:** `profiles.toml` declares Robot-Body-Isaac v1.0.0 with six features: | TOML entry | Loads? | Notes | |---|---|---| | `FET001_BASE_NEUTRAL` v0.1.0 | ✓ | 8 requirements | | `FET004_ROBOT_PHYSX` v0.2.0 | ✗ | No such name in `Features` enum (only `FET004_BASE_NEUTRAL`) | | `FET021_ROBOT_CORE_ISAAC` v0.2.0 | ✗ | Closest is `FET_021_ROBOT_CORE` v0.2.0 (note underscore + missing `_ISAAC`) | | `FET022_DRIVEN_JOINTS_ISAAC` v0.1.0 | ✗ | Closest is `FET_022_DRIVEN_JOINTS` v0.1.0 | | `FET024_BASE_ARTICULATION_PHYSX` v0.1.0 | ✗ | Closest is `FET_024_BASE_ARTICULATION` v0.1.0 | | `FET100_BASE_ISAACSIM` v0.1.0 | ✓ | 0 requirements | `pr.find('Robot-Body-Isaac', '1.0.0').features` therefore returns only the two features that successfully resolve. Four features (Robot Core, Driven Joints, Base Articulation, Robot Physx) are silently dropped — no warning, no error. The rules associated with the dropped features (RC.*, JT.*, RB.*, AT.*) still execute (per #2 the engine ignores feature gating), so they appear in the raw issue list, but they cannot be attributed to a profile feature for roll-up reporting. **Required:** reconcile the names. Either rename the TOML entries to match the `Features` enum (`FET_021_ROBOT_CORE` etc.), or add the `_ISAAC` / `_PHYSX` variants to the foundation as real feature implementations. Also make profile-feature lookup *fail loudly* when a declared feature can't be resolved — silent drop is the worst outcome. Validation also surfaced real failures with codes from features that **aren't even declared in the TOML profile**: | Code(s) | Source | Notes | |---|---|---| | `RC.002`, `RC.004` (`thumbnail-exist`), `RC.008`, `RC.009` | `capabilities/isaac_sim/robot_core` | Robot-core rules registered & raising issues, but no profile feature includes them | | `NP.001`, `NP.005`, `NP.006`, `NP.008` | `capabilities/visualization/nonvisual_materials` | | | `HI.001`, `HI.002` | `capabilities/hierarchy` | (`HI.004` is in profile, others aren't) | | `VG.007`, `VG.009`, `VG.016`, `VG.019`, `VG.MESH.001` | `capabilities/visualization/geometry` | (`VG.001` is in profile, the rest aren't) | | `EX.01`, `EX.03`, `GSP.001`, `ISA.001`, `VM.MDL.001` | various | | A "Robot-Body-Isaac" profile that does not require the asset to have a thumbnail, robot type, or pinned root joint, but the foundations repo ships those as registered rules, is a process gap. **Required:** extend the profile's features to include the robot-core, nonvisual-materials, hierarchy-completeness, and geometry-completeness features that are already authored in the foundation; align the JSON capability configs (`config/robot-core.json` etc.) with the Python `Profiles` enum. --- ## 4. JSON capability config and Python profile registry are not linked **Where:** `simready_foundations/nv_core/sr_specs/config/robot-core.json` vs `simready.foundation.core` Python plugin. **Observed:** `robot-core.json` declares `RobotCore` capability v1.0.0 with the `thumbnail-exist` requirement (and others). The Python registry exposes that requirement to the rule machinery (issues with `RC.004` are emitted), but no `Profile` exposes `RobotCore` as a feature, so client code that introspects `profile.features` to compute pass/fail per feature can't see it. **Impact:** validation reports list `RC.*` codes in raw issues but cannot map them to a feature, so they appear as "uncategorized" failures. **Required:** wire the JSON capability declarations into the `Features` / `Profiles` enums (or into a new `profile.capabilities` accessor that returns real entries — see #1). --- ## 5. ~87% of issues report `code: UNKNOWN` **Where:** rules registered in `omni.asset_validator` and SimReady plugins. **Observed:** of 6,551 issues across 7 robots, **5,695** have `iss.requirement is None`, so the issue cannot be attributed to any requirement code: ``` 5695 UNKNOWN 129 NP.001 116 HI.002 116 VG.009 96 VG.007 ... ``` These come from rules that don't decorate with `@register_requirements`, so they run but have no requirement linkage. **Impact:** profile-scoped filtering (#2's workaround) drops 87% of the signal; those failures appear in the raw issue list but never roll up to a feature pass/fail. **Required:** every rule registered in foundations should declare the requirement(s) it enforces via `@register_requirements`, so issues are attributable. --- ## 6. `init_rules` defaults are inconsistent across consumers **Where:** `omni.asset_validator.ValidationEngine` constructor and the SimReady SDK's engine wrapper. **Observed:** `validate_yaskawa.py` (top-level reference) explicitly passes `init_rules=True` and notes that `simready_sdk.core.engine` passes `init_rules=False`, which leaves the engine empty: ``` The SDK passes init_rules=False which leaves the engine with no checks, producing 'No rules or requirements have been enabled.' for every asset. ``` With `init_rules=True` the engine has 124 rules / 118 requirements. With `False` it has 0 / 0. **Required:** make `init_rules=True` the default in the engine, or remove the parameter; update `simready_sdk.core.engine` to call it correctly. Today choosing the wrong path silently produces a "passes everything" report. --- ## 7. Foundation has the wrapper but ships no runnable thumbnail generator **Where:** `simready_foundations/nv_core/testing_tools/testing_framework/source/job_runner/core/engines/usdrecord/` plus lighting rigs at `simready_foundations/nv_core/common_tools/thumbnails/auto_thumbnail_indoor_lighting_rig_{small,medium,large}.usd`. **Observed:** the foundation defines `UsdRecordCommandBuilder` which builds the command ` ` and references three preset lighting USDs intended to be composed with the asset before rendering. But: - The `` is taken from `job.runner_config.executable`. The foundation does not bundle the binary, the venv does not have it, and `pxr.UsdAppUtils` (the Python library backing `usdrecord`) is absent. - The `auto_thumbnail_indoor_lighting_rig_*.usd` rigs have no documented composition recipe — there is no published "open the rig, payload the asset, render to 256×256" wrapper script. `usdrecord` is part of OpenUSD; on this machine it must be installed externally. Three working install paths (commands documented for the record; none are run automatically by the validator): 1. **Kit Kernel from NGC** (the user already has `ngc` on PATH): ```powershell $env:KIT_VERSION = "106.5.0" ngc registry resource download-version "nvidia/omniverse/kit:$env:KIT_VERSION" ` --dest "$env:USERPROFILE\.kit" # `usdrecord.bat` lives at \dev\tools\packman\repo\bld\target-deps\usd\release\bin\usdrecord.bat $env:USDRECORD_BIN = "$env:USERPROFILE\.kit\kit-$env:KIT_VERSION\...\usdrecord.bat" ``` 2. **OpenUSD prebuilt** (NVIDIA developer release): ```powershell # Download from https://developer.nvidia.com/usd (signed-in NGC link), # extract, and point to the binary: $env:USDRECORD_BIN = "C:\openusd\bin\usdrecord.cmd" ``` 3. **Build OpenUSD from source** (heaviest, only if the prebuilt isn't acceptable): ```powershell git clone https://github.com/PixarAnimationStudios/OpenUSD.git C:\src\OpenUSD python C:\src\OpenUSD\build_scripts\build_usd.py --tools C:\openusd $env:USDRECORD_BIN = "C:\openusd\bin\usdrecord.cmd" ``` Once `USDRECORD_BIN` is set (or the binary is on PATH), `validate.py`'s `_find_usdrecord()` will pick it up and the validator will invoke it for each asset missing a thumbnail at the spec path. Generated PNGs go to `report//_generated_thumbs/.png` — never into the packaged asset tree. Every command run is logged in `results.json` under `thumbnail_generation.attempts` and surfaced in the dashboard's "External tooling used" panel. For `yaskawa_local`, six of seven thumbnails were instead pulled from `Assets/Isaac/6.0/Isaac/Robots/Yaskawa/Motoman Next/.../.thumbs/256x256/` on the Omniverse content S3 bucket (free; no install required). One robot (`NHC10DE-A00`) has no S3 thumbnail; without `usdrecord` installed, its tile renders the inline SVG "no thumbnail" placeholder. **Required:** either ship `usdrecord` in the foundation's bundled toolchain, or distribute a foundation-side wrapper (e.g. a Kit ext that does `UsdAppUtils.framerec.FrameRecorder` programmatically) so `simready ingest usd` can produce the spec thumbnail without external installs. --- ## 8. Spec docs disagree on the thumbnail filename **Where:** - Spec doc: `nv_core/sr_specs/docs/capabilities/isaac_sim/robot_core/requirements/thumbnail-exist.md` - Validation rule: `nv_core/sr_specs/docs/capabilities/isaac_sim/robot_core/validation.py:213` - OEM publishing guide: `simready-oem-sdk-poc/docs/oem-publishing-guide-hf.md` **Observed:** - The spec doc's example uses `…/Robot_Name/.thumbs/256x256/Robot.png` (filename = USD stem only, no `.usd` suffix). - The rule code computes `…/.png` where `` is the full USD filename **including** the `.usd` extension, e.g. `nex4_c00.usd.png`. - The OEM publishing guide also uses `robot-a.usd.png` (with `.usd.`). - The Isaac S3 bucket uses `NEX4_C00.usd.png` (with `.usd.`). The rule and most published assets agree (`.png` with `.usd`); the spec doc's example is wrong. **Required:** fix the spec example in `thumbnail-exist.md` to match the rule. --- ## 9. `simready ingest usd` does not lift companion thumbnails **Where:** `simready-oem-sdk-poc/src/simready_sdk/packager/organizer.py`. **Observed:** `simready ingest usd ./robot/robot.usd` produces the spec layout (`/.usd`, `configuration/`, `materials/`, `.thumbs/256x256/` folder) but **does not** copy/rename a thumbnail from any companion location into `.thumbs/256x256/.usd.png`. The packager docs (`SKILL.md`) call it "thumbnail placeholder" — the directory is created empty. For `yaskawa_local/images/.usd.usd.png`, no automated path exists for the packager to know that file should land at the spec's thumbnail path. **Required:** the packager should accept a companion-images directory hint (e.g. `--thumbs-from ` or a sibling `images/` convention) and lift matching files into `.thumbs/256x256/.usd.png` during organize. --- ## 10. A foundation rule crashes with `'NoneType' object has no attribute 'JointStateAPI'` **Where:** somewhere in the `simready.foundation.core` plugin's joint-state checker (rule not yet pinned down — issue is reported as `code: UNKNOWN`, `rule: None`). **Observed:** the rule fires on every prim it visits and produces an *Uncaught error* issue, accounting for between **566 and 698 issues per asset** in our run — i.e., most of what makes the report look noisy: ``` UNKNOWN ×668 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' UNKNOWN ×566 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' UNKNOWN ×698 Uncaught error: 'NoneType' object has no attribute 'JointStateAPI' ``` The remaining ~150 issues per asset (HI.*, NP.*, RC.*, etc.) are the *real* findings. The crash strongly suggests the rule reads `stage.GetPrimAtPath(...).GetAPISchemas()`-style and assumes the result is non-`None`. A defensive `if foo is None: continue` would silence the noise; the underlying joint-state coverage is presumably what the rule was meant to be checking, but currently it produces nothing useful. **Required:** pin down the rule (grep `JointStateAPI` across `simready.foundation.core`), add the missing None-guard, and either register the rule's requirement properly or remove it from the engine until it works. --- ## 11. `NP.005` — layout mismatch between the rule's spec and `simready ingest usd`, plus a path-printing bug **Where:** - Rule code: `simready_foundations/nv_core/sr_specs/docs/capabilities/core/naming_paths/validation.py:271-320` (`AssetFolderStructureChecker`). - Rule spec doc: `simready_foundations/nv_core/sr_specs/docs/capabilities/core/naming_paths/requirements/asset-folder-structure.md`. - Packager output: `simready-oem-sdk-poc/src/simready_sdk/packager/organizer.py` (invoked via `simready ingest usd`). ### 11a. Layout mismatch The NP.005 spec doc requires this structure: ``` / ← asset folder ├── / ← exactly ONE intermediate folder (any name) │ └──
.usd ← main USD; NO other .usd files here or below └── materials/ ← supporting folders are SIBLINGS of / ``` The reference dashboard's FANUC content follows this exactly: ``` robots/CR/cr_50f_16b/isaac_ready_usd/cr_50f_16b.usd.usd robots/CR/cr_50f_16b/configuration/... ``` But `simready ingest usd` produces a *flat* layout — main USD at the asset root, sublayers nested inside the same dir: ``` / ├── .usd └── configuration/ ├── _base.usd ├── _physics.usd └── _sensor.usd ``` The rule walks `os.path.dirname(stage_path)` (which is `/` in the flat layout) and flags every sublayer as "stray". The sublayers aren't stray — they're the spec-required configuration files — but the rule's walk-set includes them because the packager produced an NP.005-non-compliant layout. So: **two foundation artifacts disagree on the canonical asset layout.** The packaging spec (`simready-packaging`'s SKILL.md) and `simready ingest usd` produce one layout; NP.005's spec doc and the FANUC reference content use a different layout. ### 11b. Path-printing bug (independent) ```python # capabilities/core/naming_paths/validation.py:308-313 for root, dirs, files in os.walk(current_dir): for file in files: found_file = os.path.join(root, file).replace("\\", "/") if file.endswith((".usd", ".usda")) and found_file != stage_path: relative_path = os.path.relpath(file, current_dir) # ← bug other_usd_files.append(relative_path) ``` `file` here is just the basename returned by `os.walk` (e.g. `nex10_c00_base.usd`). `os.path.relpath` resolves it against `os.getcwd()`, not against `root`. With CWD = `/.claude/skills/simready-report/`, the rule prints: ``` ..\..\..\.claude\skills\simready-report\nex10_c00_base.usd ``` — a path back to the validator's CWD, where the file emphatically does not exist. Should be `os.path.relpath(found_file, current_dir)` (`found_file` is the correct joined path, already computed on the line above and otherwise unused). With that one-character fix the cited path becomes `configuration/nex10_c00_base.usd` — pointing at the real file. ### Required **Pick one canonical layout and reconcile both sides.** Either: - **Update the packager** (`simready ingest usd`) to emit the NP.005-compliant `//
.usd` structure with `configuration/` and `materials/` as siblings of `/`. This is what the FANUC reference content already uses. The packaging skill doc and any consumers (manifest tooling, dashboard, etc.) need updating in lockstep. - **Or update NP.005's spec doc and rule** to bless the flat layout that `simready ingest usd` actually produces — i.e., explicitly whitelist the spec-mandated subdirectories (`configuration/`, `materials/`, `.thumbs/`, `.simready/`) when scanning for stray USDs. Whichever is chosen, fix the path-printing bug at the same time (`relpath(file, …)` → `relpath(found_file, …)`) so the message names a real on-disk path. --- ## 12. The "example" capability is active in production validation **Where:** `simready_foundations/nv_core/sr_specs/docs/capabilities/example/example.py`, codes `EX.01`, `EX.02`, `EX.03`. **Observed:** every asset fails: - `EX.01` — *"Stage has no mesh prims."* - `EX.03` — *"Test prim 'TestBlob' not found under default prim."* The source comment on this capability is literally `"example"` and the rule docs (`example.md`) describe it as a tutorial — `EX.03` requires a prim named `TestBlob` to exist as a child of the default prim. That's clearly not an asset requirement; it's pedagogical scaffolding to teach plugin authors how to register a rule. **Required:** unregister the `Example` capability from production rule loading (move it to test fixtures, gate it behind an env var, or delete it from the shipped plugin). Today every real asset takes 2–3 spurious EX failures. --- ## 13. `EX.01` and `VG.MESH.001` are duplicate checks under different codes **Where:** - `capabilities/example/example.py:52` — `EX.01`: *"Stage has no mesh prims."* - `capabilities/visualization/geometry/validation.py:836` — `VG.MESH.001`: *"Stage does not contain any meshes."* **Observed:** both fire on every asset, with effectively identical semantics. `EX.01` is the example/tutorial version; `VG.MESH.001` is the real version. Reporting both is noise. **Required:** when #12 is fixed, this disappears for free. Otherwise, `EX.01` should be retired and any consumer that still references it should be redirected to `VG.MESH.001`. --- ## 14. `HI.002` rejects valid USD xform-op decompositions **Where:** `capabilities/hierarchy/validation.py:62-104` (`ExclusiveXFormParentChecker`). **Observed:** ~14 issues per asset, message *"Prim Parent has no xformOp:rotate."* The rule requires every Gprim parent to author both `xformOp:translate` and (a substring-matching) `xformOp:rotate*`: ```python if not any("xformOp:rotate" in op.GetAttr().GetName() for op in xform_ops): self._AddFailedCheck("Prim Parent has no xformOp:rotate.", …) ``` That's an over-strict reading of USD. Valid alternatives the rule rejects: - `xformOp:transform` (single 4×4 matrix — encodes translate + rotate + scale together). - No xform ops at all (identity transform — also a valid stateless prim). - Any combination authored on an inherited parent and overridden by the Gprim's own ops. Yaskawa's robots author matrix transforms in many places, which is what trips this. The check should accept *any* xformable spec that resolves to a defined transform — likely via `Xformable.GetLocalTransformation()` returning a non-error result — rather than pattern-matching specific op names. **Required:** rewrite the check to validate *that the prim resolves to a defined transform*, not that it authored a particular op vocabulary. --- ## 15. `NP.001` flags the conventional `/Looks` scope as a naming violation **Where:** `capabilities/core/naming_paths/validation.py:125-160` (`PrimNamingConventionChecker`). **Observed:** every asset fails NP.001 ×8 with *"Prim 'Looks' does not follow consistent naming convention (camelCase or snake_case)."* `Looks` is the long-established USD convention for the materials scope under an asset's default prim — it's used by Pixar's published USD samples, NVIDIA's Isaac/Omniverse content, and most authoring tools (Houdini, Maya USD, Kit). The rule's `CAMEL_CASE_PATTERN` and `SNAKE_CASE_PATTERN` regexes don't accept the `Looks` PascalCase single-word, so it reports a violation on a name the broader USD ecosystem treats as canonical. **Required:** either whitelist the well-known USD scope names (`Looks`, `Geometry`, `Cameras`, `Lights`, `Animation`, `Render`, etc.) or accept PascalCase as a valid convention alongside camelCase / snake_case. --- ## 16. `VM.MDL.001` and `NP.008` double-report the same MDL resolution failure **Where:** - `capabilities/visualization/materials/...` (VM.MDL.001 — *"The path OmniPBR.mdl does not exist."*) - `capabilities/core/naming_paths/...` (NP.008 — *"Asset path 'OmniPBR.mdl' on attribute 'info:mdl:sourceAsset' at prim '/.../Looks/.../...' does not resolve to an existing file."*) **Observed:** every asset emits the same number of VM.MDL.001 and NP.008 issues (9 each on `nex10_c00`, 6 each on `nex20_c00`, etc.) — both rules fire on the same `info:mdl:sourceAsset = @OmniPBR.mdl@` attribute. NP.008 gives a useful prim path; VM.MDL.001 just says "doesn't exist". Separately: `OmniPBR.mdl` is a **standard NVIDIA MDL** that ships with Kit and Isaac. The validator's asset resolver doesn't know where to find it (likely missing an MDL search path in the SimReady plugin's resolver config), so a perfectly portable, NVIDIA-blessed material reference is flagged as broken on every asset. **Required:** 1. Configure the SimReady validator plugin to register Kit's standard MDL search paths (`mdl/`, `omni/mdl/`, etc.) so `OmniPBR.mdl` and other shipped MDLs resolve without the customer having to vendor them. 2. Pick one of VM.MDL.001 / NP.008 as the canonical "MDL doesn't resolve" code. Have the other defer when the first has fired against the same attribute. --- ## 17. `RC.002` flags spec-mandated robot metadata as "overrides" **Where:** `capabilities/isaac_sim/robot_core/...`, `RC.002`. **Observed:** every asset fails RC.002 with messages like: ``` Prim is overridden: /nex10_c00, ['isaac:description', 'isaac:license', 'isaac:namespace', 'isaac:robotType'] ``` `isaac:description`, `isaac:license`, `isaac:namespace`, `isaac:robotType` look like exactly the kind of metadata the SimReady robot spec wants you to author on the robot's default prim — but RC.002 is treating any authored override of the default prim's properties as a violation. If those four `isaac:*` attributes are spec-mandated, the rule should *require* them, not flag their presence. If they're optional metadata, the rule should ignore them — overriding metadata fields on the default prim is a normal authoring pattern, not a layout error. **Required:** clarify the spec around the `isaac:*` namespace on the robot default prim and update RC.002 to either require those fields, or exclude them from the "this prim shouldn't be overridden" check, or split into two rules (one for "structural" overrides, one for the spec metadata). --- ## Summary | # | Severity | Area | One-line | |---|---|---|---| | 1 | high | profile schema | `Profile.capabilities` is dead; should be removed or populated | | 2 | high | engine API | `enable_*`/`disable_*` don't actually scope rule execution | | 3 | high | profile content | Robot-Body-Isaac v1.0.0 silently drops 4 of 6 declared features | | 4 | high | profile schema | JSON capability configs aren't linked to the Python profile registry | | 5 | high | rule registration | Most rules don't declare `@register_requirements` → 87% UNKNOWN | | 6 | medium | engine API | `init_rules` defaults inconsistent; SDK silently turns off all checks | | 7 | medium | tooling | No headless thumbnail generator ships with foundations | | 8 | low | spec docs | `thumbnail-exist.md` example contradicts the actual rule | | 9 | medium | packaging | `simready ingest usd` doesn't lift companion thumbnails into spec layout | | 10 | high | rule reliability | Rule crashes on `JointStateAPI` access → ~600 UNKNOWN issues per asset | | 11 | high | spec/packager mismatch | NP.005 expects `//
.usd`; packager produces flat layout. Plus `relpath(file,…)` should be `relpath(found_file,…)` | | 12 | high | rule scoping | "Example" tutorial capability (`EX.*`) is active in production validation | | 13 | medium | rule duplication | `EX.01` and `VG.MESH.001` are the same check | | 14 | high | rule correctness | `HI.002` rejects matrix transforms (`xformOp:transform`) and identity transforms | | 15 | medium | rule correctness | `NP.001` rejects the conventional `/Looks` scope name | | 16 | high | rule correctness | `OmniPBR.mdl` (standard NVIDIA MDL) doesn't resolve; both VM.MDL.001 and NP.008 fire on the same attribute | | 17 | medium | spec ambiguity | `RC.002` flags spec-looking `isaac:*` metadata as illegal "overrides" |