Read, Write, Import, Export: Why Support Is Directional and Version-Bound

“Supported” is an incomplete verb. A product may read a representation without writing it, open it without preserving its authoring semantics, or write a version that a particular receiver does not accept. Read support is not a reciprocal promise of write support.

Define the operation

Use the product’s own terminology, then record what the operation means in the proposed workflow:

Term	Practical question
Direct open	Can the product open the source representation through its native or direct reader?
Import or read	Can the product ingest the representation into its own working model?
Export or write	Can the product serialize a result into the named representation?
Reference	Can the product use the source in place or through a linked view without creating the same kind of editable model?
Translation	What mapping occurs between the source representation and the destination model or output?

The words are not universal API definitions. A support page’s definition and scope take precedence over assumptions based on another product. In every case, identify the direction: source → destination for an import, and destination model → output representation for an export.

Qualifiers that make a support claim useful

Rewrite a bare statement such as “supports STEP” into a record containing:

• product name, edition, and release;
• translator or exchange component version, if documented;
• operation and direction;
• source and output format identifiers;
• schema, application protocol, profile, or model view;
• source-version range or exact release;
• content scope and stated limitations;
• settings or dependencies that affect the result; and
• the downstream operation that still has to work.

Without these qualifiers, the statement may be true for a different release, direction, representation scope, or content subset.

A bounded reading exercise: VRED 2026.2

Autodesk’s VRED documentation has a section for VRED 2026.2 and states that it uses ATF 14.23.0. Its tables separate columns named “Import (Read)” and “Export (write).” In the current section, the table lists these examples:

Representation	Import (Read)	Export (write)	What the row does not establish
3MF (.3mf)	All versions	All versions	That a specific 3MF extension or print workflow is preserved
Inventor (.iam, .ipt)	Up to Inventor 2026	N/A	That a VRED import remains editable in Inventor
IFC (.ifc)	IFC2x3, IFC4, and IFC 4.3	N/A	Which view, information requirement, or IFC semantics survive
STEP (.step, .stp)	AP214, AP203E2, and AP242	N/A	That every entity or downstream CAD operation is preserved
USD (.usd, .usda, .usdc, .usdz)	All versions	All versions	That all composed assets resolve in the receiver
FBX (.fbx)	All versions	2016, 2018, 2019, and 2020	That the import and export mappings are equivalent

This is evidence about the VRED 2026.2 documentation and its listed scopes. It is not a general compatibility matrix, a product recommendation, or an end-to-end route result. The page contains historical release sections, so do not mix their rows into a current claim.

Version asymmetry is normal

A writer can emit a newer schema or representation variant than the reader understands. A reader can accept several older variants while the writer exposes only selected output versions. Even when both sides name the same family, a release, profile, extension, or implementation setting can change the result.

The buildingSMART release database illustrates why status belongs in the record: IFC 4.3.2.0 is listed as official, while IFC 4.4 and IFC 5 are under development on the accessed page. glTF likewise requires an asset to declare its target version, while a GLB carries a separate container version. These format-level facts do not replace checking product support.

Questions to settle before transfer

Send the receiver a precise question:

Can product A, release X, export representation Y at scope Z, and can product B, release W, import or reference that same scope in direction D for operation O? Which data is unsupported, transformed, or external, and how will we validate it?

Ask for:

1. the exact documentation page and product release;
2. the operation and direction, not just the format name;
3. version, schema, profile, model view, and extension scope;
4. known content restrictions and fallback behavior;
5. dependencies such as external resources or linked files; and
6. a test and acceptance method for the actual downstream task.

If the answer is only “the file opens,” continue with what a translator actually does and the relevant information-layer validation. A support declaration tells you what to test; it does not perform the test.

Key points

• Import/read and export/write are directional operations.
• Product release, translator version, representation scope, and content limits are part of support evidence.
• A support row does not establish semantic preservation or downstream usefulness.
• Treat time-sensitive support documentation as a bounded observation that must be rechecked when the route matters.