Incorporate PLM feedback and sharpen likely direction

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: asluk

proposals/identifier_separation_of_concerns/README.md

@@ -394,24 +394,48 @@ for round-trip fidelity.
 
 PLM systems assign stable identifiers -- part numbers, revision codes,
 serial numbers -- that must persist across the lifecycle of a physical
-product and its digital twin.
-
-- A **part number** like `A-0000-12345-Rev.C` identifies the *design* of a
-  component. Multiple instances of that component in an assembly share this
-  identifier.
+product and its digital twin. These identifiers are often composite, with
+distinct fields serving different roles:
+
+- A **part number** like `A-0000-12345` identifies the *design* of a
+  component as a generic reference. Multiple instances of that component
+  in an assembly share this identifier, and searching for a part number
+  may return multiple revisions.
+- A **revision** identifies a specific version of that design. Revisions
+  may take the form of a human-readable suffix (e.g., `Rev.C`) or an
+  opaque system handle (e.g., Windchill's `OR:wt.part.WTPart:4697800`,
+  which resolves to a specific revision internally).
 - A **serial number** like `SN-2025-00847` identifies a specific *physical
   instance* of that component.
 - A **BOM (Bill of Materials)** is generated by traversing an assembly and
   collecting part numbers -- a workflow that requires source identifiers to be
   discoverable and unambiguous.
+- **Alternative and equivalent identifiers** are common: OEM part numbers,
+  replacement part numbers, and service part numbers may all refer to the
+  same form/fit/function item under different schemes. A single component
+  may legitimately carry multiple identifiers that coexist without conflict.
 
 In complex configuration-managed systems, the identifier may not be a
-human-readable part number at all. PLM systems may use composite URIs or
-opaque system keys -- meaningful only to the originating system's asset
-resolver -- where a "part" is an abstract container whose concrete identity
-depends on configuration rules and context. These opaque, vendor-specific
-identifiers must survive a round-trip through USD without loss, just as
-human-readable strings do.
+human-readable part number at all. PLM systems may use opaque system
+handles -- meaningful only to the originating system's resolver -- where a
+"part" is an abstract container whose concrete identity depends on
+configuration rules and context. These opaque, vendor-specific identifiers
+must survive a round-trip through USD without loss, just as human-readable
+strings do.
+
+#### Configurable products and composite keys
+
+PLM systems also manage **configurable products** whose structure depends
+on context. A product's Bill of Materials may change dramatically based on
+**navigation criteria** -- the rules used to traverse and resolve the
+sub-structure for a specific configuration. Navigation criteria may
+themselves be opaque objects (e.g., Windchill's
+`OR:wt.filter.NavigationCriteria:7608531`) or encoded strings (URLs,
+JSON). The result is that a single primary identifier may not suffice to
+identify the specific item referenced in USD; the combination of part
+identifier and navigation criteria (or other context keys) forms a
+composite key. This reinforces the need for source identifier metadata
+that can carry multiple fields per system, not just a single value.
 
 If these identifiers are encoded into prim names, characters like hyphens and
 periods are lost or transcoded, making BOM generation from the USD stage
@@ -633,6 +657,26 @@ of fragmented workarounds.
    external identifiers are needed on prims at all levels of the hierarchy
    and the mechanism must not be artificially limited to model roots.
 
+   In manufacturing, an asset
+   may collapse internal product structure for visualization, but
+   individual meshes within the asset still need to trace back to the
+   source parts they represent -- identifiers that differ from the model
+   root's own identifier. An assembly (e.g., a rack) may contain
+   components (e.g., trays) whose visual prims carry their own source
+   identifiers even though they are not model roots.
+
+   However, broadening scope introduces a **discoverability cost**. Today,
+   the model hierarchy (via `Usd.PrimIsModel` and `Kind`) provides a cheap
+   way to find "things that have identity" -- you walk the model hierarchy
+   and stop. If any prim in a stage can carry source identifiers, "find me
+   all prims with identifiers" becomes a full stage traversal, which on
+   large scenes (millions of prims) is a meaningful performance difference.
+   The design should consider whether the model hierarchy remains the
+   primary discovery path (with sub-model identifiers accessed only when
+   drilling into a known subtree), or whether an additional indexing
+   mechanism is needed (e.g., a collection or relationship at the model
+   root that enumerates identified sub-prims).
+
 5. **Namespacing of identifiers.**
    If a prim carries identifiers from multiple external systems, how should
    they be organized? The namespacing convention must accommodate the full
@@ -644,10 +688,26 @@ of fragmented workarounds.
    `sourceId:ifc`) or a family of single-apply schemas that include a
    common base.
 
