The question that reaches me most often about STEP handoffs is some version of: “If we export AP242 instead of AP214, do we keep the colors, the part names, and the PMI?” The honest answer is that the protocol label is only half the decision. The other half is the exporter dialog and the importer on the receiving end. A file can be written to AP242 and still arrive at the shop with unnamed solids and default gray shading, because the protocol sets the ceiling and the tool settings set the floor.
This article separates the layers, states what the standards and vendor documentation actually support, and gives a verification procedure you can run before a Revit-derived model reaches a CAM programmer or a machine operator.
Separate the encoding from the application protocol
STEP is a family of standards under ISO 10303. Two different things get conflated in everyday conversation:
- Part 21 is the implementation method: the clear-text file encoding. ISO 10303-21 specifies “an exchange structure format using a clear text encoding of product data for which the conceptual model is specified in the EXPRESS language” (ISO 10303-21, third edition). This is the syntax of the file you open in a text editor.
- AP203, AP214, and AP242 are application protocols. They define which data can be represented for a given engineering domain. The protocol is recorded in the file header, not in the file extension.
That last point matters operationally. A STEP AP242 file uses the same .stp or .step extension as older STEP files, and “the AP242 content and its edition sit inside the file header rather than in the file name” (DAC.digital, STEP AP242 and PMI explained). If your intake process classifies files by extension, it is not classifying by protocol. You have to read the header.
The third edition of Part 21 also added anchor and reference sections that “allow entities and values to be defined in external files” (ISO 10303-21). That is relevant to any firm distributing large assemblies across multiple files, but it does not change the protocol question. A Part 21 file is still whatever application protocol its header declares.
What the protocols actually carry
The commonly cited capability differences, as summarized by translation vendors:
- AP203 covers geometry, topology, assembly structure, and configuration management. The original version “doesn’t support colors or layers. Edition 2 added these capabilities, but support varies between software” (HVH Industrial, STEP AP203 vs AP214 vs AP242).
- AP214 is described as defining “everything in AP 203 plus colors, layers, GD&T (geometric dimensioning and tolerance) and design intent” (Capvidia, Best STEP File to Use).
- AP242 “merges STEP AP 203 and AP 214 to create a single standard for model-based 3D engineering” and adds 3D semantic PMI (Capvidia). It also includes PMI “such as GD&T, BOM, and other meta-notes & notes for building and measuring the part or assembly” (Capvidia).
So the premise that AP214 strips colors is not supported by the documentation. AP214 is described as carrying colors and layers. What AP214 does not carry, per these sources, is the semantic PMI layer that AP242 adds. If your downstream workflow depends on machine-readable tolerances, that is the real gap, not color.
I want to be precise about what I am not claiming. The retrieved sources do not establish a general behavior in which AP214 silently strips entity names. Entity names are a separate question from colors and layers, and the protocol summaries above do not address them directly. Treat any claim that “AP214 kills names” as unverified until you test it with your specific exporter and importer.
Semantic versus graphical PMI is the distinction that decides usefulness
AP242 can store PMI in two forms, and the difference determines whether the data feeds automation or only human review:
“Graphical PMI: the annotations exist as lines and text for a person to read on screen. They look right, but a machine cannot interpret their meaning. Semantic PMI: the annotations are linked to the geometry and carry machine-readable meaning.” (DAC.digital)
For a Revit-to-CAM handoff, this is the practical fork. If the receiving CAM or inspection tool reads semantic PMI, a tolerance tied to a face can feed programming or measurement without a person re-reading a drawing. If the file carries only graphical annotations, the operator sees lines and text that look correct but the software cannot act on them. A file that “looks right” on screen can still be functionally empty for automation.
The Revit export path is tool-dependent, and the dialog is part of the standard
There is no single “export to STEP” operation in Revit. The retrieved documentation for one third-party add-in, ExportMaster for Revit STEP, illustrates how much the outcome depends on the exporter:
- It exposes a Transfer Attributes option that “enables the transfer of Name, Layer & Color information” (Autodesk App Store help doc, ExportMaster for Revit STEP).
- It offers a schema choice between AP203 and AP214 (same source).
- In that release, the PMI-related options (“XML Output Option” and “PMIXML Type”) are disabled, and PMI is described as a feature planned for a later release (same source).
Read that carefully. In this specific tool, at this specific version, you can choose AP203 or AP214 but not AP242, and PMI export is not available. If a firm standard says “always export AP242 with PMI,” this tool cannot comply. The standard is only as good as the exporter that implements it.
I am citing this add-in as a concrete example of option dependence, not as a statement about Autodesk’s native Revit exporter. The retrieved sources do not document a native Revit STEP exporter, so I will not describe one. The lesson generalizes regardless: the exporter dialog determines which attributes are written, and that dialog differs by tool and version.
For comparison, CAD Exchanger states that during import and export it supports “B-Rep and polygonal representations; assembly structure, including via external files; names; user-defined and validation properties; PMI; colors; layers” (CAD Exchanger, Revit to STEP). That is a broader attribute list than the ExportMaster release above. Two tools, two different floors. The protocol ceiling is the same; what actually gets written is not.
A verification procedure you can run before release
The goal is not to prove that STEP works. The goal is to confirm that the specific attributes your CAM or inspection workflow consumes survived the specific export you performed. Run these checks in order.
1. Read the header, not the extension
Open the .stp file in a text editor and inspect the header section. Confirm the application protocol and, where present, the edition. The extension tells you nothing about the protocol. If your intake process routes files by extension, fix that first; it is a cheap change that prevents misclassification.
2. Confirm which attributes the exporter was set to write
Before exporting, open the options dialog and record the settings: attribute transfer on or off, schema selection, units, and any PMI options. If the tool disables PMI export, document that. A handoff standard that cannot be reproduced by the next person is not a standard; it is a habit.
3. Check names and colors in the receiving tool
Import the file into the actual CAM or inspection application, not a generic viewer. Confirm that part names appear in the assembly tree and that colors map to whatever grouping or layer logic your shop uses. If names are missing, the nesting or BOM step downstream will require manual re-entry, and that is a time cost you can measure per job.
4. Determine whether PMI is semantic or graphical
If the workflow depends on tolerances, confirm that the receiving tool can read them as data, not just display them as annotations. A viewer that shows the callouts is not proof that the CAM system can consume them. If the file carries only graphical PMI, plan for manual transcription and price that into the job.
5. Compare against the source before release
Spot-check a representative subset of parts: names, colors, and any PMI that matters. This is not a full audit; it is a release gate. The cost of the check is minutes. The cost of a missing tolerance reaching the shop floor is rework, and rework on a machined part is measured in material and machine time, not minutes.
A worked example, clearly hypothetical
Suppose a shop receives a Revit-derived STEP file for a set of connection plates. The file opens, the geometry is correct, and the plates display in a single default color with generic solid names. The CAM programmer cannot tell which plate is which without cross-referencing the drawing, and the nesting step requires manual renaming.
Where to look, in order:
- The header. Which protocol was written? If the exporter was set to AP203, colors and layers may not have been in scope at all.
- The exporter options. Was attribute transfer enabled? The ExportMaster documentation shows this is a toggle, not a default guarantee (Autodesk App Store help doc).
- The importer settings. Some CAM tools have their own import options for names and colors. A file that carries the data can still arrive stripped if the import step discards it.
I am not asserting that this failure occurs at any particular rate, or that any named vendor behaves this way. The scenario is constructed to show where the checks apply. The point is that the diagnosis requires looking at three places, not one, and that “the file opened” is not a passing test.
Transparency and other attributes that behave inconsistently
Color is not the only appearance attribute with uneven support. STEP defines a surface_style_transparent entity with a transparency value from 0.0 to 1.0, present in AP203 edition 2, AP214, and AP242. But “support is inconsistent in practice — many CAD tools do not reliably export or import transparency values via STEP” (RapidPipeline, Revit to STEP conversion guide).
This is a useful calibration for the whole discussion. The standard can define an entity; the tools can still fail to write or read it. Protocol capability is necessary but not sufficient. Every attribute you depend on needs a tool-level check.
What to put in the firm standard
Based on the documented capabilities and the tool dependence above, here is the rule I would write into a file-exchange standard for a firm of 5 to 500 people:
- Choose the most capable protocol both ends support. AP242 is the superset and the right default where the exporter and importer both handle it. AP214 remains a reasonable fallback where AP242 is not available, and it does carry colors and layers.
- Record the exporter settings per tool and version. The options dialog is part of the handoff specification. A standard that says “export STEP” without the settings is incomplete.
- Verify the attributes the downstream workflow consumes, not the file’s ability to open. Names for nesting and BOM, colors for grouping, semantic PMI for tolerances. Each has a different failure mode and a different cost.
- Treat graphical-only PMI as a manual step. If the file cannot feed automation, price the transcription into the job rather than discovering it at the machine.
The protocol label is the easy part. The work is in the dialog and the receiving end, and that is where the handoff either holds or quietly costs you a shift.
FAQ
Does AP214 strip colors?
No, per the retrieved documentation. AP214 is described as defining everything in AP203 plus colors, layers, GD&T, and design intent (Capvidia). The original AP203 lacked colors; Edition 2 added them with varying software support (HVH Industrial).
What does AP242 add over AP214?
AP242 merges AP203 and AP214 and adds 3D semantic PMI, among other capabilities (Capvidia). The semantic PMI layer is the difference that matters for CAM and inspection automation.
How do I tell which protocol a STEP file uses?
Read the file header. The .stp or .step extension does not reveal the protocol or edition (DAC.digital).
Why did my part names disappear?
Check three places: whether the exporter was set to transfer names, whether the protocol in scope carries them, and whether the importer has its own settings that discard them. The ExportMaster documentation shows attribute transfer as an explicit toggle for Name, Layer & Color (Autodesk App Store help doc).
Can I trust that PMI survived because I can see it on screen?
No. Graphical PMI displays as lines and text but cannot be interpreted by software. Only semantic PMI is linked to geometry in a machine-readable form (DAC.digital). Confirm the type in the receiving tool before relying on it.