Turn a vague “send the model” request into a bounded source-to-destination handoff with a stated purpose, preservation requirements, and evidence needs.

Define a CAD Data Handoff Before You Export

An export request becomes useful only when the receiving job is explicit. “Export it as STEP” may identify a representation, but it does not say whether the recipient needs a watertight shape, an editable design, assembly identity, PMI, a manufacturing result, or simply a visual reference.

The AP242 interoperability project presents use cases and business requirements as context for implementation practice. ISO 10303-1:2024 likewise describes a product-data exchange architecture that includes application protocols, implementation methods, usage guides, and conformance-testing concepts. A filename is only one part of that larger question.

Start with the job, not the extension

Write the handoff as a chain:

source environment
→ transfer mechanism or representation
→ destination environment
→ required information layers
→ downstream objective
→ validation evidence

For each link, answer the following:

Field	Question to answer
Source	Which application, product, release, model state, and configuration produces the data?
Mechanism	Is this a native file, neutral format, direct link, reference, translation, package, or another route?
Destination	Which application, product, release, and receiving workflow will consume it?
Direction	Is the exchange one-way, source-to-destination update, destination-to-source, or repeated in both directions?
Objective	What must the recipient do: view, coordinate, edit, manufacture, inspect, render, archive, or something else?
Required layers	Which information must remain usable for that objective?
Acceptance	What comparison, check, or human decision will show that the result is fit for the job?

The objective determines the evidence you need. A file that displays the right silhouette may be adequate for a visual review and inadequate for editing or inspection.

Name what may and may not be lost

Treat “the model” as a bundle of information, not one preservation property. Depending on the job, you may need:

exact geometry, topology, tolerances, or a usable mesh;
assembly structure, component identity, configurations, and external references;
features, parameters, constraints, and other design-intent information;
dimensions, annotations, PMI, drawings, materials, classifications, and metadata;
units, coordinate systems, transforms, and spatial or BIM context;
materials, textures, cameras, lighting, scene composition, and asset dependencies; or
tool paths, manufacturing attributes, inspection plans, measurements, and quality results.

Mark each layer as required, useful, acceptable to flatten or omit, or not applicable. “Not mentioned” is not the same as “safe to discard.” If the receiving task is unknown, keep the requirement open rather than letting the transfer route decide it for you.

Capture constraints around the data

The same nominal route can behave differently when its context changes. Record constraints that can alter the result:

source and destination release, schema, profile, extension, or translator version;
units, axes, coordinate systems, tolerances, and model location;
assembly dependencies, linked files, textures, fonts, external references, or other required assets;
whether the recipient receives a self-contained copy or must resolve a live reference;
whether the file will be edited, updated, re-exported, or compared later;
security, access, packaging, and delivery restrictions; and
the date or release window by which the exchange must work.

These are requirements to investigate, not evidence that a route succeeds. A handoff brief should ask the route owner to confirm each one for the exact source and destination context.

Replace compatibility language with a testable question

Weak question:

Does the destination support this format?

Stronger question:

Can the destination release import this source release in the stated direction, preserve assembly identity and the required annotations, and support the recipient’s specified edit or review operation? What test or comparison demonstrates each result, and which conditions remain unknown?

The stronger version makes “support” answerable. It also prevents a standard description, a vendor support table, or a successful import from being mistaken for proof of downstream usefulness.

A compact handoff statement

Use this as a starting point for an exchange request:

Source: [product, release, model state, configuration]
Destination: [product, release, receiving workflow]
Route under consideration: [native / neutral / reference / translation / package]
Direction: [one-way / update / return / repeated exchange]
Objective: [specific operation and decision the result must support]
Required layers: [list the information that must remain usable]
Permitted loss: [what may be flattened, omitted, or rebuilt]
Dependencies and constraints: [linked files, units, coordinates, versions, access]
Evidence requested: [documentation, scoped test, comparison, or review]
Acceptance owner: [person or team who decides the result is usable]

The statement does not select a format for you. It creates a bounded question that route research can answer. Use CAD Interoperability Claims: Support, Conformance, Preservation, and Fitness for Purpose to assess the answer, then build a layer-by-layer requirement with Build a Preservation Map for Design Data.

Key points

Define the recipient’s operation before discussing a file extension.
State the information layers and permitted loss explicitly.
Record release, profile, direction, dependencies, and acceptance evidence.
Treat unknowns as open questions, not as implicit compatibility.
A successful transfer is useful only when it supports the task the recipient actually needs to perform.