A validator report answers a bounded question: which checks ran against which inputs, under which tool build and settings? A clean result does not establish that every dependency was included, that every variant or time sample was examined, or that the asset meets a downstream CAD or visualization task. Keep the report with its scope and test the actual delivered package separately.
Choose checks for the delivered representation
Before running a validator, record the format and package form, tool name and version or build, command or API entry point, selected profile, and the files supplied to the check. Note whether the package is a USD layer or composed stage, a USDZ archive, a glTF JSON asset, or a GLB binary. The input boundary matters: a check that receives one layer cannot establish that an external resolver or recipient environment can find every referenced asset.
| Representation | Example checks and scope questions |
|---|---|
| USD stage or layers | Which selected usdchecker checks ran? Did the check follow the package boundaries and composition paths that matter? Were variants and time-sampled values covered by the selected checks? |
| USDZ package | Did the chosen tool inspect the archive and its package constraints? Were package-relative assets resolved from the delivered archive, rather than from the sender’s workspace? |
| glTF JSON or GLB | Did validation cover JSON/schema structure, buffer and image references, binary chunks, and the extensions the asset uses? Which resources were embedded and which were external? |
OpenUSD’s usdchecker documentation exposes selected checks and strictness options; it describes limitations such as checking only the first sample of some time-sampled attributes. The OpenUSD validation framework and NVIDIA USD Validator add selectable checks or profiles, with machine-readable reporting. Treat the profile and options as part of the result, and review warning policy rather than reducing every warning to a pass/fail label. If an auto-fix is available, preserve the original, record the transformation separately, and validate the transformed result again.
OpenUSD’s release and development documentation are versioned separately. Match a documented behavior to the installed build and record its exact version; development documentation does not by itself establish support in a released application.
The Khronos glTF Validator checks such things as asset structure, references, buffers, images, and supported extensions, and can emit a JSON report. This provides useful structural and resource diagnostics for the supplied glTF input. It does not prove visual equivalence, CAD semantics, editability, or acceptance by a particular renderer or downstream operation.
Make selection and gaps visible
Some checks inspect only selected content. For a USD stage, record which variant selections, layers, payloads, and time range were active. For a glTF asset, record the extension requirements and the resources the validator actually received. For either family, report unsupported features, skipped checks, unresolved dependencies, warnings, and errors with the tool’s own classification.
Use a concise record alongside the report:
input: "asset or package identifier and hash"
representation: "USD, USDZ, glTF JSON, or GLB; version/profile where relevant"
validator: "tool, version/build, command or API"
selection: "profile, checks, variants, time range, and input boundary"
result: "report location and summarized errors/warnings"
not_checked: ["external resolver in recipient environment", "downstream task"]
changes_after_check: []
The record makes a later comparison reproducible. It does not replace the full report or package manifest.
Test the acceptance case too
After structural checks, test the package from a clean recipient-like location and run the operation that motivated delivery. Check whether referenced content resolves, selected variants appear as intended, and the recipient can perform the named view, review, coordination, or production task. If the actual requirement is a project-specific IFC information rule, use an IDS-based check; if it is geometry or visual output, define and run that comparison separately.
Keep four claims distinct: the validator ran; the supplied input passed the selected checks; the package works in the recipient context; and the asset meets its intended task. Only report the strongest claim supported by the corresponding evidence.
Key points
- Pin the tool build, input boundary, profile, and selection with each report.
- Record variants, time coverage, dependencies, skipped checks, and warnings.
- Preserve originals and describe automatic fixes as transformations.
- Re-test the delivered package and the downstream task separately from validator conformance.