“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 historical 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 that release 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.
Separate a toolkit change from support rows: VRED 2027
Autodesk states that VRED 2027 uses the New Data Translator as its only translator for NX, SolidEdge, SolidWorks, and CATIA V4/V5 files; the Legacy Translator and the switch between toolkits were removed. That release note identifies which toolkit serves those file families. It does not give their read/write direction or version bounds.
A separate VRED 2027 release-note section gives these selected file I/O declarations:
| Direction | Listed representation/version | What the declaration does not establish |
|---|---|---|
| Read | Inventor 2027; Parasolid Binary 38 and Parasolid Text 38; NX 2506 and 2512 Series; Solid Edge 2026; 3D ACIS ASM 232 | That every file at those versions is accepted or that its payload is preserved |
| Write | JT 10.7 | That a particular receiver accepts the result or that it retains a required data layer |
This is a selection from the VRED 2027 File I/O release note, not a complete support matrix. The same release note documents an option to exclude constraints and physics attachments when exporting a scene or selection to VPB or OSB. A documented option is not evidence that a given export used it.
Read consortium matrices as declarations: 3MF
The 3MF Consortium’s matrix separates Core Import from Core Export and lists extensions in their own columns. It says vendors self-report the entries and that the Consortium does not independently verify them. Its “Custom” label means custom or partial support; an empty cell is not a negative support claim, and the page provides no uniform product-release or extension-version column.
For example, the displayed Fusion 360 row lists Core import and export and Materials import, without a Materials export entry. Read this as a vendor-reported matrix declaration without a product release or file test—not as independent verification, proof that an individual material payload survives, or a statement that the blank cell means unsupported.
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:
- the exact documentation page and product release;
- the operation and direction, not just the format name;
- version, schema, profile, model view, and extension scope;
- known content restrictions and fallback behavior;
- dependencies such as external resources or linked files; and
- 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.
- Toolkit availability, directional I/O declarations, and self-reported consortium entries are different evidence types.
- Treat time-sensitive support documentation as a bounded observation that must be rechecked when the route matters.