OpenUSD Core Specification 1.1 and v26.08: What CAD, PLM and Digital Twin Teams Decide in 2026

Almost everything written about Universal Scene Description is a rendering story. The July 2026 news is not. When the Alliance for OpenUSD announced that it had begun the ISO certification process for the OpenUSD Core Specification 1.1 and moved the specification into a public GitHub repository, it changed who has to care about USD inside a manufacturer — and it moved the decision from the visualisation team to the people who write tender documents and own the engineering record. An ISO-certified interchange format is not a nice-to-have in automotive, aerospace or government procurement; it is a line item that vendors must answer. That reframing, plus three new foundational schemas in OpenUSD v26.08, is the reason a CAD or PLM group should spend an afternoon on this now rather than in two years.

What this covers: what the 1.1 milestone actually is (and is not), what Profiles, Multiple Level-of-Detail and Backplates do mechanically, and a two-track architecture that keeps STEP and JT authoritative while OpenUSD carries composition.

Context and Background

OpenUSD came out of Pixar, was open-sourced in 2016, and spent its first decade being adopted by tools whose main job was to make pictures. The Alliance for OpenUSD (AOUSD) formed in 2023 under the Joint Development Foundation, an affiliate of the Linux Foundation, with Adobe, Apple, Autodesk, NVIDIA and Pixar as founding members. Its explicit purpose was to turn a widely-used codebase into a specified standard — which is a different and much harder thing.

That work reached its first milestone on 17 December 2025, when AOUSD announced Core Specification 1.0. Core Spec 1.0 deliberately introduced no new features. It documents the minimum behaviour a piece of software must implement to claim OpenUSD compliance: the syntax of the layer formats, the composition engine’s arc semantics, and deterministic value resolution — the rule that two conforming implementations, given the same stage, must resolve the same attribute to the same value. Pixar CTO and AOUSD chair Steve May framed it at the time as the first step toward ISO standardisation.

For engineering-data teams the relevant detail is that determinism is the whole point. A format you can only view is a preview. A format whose resolution rules are specified is something you can put under change control, diff, validate and archive. That distinction is exactly the one that separates OpenUSD’s traditional VFX use from the industrial use this post is about, and it is why the site’s OpenUSD industrial digital twin architecture guide treats composition, not rendering, as the interesting surface.

The incumbents in that space have not moved. STEP AP242 (ISO 10303-242) remains the exchange format for model-based definition with product and manufacturing information; JT (ISO 14306) remains the lightweight visualisation and supplier-exchange format that most large OEM pipelines actually run on. Neither is going away, and neither has an answer for scene composition across thousands of assets. That gap — authoritative geometry on one side, composable scenes on the other — is the space OpenUSD is walking into, and the 2026 news is the first time the walk has a procurement dimension attached to it.

Why the OpenUSD Core Specification 1.1 Milestone Is a Procurement Event, Not a Graphics One

AOUSD’s July 2026 announcement says the Alliance has begun the ISO certification process with the Core Specification 1.1 release, describes it as the first step toward international standardisation, and states plainly that ISO certification “removes procurement friction” for manufacturing, automotive and government organisations that require compliance with international standards. Nothing has been certified. No ISO number, committee or completion date has been published. What exists is a process that has started, and a public repository you can read today.

Figure 1: The two-track split — authoritative geometry stays in STEP AP242 and JT under PLM control, while OpenUSD carries composition, configuration and the simulation handoff.

The diagram shows a single authoring source feeding two distinct downstream paths. The left track publishes the authoritative record into STEP AP242 or JT and vaults it in PLM with revision identity and PMI intact. The right track publishes a derivative — tessellated, renamed, stripped of tolerances — into an OpenUSD layer that composes variants and level-of-detail, hands off to simulation, and receives simulation results back as an overlay layer rather than as an edit to the source. A change event in PLM re-triggers the derivative publish; it never flows the other way.

What the 1.1 milestone actually gives you today

The concrete, checkable artifact is the repository at github.com/aousd/specifications-public. AOUSD publishes each specification in two forms: a PDF with rendered railroad diagrams and typographic layout, and a Markdown version described as the machine-readable artifact for tooling, search indexing and agent consumption, in which railroad diagrams appear as source grammar blocks. Releases are identified by name, version and a source commit hash printed in the document subtitle. Published versions are immutable; errata are filed as issues and folded into a later release. The licence is CC BY-ND 4.0 — you may redistribute the specification, you may not publish a modified version of it.