+   An alternative model is to encode vendor identity *inside* the
+   identifier value itself (e.g., `"com.ptc.windchill:part:xyz"`) rather
+   than in the key or namespace. This is attractive for its simplicity --
+   a single "primary identifier" field can carry multi-system values if
+   it accepts an array -- and it enables non-destructive composition
+   (adding an identifier does not remove an existing one). However, it
+   trades schema enforceability for encoding flexibility: tooling must
+   parse a string convention rather than inspect typed schema fields, and
+   fallback values, GUI discoverability, and schema-driven validation
+   become unavailable for the structured portions of the identifier. The
+   tension between these approaches is a key design decision for the
+   solution proposal.
+
 6. **Relationship to `displayName`.**
-   How does the source identifier relate to the prim's `displayName`? In some
-   workflows the display name *is* the source identifier; in others they
-   differ. When multiple instances share a source identifier, deriving
+   `displayName` is a UX convenience; the source identifier is the
+   authoritative link to the originating system. While a display name
+   *may* be derived from information in the source record, it has no
+   semantic relationship to the identifier itself -- the identifier is the
+   source of truth, and `displayName` should have no influence on it.
+   When multiple instances share a source identifier, deriving
    `displayName` from it may be confusing for presentation (e.g., 30 doors
    all displaying the same catalog number). `displayName` substitution
    patterns -- as used for symmetry in rigging and for multiple instances of
@@ -670,21 +730,36 @@ of fragmented workarounds.
 
 ### Likely direction
 
