Identity, Instances, and Configurations in a Design Handoff

Two occurrences can look identical and still mean different things. One may be the first use of a released component; another may be a second use of the same definition, a different configuration, or a replacement awaiting approval. If that context is reduced to unnamed geometry, a recipient may be unable to update, replace, audit, or retrieve the intended design.

Identity is not one field. Treat it as a set of questions about definitions, occurrences, variants, change context, and the relationships between them.

Separate the identities in play

Use the following vocabulary as a checklist, not as a universal schema:

• Definition: the reusable part, component, product, or other object being referenced.
• Occurrence or instance: a use of that definition in a particular assembly or context. It may have its own placement, quantity, or occurrence label.
• Configuration or variant: a selected state of a part, assembly, or occurrence. The selection may affect geometry, properties, included instances, mates, or other system-specific behavior.
• Identifier: a value used to distinguish an object or refer to it in a local system, such as a part number, document ID, GUID, namespace path, or source-local key.
• Revision or version: a change or release context. A revision label is meaningful only with its governing system and rules.
• Effectivity or applicability: the products, dates, serial ranges, options, or other conditions for which a definition or change applies, where the source system supports them.

Do not collapse these into a filename. A filename can be useful for a person while being insufficient for a controlled replacement or an archive retrieval test.

Reuse is different from copied geometry

If a source assembly uses one component five times, the receiver may need to know whether those are five occurrences of one definition or five independent copies. The visual result can be identical in both cases. The operational result is not:

• replacing one shared definition may be expected to update all occurrences;
• replacing one occurrence may be expected to affect only that occurrence;
• quantities and child relationships may be used for a bill-of-material or supplier check; and
• archive retrieval may need to identify the exact definition and its change context.

The requirement should state which behavior matters. “Preserve instances” is too vague unless it says whether shared definition identity, occurrence labels, placement, quantity, and replacement behavior are required.

Bounded product and schema examples

Onshape’s Assembly documentation describes part and subassembly instances, while its Instances list can display an instance number and properties such as part number, revision, and state. Onshape also documents a Reference manager workflow for changing a linked instance to a different document version. These are product-specific mechanisms: seeing a revision or update indicator in Onshape does not show that an exported package carries the same versioned link into another CAD system.

Onshape also treats configuration as more than a suffix on a file name. Its documentation says configurations can create variations of a part, Part Studio, or Assembly. In an Assembly, mates, instances, and patterns can be configured; after insertion, a configured part or assembly can be changed from the Instances list, and the active selection can be inspected. That establishes configuration behavior inside Onshape, not configuration transfer or parametric-history equivalence.

Release state adds another boundary in Onshape. Its documentation treats each configuration as a unique revisionable object, but only configurations explicitly included in a release are available for reuse from that released version. When an Assembly contains configured parts, releasing the Assembly includes the specific configurations it references; additional configurations must be added explicitly. Record the release and selected configurations as part of the handoff baseline rather than assuming that an export carries them.

Autodesk Inventor separates several kinds of state that can look similar in a tree. iPart and iAssembly members have their own properties and part numbers and are stored in separate files. Model States keep variations in one file and can change BOM participation through suppression. View representations control display, while Positional representations control assembly position and state. Those are Inventor-specific semantics: a visible representation or a member name is not a portable configuration or revision scheme.

Creo Parametric provides a different product-specific boundary. A family-table generic is the template for its instances, and a particular instance can have components or features that are suppressed for the generic and other instances. Replacing a family-table component requires editing the Family Table under the documented rules. The instance behavior is useful to test in a Creo handoff, but it must not be mapped automatically to an Onshape configuration or an Inventor Model State.

The JT v10 format reference supplies a format-level example rather than a product lifecycle model: an instance node may share a Part Node with another instance. That describes a possible representation of reuse, not a universal mapping to a CAD part number, revision, or occurrence identity.

IFC provides a different, schema-level example. IfcRoot defines a GlobalId for a globally unique identifier and makes OwnerHistory optional in IFC4. The documentation describes ownership, owning application, and recent change information, while noting that only the last modification is stored in that history field. This is not a universal CAD revision model, and the cited IFC 4.3.2 documentation is marked under development. Verify the exact IFC release, view, implementation agreement, and receiver behavior before treating these fields as an exchange commitment.

OpenUSD deliberately illustrates why identifiers cannot be equated across systems. USD uses textual hierarchical namespace paths rather than GUIDs for binding overrides. If a namespace changes, higher-level overrides may need to be fixed up. A USD namespace path is meaningful in the USD composition model; it is not evidence of equivalence to a CAD part number, enterprise ID, or revision code.

Specify the context needed for the handoff

Write an identity and configuration section in the exchange requirement:

Requirement area	Questions for the sender and receiver
Definition identity	Which reusable parts, subassemblies, or other definitions must be distinguishable?
Occurrence identity	Must each use retain an occurrence number, label, placement, quantity, or relationship to its definition?
Configuration	Which configuration or variant is selected, and which inputs or options determine it?
Change context	Is the handoff a released snapshot, a working version, a revision, or an update to an existing object?
Replacement	Should a later replacement affect every occurrence or only a named use?
Effectivity	Are date, serial, option, customer, or product applicability conditions in scope?
Traceability	Which source-local identifiers must be recorded so the receiver can identify the source object?
Verification	What observation proves that the receiver selected the intended object and state?

If the destination cannot represent the required identity or configuration, decide that before transfer. Possible outcomes include a bounded snapshot with a companion manifest, a receiver-native reconstruction, or a different route. Do not describe a renamed or copied shape as retaining update semantics it cannot express.

Test identity with a change scenario

An effective test uses an operation the recipient actually needs:

1. Record the expected root, definition identifiers, occurrence count, quantities, selected configuration, and version or revision context.
2. Transfer the package and inspect the destination’s structure and identity fields.
3. Select two repeated occurrences and confirm whether the intended shared or independent relationship remains.
4. Select the intended configuration or variant and record the visible state and any supported properties.
5. Perform a controlled replacement or update test if the handoff is meant to support one. Confirm the scope of the change rather than relying on a timestamp or display name.
6. Record any remapped, omitted, or destination-generated identifiers.

For a product-specific handoff, also record the source-side state that selected the object: for example, the explicitly released Onshape configurations, the Inventor member or representation and its suppression/exclusion choices, or the Creo generic and selected family instance. These observations establish what was sent; they do not establish what the receiver preserved.

For an archive or supplier snapshot, the test may instead be retrieval and identification: can another person determine exactly which definition, occurrence context, and configuration was delivered without reopening the source system?

LOTAR TS-9300-200-1 offers a bounded validation example in which selected critical attributes identify a node and an assembly’s validation property incorporates direct-child identifiers, revisions, and quantities. That method can inform a local consistency check, but the critical attributes and normalization rules must be chosen for the local purpose. A matching consistency signature does not prove semantic equivalence, geometry fidelity, or editability.

What identity does not establish

Even strong identity evidence leaves separate questions:

• A stable identifier does not prove that the geometry is accurate.
• A preserved occurrence does not prove that the source’s feature history or parameters are editable in the receiver.
• A configuration label does not prove that all of its inputs, suppression logic, or variant behavior transferred.
• A revision field does not prove that the receiver has the same change history or effectivity rules.
• A matching namespace or part number does not prove that two objects are semantically equivalent.
• A sender-side release, member, or instance selection does not prove that the same configuration context survived export.

Keep these conclusions separate in the handoff record. Identity is valuable because it makes the received structure distinguishable and testable; it is not a shortcut for every other data layer.

Key points

• Define definition identity, occurrence identity, configuration, and change context separately.
• Repeated visible shapes do not tell you whether the receiver retained shared reuse or independent copies.
• Product and schema examples document their own identity mechanisms; they do not prove cross-system mappings.
• Test the identity behavior through the operation the recipient needs: replacement, update, variant selection, supplier identification, or archive retrieval.
• Treat identifiers, geometry, editability, semantics, and acceptance as separate claims.