Two things follow that matter operationally. First, “propose a change” is now a pull request and an issue tracker rather than a membership conversation, which is the single most useful thing that happened in July for a team that has found a genuine ambiguity in composition behaviour. Second — and this is the part worth checking before you write anything into a tender — as of this writing the repository’s own availability table lists Core 1.0.1, released 2025-12-12, as the published Core stream. The 1.1 text entering certification is not yet sitting in that table. If your procurement language needs to cite a version, cite what is published and describe 1.1 as in progress.

What “begins the ISO certification process” does and does not license you to say

Standardisation processes are long and they fail in public. The correct internal framing is a conditional one: if the Core Specification completes international standardisation, then buyers who are contractually obliged to prefer international standards gain a defensible reason to require OpenUSD deliverables, and vendors gain a reason to implement the specification rather than approximate it. Neither half of that conditional is true yet.

What you can act on now is the direction of travel and the cost of being unprepared. Preparing means knowing which of your tools read and write USD, which parts of USD they actually implement, and what your authoritative record looks like when a USD deliverable is demanded. None of that preparation is wasted if the process stalls, because every item on the list is something you need for the simulation handoff regardless.

The scope AOUSD has signalled for 1.1 is worth reading with engineering eyes rather than marketing ones: animation features, scaling for massive and complex scenes, and refined guidelines for testing software compliance. The third item is the one that changes vendor conversations. Compliance testing guidance is what converts “we support USD” from a marketing claim into a pass or fail you can put in an acceptance test.

What deterministic value resolution actually buys a change-controlled pipeline

It is worth being concrete about the property Core Spec standardises, because “deterministic value resolution” sounds like boilerplate and is not. USD resolves an attribute by walking composition arcs in a fixed strength order — local opinions first, then inherits, variant sets, references, payloads and specializes — with sublayers ordered strongest-first within a layer stack. The strongest opinion found wins, and weaker opinions are not merged, they are shadowed.

That single rule is what makes the right-hand track in Figure 1 safe. Simulation results, annotations, review markup and operator state can each land in their own layer, stacked above the published derivative, and none of them modifies the derivative. Remove the layer and the stage returns exactly to the published state. There is no merge conflict to resolve because there is no merge, and there is no “apply changes” step that could partially succeed.

For a PLM group used to reasoning about check-in and check-out, the mental model is closer to a stack of transparent overlays than to a branch. It also explains why the composition layer is a poor place to keep authoritative data: an opinion is only authoritative relative to the layers currently in the stack, and the stack is assembled at load time by whoever opened the stage. An overlay you forgot to remove changes the answer, silently and reproducibly. Discipline about what may author an opinion, and where, is the operational cost of this design.

The practical consequence is a rule worth writing down: any layer that can be authored by a downstream consumer must be weaker than the published derivative for geometry, and may be stronger only for data the derivative does not own — visualisation state, annotations, simulation outputs. Encoding that as a layer-stack policy, and validating it at load, prevents the entire class of incidents where a review overlay quietly changed a dimension.

The working groups you are actually waiting for

Core Spec is composition and value resolution. It is not geometry semantics, not materials, not physics. AOUSD’s Geometry, Physics and Materials working groups each have 1.0 releases described as expected later in 2026 — which means, on 19 September 2026, that none of them has shipped. For a manufacturing team this is the honest state of play: the layer that says how a scene composes is being standardised first, and the layers that say what a surface or a joint means are still ahead.

That ordering is defensible and it is also inconvenient. It means an OpenUSD deliverable today carries a guaranteed-composable scene graph whose domain semantics are still governed by de facto conventions and vendor agreement. Plan your acceptance criteria around composition behaviour, which is specified, and around explicit bilateral agreement on geometry and material conventions, which is not.

Agentic AI is the second procurement lever

The July announcement’s other theme is that OpenUSD is becoming the 3D data layer for agentic workflows, with three named early implementations: Cesium’s AI integrations and agentic skills for making geospatial data readable to agents; a PTC multi-agent workflow that automatically prepares Onshape CAD models in OpenUSD for robotics simulation with NVIDIA; and NVIDIA’s nanoUSD-labs, an experimental project exploring agent-guided generation of a portable, embeddable implementation of the Core Specification.