-TAC discussion has identified two candidate approaches, each with distinct
-trade-offs. The next phase of this work will evaluate both before committing
-to one.
+#### Emerging consensus
+
+Discussion and review feedback have converged on several points:
+
+- **Multi-field, not single-value.** Source identifiers are metadata
+  packages, not atomic strings. Part numbers, revisions, serial numbers,
+  and navigation criteria serve different roles and must be separable.
+  Every domain that has contributed feedback confirms this.
+- **Multiple systems per prim.** A single prim may carry identifiers from
+  more than one external system (e.g., Windchill and SAP). The mechanism
+  must support this without collision.
+- **Any prim, with cost-aware discovery.** Identifiers are needed below
+  model roots, but discovery must not require full stage traversal on
+  large scenes (see [open question 4](#open-questions-for-discussion)).
+
+#### Remaining design choice: mechanism
+
+TAC discussion has identified two candidate approaches. The next phase
+will evaluate both before committing to one.
 
 **Approach A: Extend `assetInfo` with stratified sub-dictionaries.**
 Domains register source identifiers as sub-dictionaries within `assetInfo`,
 with applied API schemas providing convenience access (following the
 `UsdMediaAssetPreviewsAPI` precedent).
 
 **Approach B: Applied schema (likely multi-apply) with typed properties.**
-Applied schemas are a well-established USD mechanism; the question is
-whether to direct them at the cross-domain identifier problem as a
-standards framework. Source identifiers would be expressed as properties on
-an applied API schema, with each external system represented as a schema
-instance.
+Source identifiers are expressed as properties on an applied API schema,
+with each external system represented as a schema instance (e.g.,
+`sourceId:windchill`, `sourceId:ifc`). Each instance carries typed fields
+(part number, revision, etc.) with fallback values.
 
 | | Approach A (`assetInfo` dictionary) | Approach B (applied schema) |
 |---|---|---|
@@ -697,10 +772,18 @@ schemas that include the base and add their own extensions. This encodes
 systems in concrete schemas rather than multi-apply instance names, but
 requires `UsdSchemaRegistry` query enhancements.
 
+A third option -- encoding vendor and structure inside a single string or
+array field (e.g., `identifier=["windchill:x","sap:y"]`) -- has been
+raised. This trades schema structure for simplicity and is attractive for
+ad-hoc adoption, but collapses the per-system typed fields that both
+approaches above preserve. It may be useful as a lightweight fallback but
+is unlikely to serve as the primary mechanism given the multi-field
+consensus.
+
 The remaining open questions above are intended to resolve which approach
-best serves the community, including scope (any prim vs. model roots),
-namespacing conventions, and how adjacent use cases (including authorship
-traceability) should be accommodated.
+best serves the community, including namespacing conventions and how
+adjacent use cases (including authorship traceability) should be
+accommodated.
 
 ### Risks
 
@@ -912,49 +995,35 @@ The following materials were provided as input context for drafting:
 The draft was refined through multiple rounds of internal review. Key
 editorial decisions included:
 
-- Explicitly naming the two distinct problems (unencumbered source identifier
-  field vs. improved prim name ergonomics) based on reviewer feedback, and
-  positioning this proposal as addressing the first without foreclosing the
-  second.
-- Compressing and reframing the GUIDs discussion to serve the proposal's
-  argument (GUIDs-as-primary-identifiers pressure is a symptom of the missing
-  separation of concerns) rather than reading as a defensive digression.
-- Augmenting `assetInfo` analysis with `UsdModelAPI` and
-  `UsdMediaAssetPreviewsAPI` as potential prototypes for a source identifier
-  mechanism.
-- Correcting the IFC GlobalId characterization (GlobalIds are per-instance, not
-  per-type) based on fact-checking against the IFC specification.
-- Adding external queryability as a design principle and cross-system
-  resolution as an open question, based on reviewer feedback that the
-  practical utility of source identifiers depends on the ability to resolve
-  them from outside USD -- with the consumer responsible for building indexes
-  on top of the mechanism.
-- Incorporating TAC feedback: adding authorship traceability as a related
-  use case, updating next steps to reflect consensus trajectory, and adding
-  PR submission as the first next step.
-- Incorporating TAC feedback on applied schema limitations: tempering the
-  `UsdMediaAssetPreviewsAPI` pattern's characterization, presenting the case
-  for true applied schemas (multi-apply or single-apply with base) as an
-  alternative to the `assetInfo` dictionary approach, and restructuring the
-  "Likely direction" section to compare both approaches with their trade-offs.
-- Adding vendor extensibility as a design principle, referencing cross-industry
-  precedent (Khronos, IETF, W3C) for vendor-first deployment with a path to
-  standardization.
-- Adding Khronos glTF and the W3C web platform as co-equal vendor extension
-  precedents alongside Khronos graphics APIs and IETF: glTF as a 3D data
-  interchange format whose extension model governs properties on objects;
-  the W3C model for its consensus-driven staged maturity path (Community
-  Group → Working Group → Recommendation) and its freeform/governed
-  distinction (`data-*` attributes vs. standard attributes). Explicitly
-  deferring vendor extension governance details (prefix conventions,
-  registration process, promotion criteria) to the follow-up solution
-  proposal.
-- Clarifying that a "vendor extension" is a specification-level concept (a
-  schema, identifier scheme, or set of conventions) distinct from an OpenUSD
-  plugin, which is a runtime implementation detail. This distinction follows
-  the precedent set by the AOUSD Core Specification 1.0, which specifies
-  schemas without prescribing a plugin or schema registry. Expanded the
-  solution proposal next step to include the vendor extensibility model
-  (prefix conventions, naming rules, registration, promotion criteria).
+- **Two-problem framing** -- named source-identifier and prim-name-ergonomics
+  as distinct problems; positioned this proposal on the first without
+  foreclosing the second.
+- **GUIDs discussion** -- reframed as a symptom of missing separation of
+  concerns, not a defensive digression.
+- **`assetInfo` analysis** -- added `UsdModelAPI` and
+  `UsdMediaAssetPreviewsAPI` as prototype precedents.
+- **IFC GlobalId correction** -- GlobalIds are per-instance, not per-type.
+- **External queryability** -- added as a design principle and open question:
+  - Consumer-side indexing; mechanism must make this tractable.
+- **TAC feedback (authorship, next steps)** -- authorship traceability as a
+  related use case; consensus-driven next steps; PR submission step.
+- **TAC feedback (applied schemas)** -- tempered `UsdMediaAssetPreviewsAPI`
+  characterization; restructured "Likely direction" to compare dictionary
+  vs. applied-schema approaches with trade-offs.
+- **Vendor extensibility** -- added as a design principle:
+  - Cross-industry precedent: Khronos (glTF, OpenGL/Vulkan), W3C, IETF.
+  - glTF `extensions`/`extras` parallels schema vs. `customData`.
+  - W3C staged maturity path; `data-*` vs. governed attributes.
+  - Governance details deferred to solution proposal.
+- **Vendor extension vs. plugin** -- clarified as specification-level vs.
+  runtime distinction, citing AOUSD Core Spec 1.0 precedent.
+- **PLM feedback (Steve Ghee, PTC)** -- expanded manufacturing section:
+  - Part number separated from revision; opaque handles; alternative
+    identifiers (OEM, replacement, service).
+  - New subsection: configurable products and composite keys.
+  - Scope open question: sub-model-root use cases + discoverability cost.
+  - Namespacing open question: vendor-in-value vs. key-level namespacing;
+    tension with schema enforceability.
+  - `displayName` open question: asserted independence from identifiers.
 
 A prompt-level drafting log has been archived separately.