THE LINUX FOUNDATION PROJECTS

OpenUSD Core Spec 1.0 is Here. Details »

Authors: Aaron Luk, Nick Porcino

We have reached a massive milestone. The OpenUSD Core Specification 1.0 is officially ratified.

For those of you who have been following along, you know this has been a journey involving meticulous drafting, spirited debates over composition fundamentals, and more than a few late-night GitHub commits. But for those just tuning in, you might be asking: What exactly is in the box? And more importantly, what does this mean for me?

Here is the rundown of what we’ve built, why it matters, and what it’s going to take to get to 1.1 and beyond.

What’s in Core Spec 1.0?

Think of the Core Spec as the syntax and grammar of a spoken language. It defines the structural rules such as how to construct a sentence or how verbs relate to subjects. It does not dictate the specific vocabulary of a medical textbook or legal contract (that’s for domain-specific specs like Physics and Materials), but it ensures that anyone speaking the language can parse the intent, regardless of the topic. 

Core Spec 1.0 delivers six essential pillars:

  1. Grammar and Data Types: Formal specification of OpenUSD’s human-readable grammar and foundational data types.
  2. Document Data Model: A file-format agnostic model for how inputs to composition and other foundational document fields are organized.
  3. Composition Algorithm: A normative specification of the composition algorithm—the “secret sauce” of how USD non-destructively aggregates heterogeneous data sources.
  4. Stage Population & Value Resolution: A predictable way to populate and traverse the scene graph, and query values for every object.
  5. File Formats: Detailed specifications for USDA (human-readable), USDC (binary), and USDZ (packaged) interchange formats
  6. Compliance Framework: Clear rubric for implementers to validate conformance

To prove this actually works, we’ve also released sample implementations for compliance testing. These let you verify your own tools against the spec, covering foundational data types like ListOps (crucial for declaring references and applied schemas, for example) and parsers for file formats like the human-readable USDA format.

Decoupling Intent from Implementation

In modern development, we often distinguish between the high-level intent of a system and the specific code that executes it. A normative specification functions similarly across the entire industry. We codify the concepts in normative language without tying them to one specific codebase so we can rally around a shared architectural intent and first principles. 

Why does this matter for you?

  • Interoperability: It allows different vendors to build independent tools that are implemented differently but behave identically.
  • Lightweight Alternatives: It enables projects to exist and implement the rules defined by the spec.

The Reality of Standardization

Writing a standard starts fundamentally with an understanding of the domain; an audit of what will be covered. The process of writing Core Spec 1.0 actually revealed ambiguities and even a few bugs in the OpenUSD codebase. Standardization forces us to be precise, which makes the technology better for everyone.

The reality of this process is that writing a specification is hard work. We faced challenges scoping a rapidly evolving technology – while drafting 1.0, new features like Animation Splines and Relocates landed in the codebase. We made tough calls on what to include now versus what to push to a fast-follow release to maintain momentum without sacrificing quality.

Keeping the Momentum: We Need You

OpenUSD has reached this milestone because many contributors across the community have already invested time, expertise, and resources into the work so far.

This brings us to the most critical realization of this process: standardization is not a spectator sport.

The delivery of Core Spec 1.0 highlights a vital operational reality: the velocity of our roadmap depends entirely on active contribution. The community rallied around our member organizations’ collective effort to deliver a document we are proud to publish.

Resource constraints can throttle our momentum. While membership fees provide the infrastructure, the hosting, and the legal frameworks, fees alone do not write a standard. 

If your organization relies on OpenUSD, contributing to the spec is the most effective way to ensure the standard evolves to meet your production needs. We need engineers who are formally empowered to make standardization part of their core responsibilities—ensuring this critical infrastructure is built during the work week, not on the margins of it.

What’s Next? 

We aren’t resting on 1.0. We are already planning a 1.1 fast follow for 2026. This release will target several key areas, including:

  • Animation Spline parity with OpenUSD v25.08+
  • Variable & Path Expressions
  • Compliance Rubric improvements

Confidence in a standard comes from predictability, so we are establishing a regular release cadence. But quality comes from debate.

If you have strong opinions on how these features should work—or what didn’t make the list—the Core Spec Working Group is where those decisions are being made right now. Joining the working group will give you a voice in the ongoing process: contributing to the fundamental work of creating the specification, and critically, helping to determine priorities, and approving them through your vote.

Call to Action

Core Specification 1.0 is just the starting point. Let’s build the rest of the pillars together.

Starting today, developers can read the core specification, sample implementations and compliance tools and provide feedback on forum.aousd.org.

If your company is interested in joining the Alliance for OpenUSD (AOUSD) and contributing to the Core Specification Working Group, sign up to become a member. To read more about the Core Spec announcement, see the press release.

Learn more about the latest OpenUSD advancements from AOUSD members: