Choose the Right Handoff Expectation: Delivery, Continued Work, Reference, Update, or Round Trip

The recipient’s ability to open a result does not tell you how the result is expected to behave afterward. A one-way deliverable, a linked reference, and a round trip have different requirements for identity, dependencies, editability, change detection, and acceptance.

Choose the continuity model before you select a route.

Five models, five questions

These models can be combined. A team might deliver a neutral shape once, keep a separate reference for coordination, and retain the source as the editing authority. State which expectation applies to each artifact.

One-way delivery is still a requirement

One-way does not mean “anything that opens is fine.” It means the receiving task is bounded and the permitted loss is explicit. For example, a supplier may need a shape with units and tolerances plus a drawing, while a visualization team may need a mesh and material assets but no editable feature history.

Write down:

• the accepted representation and accuracy or completeness threshold;
• the layers the recipient must use;
• the layers that may be flattened, omitted, or rebuilt;
• all dependencies included in the package; and
• the comparison or review that closes acceptance.

Autodesk describes AutoCAD IMPORT as translating incoming data into the current drawing’s DWG data. That tells you what the operation does at a high level; it does not decide whether the translated result is adequate for your particular delivery.

Release conversion adds another boundary. Autodesk’s AutoCAD documentation gives format-specific examples in which saving to an earlier format can strip current-release information or convert objects, and notes that some newer drawing views may not be editable in an older release even when the file format is shared. The target release and the information that may change therefore belong in the delivery requirement; do not generalize one release’s limitation to every CAD format.

Autodesk’s Fusion DWG guidance is another bounded delivery example. It says that the documented cloud-translation path produces 2D sketches from 2D sketch geometry and bodies and solid features without sketches from 3D solid bodies, while some DWG data cannot be read. If the receiving task depends on the missing or alternate representation, “DWG is supported” is not an adequate delivery requirement.

Continued work needs named operations

“Editable” is too broad to test. Name the operations that matter: changing a dimension, moving a component, suppressing a feature, updating a reference, revising a drawing view, or rebuilding a defined feature set. Also state what is acceptable when the destination cannot reproduce the source history: direct editing, a converted solid, a reference-only result, or manual reconstruction.

The available research for this category does not establish a general CAD route that preserves arbitrary design intent or continued editing. Treat such a result as route-specific and test it with representative models and operations.

Reference and update are dependency questions

A reference-based result may depend on a path, identifier, resolver, linked file, or source application. The dependency is part of the handoff, not an implementation detail to discover after delivery.

OpenUSD provides a useful bounded example from a scene-description system: a stage can reference another layer, use a path resolver, compose the referenced content, and apply non-destructive overrides. That example demonstrates why a reference package must describe target resolution, composition, overrides, and external dependencies. It is not evidence that a CAD application behaves the same way.

Autodesk’s Inventor 2026 documentation distinguishes an AnyCAD Reference Model from a Convert Model. The documented reference workflow maintains a link to the selected source for monitoring and updates, while the convert workflow creates unlinked Inventor files for a new design. The same page qualifies STEP reference updates as new translations that may produce unresolved geometry or prevent Inventor-side changes from updating properly. These are product- and workflow-specific statements, not a universal rule for linked CAD data.

Autodesk’s Fusion AnyCAD guidance describes a similar but separately scoped linked-source workflow: the native file remains edited in its authoring CAD application, and the linked Fusion design is refreshed to obtain the latest source version. A refresh relationship answers how an update is requested; it does not establish feature-history transfer or acceptance of the refreshed result.

Creo Parametric r12’s ATB documentation adds explicit dependency controls for its own route: an ATB-enabled import can be checked for status, updated, relinked when a reference is missing, or deliberately detached. The documentation also makes geometric-ID retention conditional on the native source. These controls help define the reference/update contract, but they do not prove that semantic or parametric information survives.

A separate Inventor 2026 FAQ illustrates a release boundary rather than a general continuity rule. It says a prior sequential release can see changes in a newer-release reference model after a rebuild, but cannot edit newer-release features or save the file as a previous native version. Treat that as a narrowly scoped reference/update example and test the exact release pair and model state.

For any reference or update route, record:

1. which file or service remains authoritative;
2. how the destination resolves the dependency;
3. what happens when the source changes, moves, or becomes unavailable;
4. which identities, configurations, and external files must remain stable; and
5. how each update is checked before downstream use.

Round trips need comparison, not optimism

Repeated translation can change a representation even when each individual step completes. Autodesk’s AutoCAD 2022 IGES documentation gives a bounded example: a 2D polyline can map to an IGES entity on export and to a spline on import, so the drawing may not be identical. It warns that repeated translation in and out of IGES can make data loss a concern and recommends consulting both translators’ conversion tables.

The example does not supply a general loss rate or a result for another product pair. Use it as a reason to define a round-trip test:

• choose a representative model and the exact route, release, options, and direction;
• compare the layers that matter, not only whether the file opens;
• identify substitutions, missing entities, changed identity, or altered references;
• repeat the exchange only when repeated translation is part of the real workflow; and
• obtain an acceptance decision from the team that owns the downstream task.

Choose the expectation in the brief

If the handoff model is unclear, write the uncertainty explicitly:

Expected continuity: [one-way delivery / continued work / reference / update / round trip]
Authority after transfer: [source / destination / shared or unresolved]
Required operations: [view, edit, update, compare, manufacture, inspect, ...]
Dependencies: [linked files, identifiers, resolver, assets, release context]
Permitted changes: [flattening, substitutions, approximation, manual rebuild]
Acceptance: [comparison, test case, review, and accountable decision owner]

Use Build a Preservation Map for Design Data to fill in the required layers, then Write an Interoperability Brief That Leads to Testable Acceptance to make the expectation actionable.

Key points

• “Opens” does not specify delivery, editing, reference, update, or round-trip behavior.
• Continued work requires named operations and rebuild expectations.
• Reference and update workflows include dependencies, resolution, identity, and change behavior.
• Round trips need layer-specific comparisons and accepted thresholds.
• Product examples are useful only within their documented release, route, and scope.