AI for Engineering Productivity
STEP, IGES, and Parasolid handle CAD geometry differently. Learn where translations break, why AP242 is the default, and how to keep design intent intact.
·
⏱
8 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
STEP, IGES, and Parasolid are not three grades of the same thing. Parasolid gives the highest fidelity when both systems share the kernel. STEP AP242 is the right neutral default in 2026, because it carries closed solids, assembly structure, and semantic tolerance data that earlier protocols dropped. IGES is a legacy option that should be chosen only when nothing else works. Most of what goes wrong in a handoff is not geometry corruption but information loss: parametric history, annotation, and identity that no healing tool can restore. Decide what the recipient needs, match the kernel when possible, validate imports against measurable properties rather than appearance, and record the settings you used. When intent has already been lost, the answer is retrieval from your own engineering records.
Every mechanical engineer has opened a translated file and found something wrong. A face that will not knit. A fillet that arrived as thirty separate surfaces. An assembly that looks correct until you try to edit it and discover there is nothing left to edit. The geometry is technically present, but the model has stopped behaving like a model.
This is the daily reality of CAD interoperability, and the format you choose largely determines how bad it gets. STEP, IGES, and Parasolid are the three names that come up most often, and they are not three equivalent options on the same menu. One is a neutral standard that is still actively maintained and extended. One is a neutral standard that stopped evolving in the 1990s. One is a native kernel format that carries geometry with very high fidelity but ties both ends of the exchange to the same modeling engine.
Choosing badly costs real hours. Topology fragments, parametric history disappears, tolerance and annotation data gets stripped, and someone spends an afternoon healing surfaces that were perfectly fine before the export. This guide covers what each format actually preserves, where translations break and why, why STEP AP242 has become the sensible default in 2026, and what to do when a handoff has already flattened the design intent you needed.
What STEP, IGES, and Parasolid Actually Are
The three formats come from different eras and solve different problems. Treating them as interchangeable is the root of most translation pain.
IGES (Initial Graphics Exchange Specification) dates to 1980 and was standardised through ANSI. It is fundamentally a surface and wireframe format. It can carry the faces that make up a part, but it has no strong concept of a watertight solid, so the receiving system has to infer topology by stitching surfaces together. Development stopped at version 5.3 in 1996. Nothing has been added since, including any real support for tolerances, annotation, or assembly structure.
STEP (Standard for the Exchange of Product model data, ISO 10303) is the modern neutral standard, and it is still being extended. STEP defines solids as boundary representation, so a well formed STEP file describes a closed volume rather than a bag of surfaces. It also carries assembly structure, colour, and, in the right application protocol, full tolerance and annotation data.
Parasolid is not a neutral standard at all. It is a geometric modeling kernel, and its transmit files (.x_t text and .x_b binary) are that kernel's own serialisation. When both the sending and receiving systems are built on the same kernel, geometry transfers with essentially no conversion, because there is nothing to convert.
That last distinction is the one engineers most often miss. A neutral format asks two different mathematical representations to agree. A kernel format sidesteps the question entirely, which is why it is usually the highest fidelity option available and simultaneously the least portable. If the receiving system runs a different kernel, a Parasolid file is no better than any other import and may be worse, since the reader has to interpret a format it did not design.
IN PRACTICE
The geometry search has been invaluable, helping me find standard parts instead of designing new ones, saving a huge amount of time and effort. The search system is smart and CAD-aware.
- eytan s., R&D Engineer
Where Interoperability Actually Breaks
Translation failures are rarely random. They cluster into a small number of predictable categories, and knowing them tells you what to check first.
Topology fragmentation. Two kernels represent the same curve or surface with different mathematics and different internal tolerances. A blend that one system stores as a single analytic face may arrive as a strip of spline patches. If the gaps between those patches exceed the receiving system's sewing tolerance, the body never closes, and you get a surface model where you expected a solid.
Lost parametric history. Neutral formats transfer the result of your modeling, not the reasoning behind it. Sketches, constraints, feature order, and design tables do not survive. What arrives is a static body, which is why parametric modeling work usually has to be redone rather than adjusted after a cross system handoff.
Missing tolerance and annotation data. If dimensions, datums, and geometric tolerances live only on a drawing, a geometry translation carries none of it. Downstream users then measure the model to guess at requirements, which is exactly how a nominal dimension quietly becomes the specification.
Assembly structure and identity. Component names, instance structure, and part numbers often flatten or get renamed on export. Reconnecting the result to the original records afterwards is one of the more tedious parts of any CAD data migration.
Units and scale. Less common, but the most damaging when it happens, because a model that is uniformly wrong by a factor of 25.4 still looks entirely plausible on screen.
Only the first category is really a geometry problem. The rest are information loss, and no amount of surface healing recovers them.
Why STEP AP242 Is the Modern Default
STEP is not one format. It is a family of application protocols, and the one you export matters as much as the choice of STEP itself.
AP203 covers configuration controlled 3D design. It handles solids and assemblies but was scoped around mechanical geometry with limited presentation data.
AP214 extended that toward automotive process data, adding colour, layers, and richer assembly handling.
AP242 merges the two and adds what the earlier protocols lacked: product manufacturing information, tessellated geometry alongside exact geometry, and kinematics.
The important addition is semantic product manufacturing information. Graphical annotation transfers a tolerance as lines and text positioned in 3D space, which a human can read and a machine cannot. Semantic annotation transfers it as structured data attached to the specific face it governs, which means downstream software can query it. That is the difference between a model that documents a requirement and a model that carries one.
In practice the guidance is short. Export AP242 when both systems support it. Fall back to AP203 or AP214 only when the receiving system is old enough to require it. Choose IGES only when nothing else is available, and expect to spend time healing the result. Reach for Parasolid when you know both ends share the kernel and you want maximum geometric fidelity for a single handoff.
One caveat worth stating plainly: a file being valid AP242 does not mean the exporting system populated everything AP242 allows. Support varies between products, and the only way to know what your particular pipeline carries is to export a representative part and inspect what arrives.
A Translation Workflow That Does Not Break the Model
Most recurring interoperability pain comes from treating export as a single click rather than a decision. A short, repeatable sequence removes most of it.
Decide what the recipient actually needs. Editable features, a reference solid, or just a visual envelope are three different requirements. Only the first justifies rebuilding, and the third is often satisfied by a lightweight tessellated representation.
Match the kernel when you can. If both systems share a modeling kernel, the kernel's own transmit format is the shortest path and the least lossy.
Otherwise default to STEP AP242. Include product manufacturing information if your exporter supports it, and confirm the receiving system reads it rather than assuming.
Export at the right granularity. Sending a whole assembly as one merged solid destroys component identity. Preserve the assembly tree unless the recipient has asked for a single body.
Check tolerance settings before exporting, not after importing. Most exporters expose a resolution or tolerance parameter. Setting it tighter than the receiving system's sewing tolerance prevents most stitching failures.
Validate on import against something measurable. Compare volume, surface area, mass properties, and bounding box against the source. A closed solid with matching volume is strong evidence the translation succeeded. Visual inspection alone is not.
Record what you did. Format, protocol, exporter version, and settings belong with the file. When the same handoff fails in six months, that record is the difference between a five minute fix and a rediscovery, which is where disciplined version control pays for itself.
None of this is difficult. It is simply rarely written down, which is why the same failure recurs on every new project with every new supplier.
Recovering Design Intent After the Handoff
Preventing loss is the ideal. Recovering from it is the common case, because most of the imported geometry an engineering team works with arrived long before anyone wrote down a translation policy. You inherit a static solid with no history, no annotation, and no record of why a wall is 4 mm rather than 3 mm.
That information usually still exists inside the organisation. It sits in the original drawing, a supplier email, a past calculation, a change order, or a revision comment in a vault. It is simply not attached to the file you are holding. The problem is retrieval, not absence, which is the same pattern behind most legacy engineering data difficulties.
This is the gap Leo AI is built to close. Leo is an AI assistant for mechanical engineers, trained on more than a million pages of standards, books, and technical articles, and it offers integrations with leading PDM and PLM platforms (SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, Arena PLM, and others). Because it is aware of geometry as well as documents, it can take an imported body and surface the records that describe it: the earlier revision it derives from, the tolerance study behind a fit, the decision that fixed a dimension. It cites its sources, so you can verify a claim instead of trusting it, which matters a great deal when you are reconstructing requirements from fragments. Leo sits as an intelligence layer on top of the systems you already run rather than replacing them, and it is SOC-2 certified with no models trained on customer data.
Doing this well is closely related to capturing design intent in the first place, so that the next handoff loses less.
FAQ
Recover the intent in imported CAD
Leo reads your geometry and your engineering history, then cites both.
Leo AI is built for mechanical engineers. It searches geometry across your PDM and PLM records, surfaces the decisions behind a part, and shows the source for every answer.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