The PTC example is the one CAD and PLM teams should read twice. It is a direct claim that the CAD-to-simulation preparation step — the tedious, manual, error-prone one — is being automated against OpenUSD as the target representation. If that automation matures, the format your CAD system can publish stops being an aesthetic preference and starts determining whether a class of tooling works on your data at all. nanoUSD-labs points the same way from the other end: a small, embeddable Core Spec implementation is what you need to put USD reading inside a controller, a gateway or a test rig, rather than only inside a workstation.

Reading v26.08: Three Schemas That Happen to Be Engineering Hooks

OpenUSD v26.08 was published on GitHub on 20 July 2026 and described by AOUSD the following day as a schema-focused release. Rather than one headline feature it delivers three new foundational schemas — Profiles, Multiple Level-of-Detail and Backplates — alongside continued work on OpenExec, splines, the namespace editor and platform support. The non-imaging core libraries install from PyPI as usd-core. Two of the three schemas are far more interesting to an industrial team than to a VFX one, which is unusual and worth explaining.

Profiles: the capability negotiation USD never had

Profiles is the release’s most consequential addition for interoperability, and it addresses a problem every CAD group already has in a different format. USD is deliberately large and applications implement the subset they need. Given an asset and a tool, there has never been a way to establish whether that tool can faithfully open, edit and round-trip the asset other than by trying it and inspecting the result.

Profiles gives USD a formal vocabulary for declaring and querying capabilities. A capability is an identifier for a specific piece of functionality, named in reverse-domain notation — usd.geom.skel, usd.image.jpeg. Capabilities are organised into a directed acyclic graph in which each capability derives from its predecessors, so usd.image.jpeg implies usd.image. A profile is a coherent set of capabilities defined by its predecessors in that graph. Capabilities span three domains: Layer (file-format features such as an encoding or compression), Prim (schema-specific functionality such as skeletal animation), and Application (tool support such as physics simulation or a particular import/export path).

Figure 2: How a capability is declared and queried — authored declarations via ProfileAPI, schema-implied declarations via plugin metadata, and the two query modes that trade cost against completeness.

The diagram separates declaration from query. On the declaration side, an author can apply a ProfileAPI to a prim to state conformance directly, and a schema can advertise the capabilities it requires through plugin metadata in plugInfo.json and schema.usda. To support the latter, v26.08 adds schema-implied capabilities and allows array values in the extraPlugInfo dictionary in usdGenSchema, so a schema can enumerate its dependencies at generation time. On the query side, an explicit query reads declared capabilities and is fast and cacheable; an introspective query infers capabilities by examining the composed scene, which is more complete and more expensive.

That cost asymmetry is the design decision to reason about. An explicit query is a metadata read — cheap enough to run on every asset at ingest, cacheable against a layer hash, and therefore suitable as a gate in a publish pipeline. An introspective query composes the stage and walks it, which for a large assembly is the expensive operation you were trying to avoid. The sensible pattern is explicit-first with introspective fallback only on mismatch, and that is exactly what a validator should encode. AOUSD says tool and pipeline support, including validation through usdchecker, is coming in later releases — so today this is a schema you can author against and a query you can call, not a turnkey gate.

For a PLM group the mapping is almost too neat. Profiles is the USD equivalent of a conformance class, and conformance classes are how STEP has managed exactly this problem for decades. The difference is that a USD capability declaration lives inside the asset and is composable, so a referenced sub-assembly can carry its own declaration and an aggregating stage can be checked against the union.

Multiple Level-of-Detail: configuration control the runtime can honour

Renderers and engines have always swapped between representations of an asset to trade quality against performance, and until v26.08 USD had no standard way to describe those alternatives — so every application invented its own convention. The new UsdLod schema provides a shared framework for authoring multiple detail levels and letting the runtime choose among them without modifying the scene graph.

