The best exchange mechanism depends on what the receiving team must do and who must remain the source of truth. A reference can preserve an update relationship while depending on external resolution. A package can gather dependencies without preserving native semantics. A neutral file can cross ecosystems while changing the authoring representation. None is universally best.
Start with the collaboration question
Answer these questions before comparing formats:
- Is the recipient viewing, coordinating, editing, manufacturing, approving, or preserving the data?
- Is the source owner still authoritative after delivery?
- Must changes flow automatically, be reissued deliberately, or return to the source?
- Which information layers may be approximated or rebuilt?
- Can the recipient resolve the required files, assets, references, versions, and credentials?
- What evidence will make the delivery acceptable?
Compare mechanisms by behavior
| Route | Authority and update behavior | Dependency implication | Typical fit | Main risk to test |
|---|---|---|---|---|
| Direct/native | Often closest to a product’s native representation; update behavior is product-specific. | May depend on the source product, release, options, or linked files. | Continued work when the direct route is documented and the receiver needs native behavior. | A support entry may not establish preserved features, structure, or editability. |
| Neutral file | Creates a representation intended to cross ecosystems; source-native history may not travel. | Dependencies are representation- and route-specific. | One-way delivery where selected geometry, structure, PMI, or other layers need a shared exchange contract. | The protocol scope can be mistaken for exporter/importer coverage or receiver acceptance. |
| Reference/link | Source remains authoritative while the destination consumes a linked representation. | The receiver needs the referenced file, paths, resolver, permissions, and compatible versions. | Evolving designs, coordination, or controlled downstream views. | Missing or changed dependencies break the update path; reference does not equal local editability. |
| Controlled package | Delivers a selected set of files and assets together. | Packaging can improve transport completeness but must still be checked for closure and path resolution. | Supplier delivery, review, or a handoff with fonts, xrefs, textures, or other external assets. | A complete package can still contain lossy or unusable representations. |
| Managed cloud subset or published package | Gives a recipient a selected, permissioned project state or published version. | Depends on the service, project/folder access, selected versions, and update or consumption rules. | Shared project work or delivery of a bounded set of models and documents. | A visible subset is not a complete project, immutable archive, or proof that the recipient can perform the task. |
| Live review or authoring session | Shares a view, annotation, proposal, or session edit while participants interact. | Depends on membership, client/version eligibility, participant rights, and the owner who saves or merges. | Time-bounded coordination when the task benefits from interactive review or coauthoring. | Session participation may create no transferred file or durable accepted result. |
| Issue/viewpoint context | Carries an issue, references, comments, and selected model view. | The recipient needs compatible issue/model versions, references, and project permissions. | Persistent review discussion around a separately delivered model. | The issue is not the model, and its attachment/view context may follow a different version rule. |
The table describes route behavior, not a ranking. Choose based on the required continuity and acceptance boundary.
Follow the recipient operation to the focused guide: use managed sharing for project state, access, packages, and sync; live-session authority for viewing, proposing, editing, and saving; and BCF issues for durable issue context. Named workflows then narrow the route: CoDesigner or IDX for ECAD–MCAD changes, Inventor to Revit for a building component, Datasmith for a visual scene, or 3MF to a slicer when the recipient must resolve model and print-setting state.
Reference versus conversion: a concrete example
Inventor’s AnyCAD guidance separates two modes. Reference Model maintains a link to the selected source file so changes can be monitored and updated; Autodesk positions it for an evolving design that does not need to be edited in Inventor. Convert Model creates a new Inventor file that is not linked to the original and is intended for modification in a new design.
Those choices answer different ownership questions. A reference is not a backup and does not make the source file portable by itself. A conversion is not a live update path. If an AnyCAD reference is missing, Inventor opens a resolve-link workflow; skipping resolution leaves the dependency question open.
Record the authority, link target, path policy, update trigger, conflict handling, and destination operation. Do not infer a universal update policy from one product’s reference feature.
Compare concrete update models without universalizing them
Product-specific collaboration features are useful examples because they make authority and update state visible. SOLIDWORKS 3D Interconnect documents a third-party-CAD insertion that can retain an associative link and update downstream SOLIDWORKS features; breaking the link changes the later update relationship. Its selected receiver-side mappings—material name and density, some custom properties, and unconsumed sketches or curves—do not amount to complete source-history or field preservation.
Onshape exposes two different boundaries. Imported CAD has no source feature
tree; a changed imported part can be re-exported and used to update the Import
feature, but the documented workflow updates only the Part Studio, not the
Assembly. A linked Onshape document instead references an immutable version:
newer versions do not silently propagate, Update all can recurse through
eligible subassemblies, pinned references are excluded, and write permission
is required for updates. These are concrete product behaviors, not a general
rule for every reference or file-based CAD workflow.
What a neutral file can and cannot solve
ISO 10303-242:2025 has a broad scope covering managed engineering data, geometry, assemblies, PMI, configuration and change information, quality and inspection, and long-term retrieval. That scope makes it a candidate for a neutral exchange requirement. It does not establish that a selected exporter emits each scope item or that a receiver preserves and exposes it.
For a neutral route, specify the protocol/profile/edition, source and destination releases, settings, required layers, and acceptance comparison. If a receiving team needs native feature-history editing, demand a test for the named editing operations or change the requirement to a supported downstream outcome.
What packaging can and cannot solve
Autodesk documents AutoCAD ETRANSMIT as packaging selected drawing files for transmission and automatically including related dependent files such as external references and font files. That is concrete evidence for a dependency-packaging step. The documentation does not establish an exhaustive dependency inventory, complete path resolution, or semantic preservation of every object and annotation.
The same distinction appears in OpenUSD. usdzip can create and inspect USDZ packages from USD assets and referenced assets, and usdchecker provides a separate validation operation. A usdzip --asset input must be a resolvable root-layer asset path, and package compliance checks are not a guarantee that every dynamically resolved dependency is discoverable or that a receiver will render the intended result.
For USDZ specifically, the package has a Default Layer and package-relative
resolution rules, is read-only in place, and may still consult an external
resolver after package-local resolution fails. Anchored ./ or ../ paths are
recommended for more uniform consumption, while usdzip can recursively
localize referenced files. Package creation and compliance checking still do
not prove receiver-side visual acceptance or complete closure for custom
resolver behavior.
Packaging solves a transport question: what selected files and assets travel together? It does not automatically solve a representation question: what information survives inside those files?
Choose among references, packages, and flattening deliberately
OpenUSD references compose a source layer into a target stage and allow non-destructive overrides. The referenced identifier may be resolved by a path-resolver or file-format plugin and need not be a local file path. This supports collaborative composition, but the resolver context and referenced layers become part of the route.
OpenUSD flattening is different from packaging. UsdStage::Flatten creates a single merged layer with resolved values authored directly into it. It removes most composition metadata; only currently selected variants remain, inherited data is copied to child objects, and deactivated prims are pruned. A flattened result can be easier to deliver as one layer while losing update and composition behavior.
Make the choice explicit:
| Need | Prefer investigating | Confirm before acceptance |
|---|---|---|
| Live or repeatable source updates | Reference/link route | Resolver/path access, update behavior, conflict rules, and receiver support. |
| A self-contained selected delivery | Controlled package or a deliberate flatten | Dependency closure, selected variants, package checks, and the required receiver task. |
| Cross-ecosystem design exchange | Neutral file | Profile/edition, field mapping, source/destination settings, and task-specific comparison. |
| Native downstream editing | Direct/native or another route with an explicit edit test | Named operations, rebuild behavior, feature/parameter availability, and release constraints. |
Treat returned files honestly
A file returned by a collaborator may be:
- a new authoritative source;
- a derived neutral deliverable;
- a reference or update to the original source; or
- a visual, review, or manufacturing representation that is not intended to return to the authoring system.
Name that status in the exchange record. Do not call a lossy derived file a round trip merely because it can be imported again. A round trip requires a defined return path and a comparison against the information and operation that must remain continuous.
Write the handoff acceptance record
Record the selected mechanism, source of truth, versions, profile, dependencies, required layers, permitted loss, update expectation, and recipient task. Then test the result in the receiving environment:
- resolve or enumerate dependencies;
- inspect the representation and required information layers;
- perform the named downstream operation;
- record repairs, omissions, unresolved references, and untested areas; and
- decide whether the result is accepted, accepted with restrictions, or needs another route.
If no mechanism provides sufficient evidence for the task, state that no reliable route has yet been established. A narrower deliverable or separate representations may be more honest than forcing one file to serve incompatible purposes.
Key points
- Choose by authority, update behavior, dependencies, required layers, and task—not by extension alone.
- References, neutral files, packages, and flattened results solve different problems.
- A package can improve dependency delivery without proving semantic preservation.
- A return file is not a round trip unless the return path and required continuity are tested.