“Supports IFC,” “opens STEP,” or “loads glTF” describes a family label. A useful exchange statement identifies the particular scope inside that family and what happens when the receiver encounters information outside it.
One family can contain several contracts
Separate these questions:
- Schema: Which entities, properties, relationships, and constraints exist?
- Application protocol or domain scope: Which subset of a larger model is assembled for a particular application area?
- Profile or model view: Which constrained view or information requirement is expected by a consumer?
- Extension: Which additional capability is present beyond the core representation?
- Status and release: Is this scope official, withdrawn, retired, under development, or tied to a particular version?
The names are not interchangeable. A product can support one release or view and not another. A file can declare an extension that the receiver does not implement. A specification can define all of them without proving that a product maps them correctly.
STEP: architecture is not a route
The public ISO 10303-1:2024 overview describes architectural principles for the ISO 10303 series and lists application protocols, implementation methods, conformance-testing concepts, and schema identification among its scope. This is enough to establish that the series has more structure than a single “STEP” label.
It is not enough to infer a product route. The overview does not tell you which application protocol a particular exporter writes, which implementation method a receiver uses, or which product data survives the mapping. Those are product- and route-specific questions.
Edition and lifecycle status also belong in the record. On the ISO page accessed 2026-09-26, ISO 10303-242:2025 (Edition 4), titled Managed model-based 3D engineering, is listed as published at stage 90.92 (“to be revised”), with a replacement under development. This identifies the edition and its recorded lifecycle; its broad scope and publication status do not prove that a product implements it or that an exchange contains any particular information.
IFC: release and view context matter
The buildingSMART IFC release database lists IFC 4.3.2.0 as an official release. On the accessed page, IFC 4.4 and IFC 5 are marked as under development, while other entries are marked official, withdrawn, or retired. Treat those status values as part of the representation record; do not turn a development entry into a compatibility recommendation.
The page expresses IFC versions as Major.Minor.Addendum.Corrigendum. Its explanation says major changes may break compatibility; minor versions extend features with compatibility guaranteed for the core schema but not other definitions; addendums improve existing features with upward compatibility guaranteed; and corrigendums improve documentation, although deprecation may be possible. These are release-notation statements, not application support guarantees.
When an IFC workflow relies on a particular view or information requirement, record it alongside the release and schema. The schema tells you what the model can express; the selected view or requirement helps define what the receiving workflow expects. Confirm that the sender and receiver use the same interpretation before treating a schema match as sufficient.
Extensions: used is not always required
glTF makes extension scope explicit. The specification requires every extension used by an asset to appear in the top-level extensionsUsed array. Extensions required to load or render the asset must also appear in extensionsRequired, and extensionsRequired is a subset of extensionsUsed.
That distinction creates two different receiver questions:
- Does the receiver recognize an extension that may improve or add information?
- Does the receiver support an extension required to load or render the asset?
The declaration improves the receiver’s ability to make a compatibility decision. It does not prove the receiver implements the extension or preserves its information after translation.
Extension status and fallback add more scope. The Khronos registry separates ratified, draft or proposed, vendor-prefixed, and archived extensions, and ties each extension to a glTF version; those registry labels can change. For example, KHR_texture_basisu describes KTX v2 images with Basis Universal supercompression and includes a PNG fallback in its example. The fallback and extensionsRequired declarations help characterize loading expectations, but they do not prove that a particular runtime will transcode or render the asset as intended.
3MF provides another bounded example. Its Core Specification v1.3.0 defines core and extension versions independently through XML namespaces. It also allows a producer to mark an extension as required; a consumer that does not support a required extension must fail to edit or manufacture the document rather than silently ignore it. The exact behavior belongs to that specification version and extension scope.
The published Materials and Properties Extension v1.2.1 is separate from the Core version and describes material, color, texture, and related resources. The Displacement Extension v1.0 adds textured-mesh displacement and states that it must be used with Core 1.x. A .3mf suffix alone does not identify either payload or establish that a consumer or printer supports it.
OpenUSD Profiles describe capabilities, not a support guarantee
The Alliance for OpenUSD’s v26.08 announcement describes Profiles as a vocabulary for declaring and querying capabilities. It groups capabilities by layer (such as encoding or compression), prim (schema functionality), and application (such as simulation or import/export). Capability identifiers can imply predecessor capabilities, and a profile is a coherent set built from those relationships.
The announcement describes applying ProfileAPI to a prim and declaring schema requirements through plugin metadata. It distinguishes explicit queries, which read declarations, from introspective queries, which inspect the composed scene. These declarations help identify intended scope; they do not prove that a named application implements it. The announcement says usdchecker support is upcoming, so do not assume that it validates Profiles in v26.08.
The same release announcement describes UsdLod for authoring alternate levels of detail, with distance or projected screen coverage heuristics, an explicit override, and a default index. The stated selection order is override, heuristic, then default. This is schema behavior as described by AOUSD, not evidence of support or visual equivalence in a particular renderer.
A sender-and-receiver checklist
Ask for these values before a transfer:
| Check | Sender should identify | Receiver should confirm |
|---|---|---|
| Core representation | Format, schema, or family | The exact supported scope |
| Release and status | Version and whether it is official, development, withdrawn, or retired | Supported release and any conversion rule |
| Application scope | AP, domain scope, profile, model view, or information requirement | The view or subset the workflow consumes |
| Extensions | Used, required, and their versions where applicable | Supported, ignored, rejected, or mapped behavior |
| Encoding/container | Text or binary form and package type | Reader and parser support |
| Fallback | What may be omitted or represented differently | Whether the workflow can proceed safely with that result |
| Purpose | The operation the receiver must perform | Acceptance checks for that operation |
Use an explicit unknown rather than assuming the broadest scope. If a required extension or view is not supported, a cleanly opened file may still be unsuitable for the intended task.
Follow the implementation question
Directional and versioned support shows how to read a product support declaration. Translation mechanics explains why a declared scope still has to be mapped into the destination’s data model. For information-layer acceptance, continue to the portal categories on geometry, structure, and engineering semantics.
Key points
- A format family can contain multiple schema, release, view, profile, and extension scopes.
- An OpenUSD capability profile or LoD schema describes declared scope and selection rules, not verified application behavior.
- Official status does not prove product support; product support does not prove preservation.
- Required extensions demand a different receiver response from optional or merely used extensions.
- Record exact scope, status, extensions, fallback behavior, and intended purpose.