It is built from three pieces. UsdLodRootAPI marks a prim as the root of an LoD hierarchy and carries lod:heuristics plus a fallback lod:default:index for when no heuristic applies; LOD children are declared in the prim scope and the child index is the LOD index, so /Tree as an LoD root might hold meshes at /Tree/LOD0 (highest detail), /Tree/LOD1 and /Tree/LOD2 (lowest). UsdLodHeuristic is the abstract base for selection logic, and two concrete heuristics ship in this release: UsdLodDistanceHeuristic selects by distance from the viewpoint, UsdLodScreenSizeHeuristic by projected screen coverage. UsdLodOverrideAPI bypasses heuristics entirely through lod:override:mode and lod:override:index.

Figure 3: Deterministic LoD selection — override first, then heuristic prims in declared order, then the authored fallback index.

Selection is deterministic: check for an override, evaluate heuristic prims in turn, then fall back to lod:default:index. The schema also supports custom domains using a company or product prefix, nested LoD roots, non-integer indices for cross-fading, and hysteresis to prevent flicker near a threshold.

Determinism is why this matters outside graphics. A plant-scale twin is far too large to load at full fidelity on any client, so every serious deployment already has a representation-swapping scheme — it is just bespoke, undocumented and unportable. Standardising it means the swap policy travels with the asset, which in turn means a review session, a training run and an operator display can be made to agree on which representation they are looking at.

The UsdLodOverrideAPI is the specific hook for engineering use. Heuristics are viewpoint-dependent and therefore non-reproducible: two people looking at the same stage from different cameras see different geometry. An override is an authored fact, so a test harness, a clash check or a measurement workflow can pin the hierarchy to LOD0 and know it got the detailed representation. If you take one implementation note from this section, make it that: heuristics for humans, overrides for anything whose result you intend to trust.

The non-integer index provision deserves a caution. Cross-fading between LODs is a rendering behaviour with no meaning in a geometric query, so an index of 0.5 is not “the average of two meshes” — it is a blend instruction. Do not let a non-integer index reach anything that computes on geometry.

Backplates: useful to you, and not for the reason it was built

UsdGeomBackPlateAPI is a multiple-apply schema describing fixed images composed behind rendered geometry, usually tied to a specific camera. Its origin is unambiguously VFX — match moves, object replacement, scene extension — and several backplates can attach to one camera for multi-plane composites with true parallax. Each instance exposes a colour image plus optional AlphaImage and DepthImage for matte and depth compositing; PlateVisibility to toggle the plate for all cameras, only the owning camera, or none; LumaGain, LumaGamma and LumaLift for tonal response; and TranslateTweak, RotateXYZTweak and ScaleTweak plus depth offset and normalisation controls for framing and depth integration.

AOUSD calls out two non-VFX uses directly, and they are the ones to pay attention to. Backplates are useful in photogrammetry because they bundle a camera’s pose with the picture that camera took. And they are useful in machine learning because they provide a way to associate readings from machine-vision cameras with spatial tracks — the kind produced by a rover or an autonomous vehicle.

Read that as a standardised container for “this image, from this pose, in this scene.” For an industrial twin that is the missing link between a fixed inspection camera and the 3D model it inspects. Today, camera extrinsics for a plant camera live in a config file, a database row, or a comment. Putting them in the stage as a schema-typed relationship to a camera prim makes the association composable, overridable per layer and diffable — which is a genuinely better data model for vision-fed twins than what most deployments have.

One honesty note on maturity, because the source material is internally inconsistent. The AOUSD post’s highlights list backplate visualisation in usdview, and the body says the release includes a Hydra scene index and Storm implementation making backplates immediately available to Hydra and Storm users — but the same post then carries an explicit note that these backplate features are not yet implemented in the Storm Hydra render delegate and so will not be visible in usdview. Treat the schema as authorable and the interactive visualisation as not yet dependable, and verify against your own build before promising anyone a preview.

Where each format wins, and why the split holds

The two-track recommendation is easier to defend when the axes are written out rather than argued. The matrix below compares the formats a manufacturing pipeline realistically has on hand, on the dimensions that decide which track a data class belongs to.

Capability	STEP AP242	JT	OpenUSD	glTF
Precise B-rep geometry	Yes, native	Yes, optional B-rep alongside tessellation	No, tessellated derivatives	No
PMI, tolerances, datums	Yes, semantic and presentation	Yes, in supported profiles	Not defined by Core Spec	No
Scene composition across assets	Assembly structure only	Assembly structure only	Yes — layers, references, payloads, variants	Scene graph, no composition arcs
Non-destructive override of a third-party asset	No	No	Yes, by layer strength	No
Standardised level-of-detail selection	No	Vendor-specific	Yes, as of v26.08	Extension-dependent
Declared capability negotiation	Conformance classes	Vendor profiles	Yes, as of v26.08 Profiles	Extension list, informal
Long-term archival posture	Strongest — decades of ISO practice	Strong, widely vaulted	Immature for archival	Weak
Streaming to a lightweight client	Poor	Good	Payload-dependent	Strongest

Read across a row rather than down a column. No format wins everywhere, and the two rows that changed in July 2026 are the two that OpenUSD now owns outright: standardised LoD selection and declared capability negotiation. Neither STEP nor JT has an equivalent to a composable, per-asset capability declaration, and neither has a mechanism for overriding a supplier’s asset without editing it.

That is the whole argument for the split. The left track exists because the archival and PMI rows are unambiguous and are not going to move. The right track exists because the composition, override and negotiation rows are things a twin needs every day and the authoritative formats do not provide. A team that tries to collapse the tracks is choosing to lose one of those two halves, and which half it loses depends on which format it picks — which is a bad way to make the decision.

For the runtime end of the right track, the practical comparison is between engines rather than formats, and our breakdown of Omniverse, Unreal and Unity for digital twins covers how differently each consumes a composed stage.

Trade-offs, Gotchas, and What Goes Wrong

The two-track architecture in Figure 1 is a recommendation with real costs, and the failure modes are specific.

Figure 4: An ingest gate built on Profiles — explicit query first, introspective scan only on mismatch, and a named-capability quarantine rather than a silent partial load.

Derivative drift is the default outcome. The moment you publish a USD derivative alongside an authoritative STEP or JT record, you have two representations that can disagree. Every drift incident I have seen traces to a publish step that was triggered manually. Bind the derivative publish to the PLM change event, stamp the derivative with the source revision identity, and make a mismatch a hard failure in the consumer rather than a warning.

Semantics you assume are specified are not. Core Spec covers syntax, composition and value resolution. Geometry, Physics and Materials 1.0 have not shipped. A stage that composes identically in two tools can still be interpreted differently at the domain level — units, up-axis conventions, material parameter meaning. Write these into a bilateral profile document with your partner; do not assume the standard carries them.

Profiles declarations go stale. A declared capability set is metadata, and metadata written once and never revalidated is a lie waiting to be believed. If a downstream author edits a referenced layer and adds a capability the aggregate declaration does not mention, the explicit query now returns a confident wrong answer. This is why Figure 4 routes a declaration-stale result back to re-authoring rather than to rejection, and why the introspective query needs to run on some schedule even when explicit queries pass.

PMI does not survive the derivative path, and should not. Tolerances, datums and geometric dimensioning are the authoritative record’s job. Publishing them into a tessellated USD derivative produces something that looks authoritative and is not — the single most dangerous artifact in this architecture. Keep them on the left track. Our comparison of STEP AP242, JT and QIF for MBD and PMI covers why those formats carry PMI semantics that a scene-description layer does not attempt to.

LoD heuristics quietly change what a downstream process measured. Covered above, but it is the failure mode most likely to reach production silently, because the wrong answer still renders.

Certification timelines are not plans. Do not let a roadmap slide promise an ISO-certified OpenUSD deliverable by a date. The process has begun. That is all anyone can currently say.

Practical Recommendations

The right posture for the next two quarters is preparation without commitment. Nothing in the OpenUSD Core Specification 1.1 announcement requires re-platforming, and nothing in it justifies waiting either — the work that makes you ready is work you need anyway for simulation handoff.

Start by making the two-track split explicit in writing, because most organisations have it implicitly and inconsistently. Name the authoritative format per data class, name the derivative, and name the one event that triggers republication. Then inventory what your tools actually implement rather than what their datasheets claim, using Profiles vocabulary as the checklist even before tooling enforces it — the exercise of enumerating capabilities is where the surprises are. Treat the AOUSD repository as a live source and subscribe to it.

A concrete checklist:

• Record which of your CAD, PLM, visualisation and simulation tools read USD, which write it, and which round-trip it without loss.
• Pin the authoritative format per data class — geometry, PMI, BOM structure, kinematics — and write down which one wins on conflict.
• Bind derivative USD publication to a PLM change event and stamp every derivative with the source revision identity.
• Add an ingest gate that runs an explicit Profiles query, with an introspective fallback on mismatch and a named-capability quarantine on failure.
• Author UsdLodOverrideAPI on any hierarchy whose geometry feeds a measurement, clash check or automated test; reserve heuristics for human viewing.
• Watch the Geometry, Physics and Materials working groups; do not write acceptance criteria against specifications that have not shipped.
• Keep tender language conditional on certification status and cite the published specification version, not the one in process.
• Evaluate whether the CAD-to-simulation preparation step in your pipeline is a candidate for the automated OpenUSD workflows now appearing.

Frequently Asked Questions

Is OpenUSD an ISO standard?

No. AOUSD announced in July 2026 that it has begun the ISO certification process with the Core Specification 1.1 release, describing it as the first step toward international standardisation. No ISO number, committee or completion date has been published, and the process being underway is not the same as certification being granted. Until it completes, treat any procurement language that assumes an ISO-certified OpenUSD as conditional. The published Core stream in the AOUSD public repository remains version 1.0.1.

Does OpenUSD replace STEP AP242 or JT?

Not for authoritative engineering data. STEP AP242 and JT carry product and manufacturing information, tolerances, datums and the long-term archival semantics that a scene-description format does not attempt to define. OpenUSD’s strength is composition — layering, referencing, variants and deterministic value resolution across thousands of assets. The workable 2026 architecture keeps the authoritative record in STEP or JT under PLM control and uses OpenUSD as the composition and simulation-handoff layer above it.

What are Profiles in OpenUSD v26.08?

Profiles give USD a formal vocabulary for declaring and querying capabilities, so you can reason about whether a tool can faithfully open, edit and round-trip an asset. A capability is a reverse-domain identifier such as usd.geom.skel, organised into a directed acyclic graph where each capability derives from its predecessors. Capabilities span Layer, Prim and Application domains. Authors declare them with a ProfileAPI, schemas imply them through plugin metadata, and consumers query them either explicitly or introspectively.

Why does the new Multiple Level-of-Detail schema matter outside graphics?

Because it makes representation swapping deterministic and portable. Before v26.08 every application invented its own LoD convention, so a twin, a review session and a training run could silently disagree about which representation they were using. UsdLodRootAPI plus the distance and screen-size heuristics standardises the runtime behaviour, and UsdLodOverrideAPI lets you pin a hierarchy to a specific index — which is what any measurement, clash check or automated test needs in order to be reproducible.

Have the Geometry, Physics and Materials specifications shipped?

No. AOUSD described the 1.0 releases from those three working groups as expected later in 2026, so as of September 2026 they are not available. This matters for planning: Core Spec standardises how a scene composes and how values resolve, not what a surface or a joint means. Until those specifications land, domain semantics between two parties exchanging OpenUSD remain a matter of bilateral agreement, and acceptance criteria should be written accordingly.

Can I propose changes to the OpenUSD Core Specification?

Yes, and that is the most immediately usable outcome of the July 2026 milestone. AOUSD now hosts the specification in a public GitHub repository with an issue tracker, publishing each release as both a PDF and a machine-readable Markdown artifact under a CC BY-ND 4.0 licence. Released versions are immutable; errata reports are triaged by the relevant working group and corrections are folded into a subsequent release. General discussion goes to the AOUSD forum rather than the tracker.

Further Reading

• OpenUSD for industrial digital twins: architecture guide — how composition, layering and payloads behave at plant scale.
• STEP AP242 vs JT vs QIF for MBD and PMI — why the authoritative track stays where it is.
• Omniverse vs Unreal vs Unity for digital twins — runtime choices downstream of the composition layer.
• Industrial metaverse and Omniverse digital twin reference architecture — where the simulation handoff lands.
• AOUSD: Announcing OpenUSD v26.08 — the primary source for Profiles, Multiple LoD and Backplates.
• AOUSD Core Specification public repository — published specification versions, licence terms and the errata tracker.

By Riju — about