Design Software History: File Formats as Industrial Power in CAD History

File formats as power structures, not just technical containers

Formats as industrial governance

In the history of engineering software, file formats were never merely passive vessels for geometry, drawings, or metadata. They functioned as mechanisms of industrial governance, quietly determining who could participate in a workflow, under what conditions, and at what cost. A CAD file might appear to be a technical artifact, but in practice it embodied the assumptions of a specific software architecture, a specific vendor strategy, and a specific view of what counted as valid design knowledge. When companies such as Autodesk, Dassault Systèmes, PTC, Siemens, SDRC, and Intergraph designed their native formats, they were not simply solving storage problems. They were defining the boundaries of their ecosystems, shaping user behavior, and influencing procurement decisions across manufacturing, aerospace, automotive, shipbuilding, and plant design.

The political dimension of engineering file formats becomes especially clear when one considers the asymmetry between software publishers and industrial customers. A vendor that controlled a dominant format often gained more than a revenue stream from licenses. It gained leverage over upgrades, over adjacent products, and over the long-term accessibility of customer knowledge. If a design organization accumulated ten or twenty years of models in a native proprietary format, it became extremely difficult to leave that software environment without incurring translation losses, retraining costs, broken automation, and uncertain archival outcomes. In that sense, the file format became a durable instrument of software lock-in. It also became a way to cultivate partner ecosystems, because resellers, application developers, CAM vendors, CAE tools, visualization platforms, and PLM systems all had to decide whether to build around one vendor’s internal representation or to pursue more neutral pathways.

Control, dependence, and data survival

Control over file specifications shaped several interlocking forms of dependence. First, it governed day-to-day interoperability. If a supplier received geometry in a format that preserved solids, assembly references, attributes, tolerances, and layer structures accurately, collaboration could proceed with relatively low friction. If the same supplier received a crippled or poorly translated file, expensive rework followed. Second, it shaped strategic dependence. Companies that standardized on a dominant file format often found that extensions, product data management links, drawing associativity, and feature intelligence only worked fully inside the originating software family. Third, it affected long-term data survival. The ability to reopen and meaningfully reuse design data ten or twenty years later depended not only on media preservation, but on whether the semantics of that data remained intelligible outside a discontinued product line or obsolete computing platform.

This is why the tension between proprietary formats and neutral exchange standards became so central to engineering computing. Standards bodies such as ANSI and ISO, along with committees associated with PDES and later the broader STEP effort, tried to create representations that would outlive individual vendors and support cross-platform collaboration. Yet the vendors themselves had mixed incentives. Publicly, many supported openness, interchange, and standards-driven workflows. Privately, they knew that their native formats carried the richest product meaning and the strongest commercial leverage. The practical history of design software is therefore full of an unresolved conflict: industry demanded exchange, archiving, and portability, while vendors benefited from preserving the superiority of their own internal data models. That conflict was not incidental to CAD history. It was one of its deepest organizing forces.

The early battles: proprietary CAD data versus the dream of interoperability

Mainframes, workstations, and native data worlds

The earliest mature CAD systems emerged in environments where computing resources were expensive, hardware architectures were diverse, and application software was often built in highly customized ways. During the mainframe and minicomputer eras, and later in the age of engineering workstations from companies such as Apollo, Sun, Silicon Graphics, and Hewlett-Packard, CAD vendors built data structures tightly tailored to their own computational constraints and modeling philosophies. Intergraph developed strong positions in plant design and mapping. SDRC built systems deeply tied to high-end engineering workflows. Computervision, Applicon, and later PTC developed distinctive approaches to product representation. When Autodesk rose with AutoCAD and the DWG format on personal computers, it established another powerful native universe, one especially significant in drafting and later in broader design workflows.

These systems did not merely differ in user interface or hardware targets. They embodied distinct internal representations of design intent. Some revolved around wireframe entities such as points, lines, arcs, splines, and trimmed curves. Others added surface models designed for automotive bodywork, aerospace lofting, or industrial design applications where shape continuity mattered more than volumetric solidity. Still others developed feature structures that encoded operations such as extrudes, revolves, blends, holes, and patterns. Assemblies introduced another layer of complexity, because one had to represent instance relationships, constraints, configuration options, reference geometry, and product metadata. As a result, each vendor’s “file format” was actually a frozen expression of a much larger software worldview, including database assumptions, memory management strategies, geometric tolerancing policies, naming conventions, and update logic.

Why translation was so hard

The dream of interoperability collided with the reality that CAD data was deeply coupled to kernels, modelers, and application behavior. A boundary curve stored in one system might not be mathematically equivalent to a curve in another. A surface could be represented as an analytic form in one package and as a NURBS approximation in another. Topological consistency rules varied. Feature histories were often inseparable from regeneration engines. Assembly references could depend on naming systems that were fragile even within the originating software. Product metadata, including materials, revision states, drafting notes, layer semantics, and manufacturing annotations, might live partly in the file and partly in external databases. Translating such data was not a matter of moving bytes between containers. It was an act of interpretation, reconstruction, and compromise.

Because the application logic mattered as much as the geometry, early exchange workflows often lost information in predictable ways. Wireframe could survive where parametric intelligence could not. Surfaces might arrive untrimmed, duplicated, or disconnected. Solids could degrade into collections of faces. Assembly hierarchies might flatten. Metadata could disappear entirely. These failures were not simply bugs. They were symptoms of a deeper mismatch between heterogeneous design systems. For this reason, native formats became precious strategic assets: they carried the fullest version of the customer’s intellectual work. The costs of leaving one environment rose in direct proportion to the richness of the data embedded within it.

• Wireframe entities were easier to exchange, but limited in semantic richness.
• Surface models preserved shape better for styling and aerospace skins, yet were mathematically fragile across systems.
• Feature structures carried design intent, but depended heavily on the originating software’s regeneration logic.
• Assemblies required stable references, configuration rules, and product structure management that many translators could not reproduce.
• Product metadata often lived outside geometry altogether, making full interchange especially difficult.

IGES and the political triumph of interchange

The emergence of IGES, the Initial Graphics Exchange Specification, was a turning point because it represented not just a technical scheme but a political coalition. It gained force through the needs of U.S. government procurement, aerospace contractors, and automotive supply chains that could no longer tolerate total isolation between major CAD systems. Organizations working with the U.S. Air Force, the National Bureau of Standards, and major industrial contractors pushed for a common exchange mechanism because procurement realities demanded that digital design data move across organizational boundaries. A prime contractor might use one CAD system while suppliers used others, and government agencies wanted deliverables that were not irretrievably trapped in vendor silos. In that environment, a neutral exchange specification was a strategic necessity.

IGES succeeded politically before it fully succeeded technically because it provided a shared reference point around which industry could organize. It gave procurement departments language for requirements. It gave software companies a box to check when customers demanded interoperability. It gave committees and standards advocates a path to institutional legitimacy through ANSI. And it gave the broader market an aspirational story: design data should be portable. Yet its practical limitations were significant. IGES often worked best for drawings, wireframe, and some surface definitions, while richer product meaning remained difficult to preserve reliably. Still, that did not diminish its historical importance. IGES marked the moment when interchange stopped being treated as a private bilateral agreement and became a matter of industrial policy. It announced that CAD file formats had consequences that extended far beyond engineering departments and into the organization of entire supply networks.

Neutral standards, kernel dependencies, and the business incentives behind format strategy

Why STEP promised more than IGES

If IGES was the politically necessary first great exchange framework, STEP, formally ISO 10303, represented a more ambitious attempt to encode product information comprehensively and durably. The promise of STEP was that industrial data exchange should not stop at geometric outlines or drafting entities. It should describe products in ways that support their lifecycle across design, manufacturing, inspection, documentation, maintenance, and archival use. Through the work of ISO committees, the PDES community in the United States, and many corporate participants, STEP developed as a family of application protocols rather than a single simplistic format. That architecture reflected a serious insight: the data needs of mechanical design, electrical systems, shipbuilding, process plants, and configuration-controlled products were not identical, and a neutral standard had to acknowledge domain specificity without forfeiting interoperability.

STEP’s importance lay in its attempt to represent not merely geometry but the structured meaning of engineered products. That meant dealing with boundary representation, topology, tolerances, configuration control, and manufacturing-relevant information that had often been trapped inside proprietary systems. In principle, STEP offered a path toward long-term preservation because it was not tied to the business fortunes of one vendor. In practice, however, breadth and rigor came at a cost: the standard was complex, implementation was uneven, and vendors continued to reserve their richest semantics for native formats. Even so, STEP changed expectations. It made it harder for software companies to argue that interchange had to remain limited to dumb geometry. It also gave large industrial users, especially in aerospace and defense, a stronger basis for demanding durable and supplier-neutral product definitions.

The hard problem of complete product representation

The technical difficulty of neutral representation should not be understated. A solid model is not just a shell of surfaces. It depends on the integrity of boundary representation, which requires careful coordination between geometry and topology. Faces reference surfaces, edges reference curves, loops establish trimming boundaries, and vertices close the structure. Tolerances influence whether the model is interpreted as watertight and manufacturable. If these relationships shift during translation, the receiving system may produce gaps, slivers, self-intersections, or invalid solids. On top of that, engineering workflows increasingly required the preservation of dimensions, geometric dimensioning and tolerancing, notes, layers, materials, finishes, and increasingly the broader domain now called product manufacturing information. Assemblies introduced multiple levels of occurrence, product structure, and configuration logic, while revision and lifecycle status often connected the CAD file to PDM or PLM systems.

To exchange such information reliably, one had to map not only mathematical definitions but also semantic intent. A hole feature in one system might be encoded as a procedural feature with drafting implications, machining relevance, and relations to downstream analysis. In another system, the same result might exist only as cylindrical faces in a B-rep. Likewise, assembly structure might depend on naming rules and reference schemes not visible in the geometric payload. These issues explain why seemingly straightforward marketing promises of “open data exchange” so often dissolved into a reality of data loss, topology repair, feature suppression, or complete remodeling. The problem was not that standards were unnecessary. It was that the software industry was trying to exchange layered forms of knowledge whose meaning depended on years of accumulated architectural choices.

• Boundary representation required consistent geometry-topology correspondence.
• Topology had to survive translation without introducing invalid adjacency or open shells.
• Tolerances affected whether receiving systems could heal or reject a model.
• Product manufacturing information added semantic richness beyond shape.
• Configuration and assembly structure depended on stable product relationships, not just coordinates.

The strategic embrace of standards without surrendering native advantage

Most major CAD vendors learned to support standards in carefully calibrated ways. They could not afford to reject them outright, especially when large customers in aerospace, automotive, and defense procurement required neutral exchange. Yet they also had strong incentives to ensure that native formats remained the most complete, reliable, and operationally valuable carriers of design knowledge. This produced a characteristic pattern across the industry. Companies advertised standards compliance, joined committees, funded translators, and published compatibility matrices. At the same time, they reserved crucial capabilities for native workflows: history-based features, associativity, drafting intelligence, family tables, assembly constraints, knowledge-based rules, PMI fidelity, and direct links to PDM or PLM systems.

The strategies varied by company and historical period, but the underlying logic was consistent. Autodesk benefited enormously from the spread of DWG, whose ubiquity in drafting created a broad ecosystem but also recurring controversy over control, reverse engineering, and compatibility across software versions. Dassault Systèmes, through CATIA and later its broader PLM ambitions, sought to preserve the authority of its own product model while still participating in standards discourse important to aerospace and automotive customers. PTC built a particularly strong story around associative parametric design in Pro/ENGINEER, where the native representation of features and regeneration logic gave customers capabilities that neutral exchange rarely preserved fully. Siemens, through inherited lineages including Unigraphics and later NX, balanced native richness with strong positions around product lifecycle integration and kernel-based interoperability. SDRC and Intergraph operated in sectors where data exchange was commercially unavoidable, yet the practical value of their software still depended on what was lost when customers stepped outside native pipelines.

Kernels as hidden determinants of exchange reliability

Behind much of this history stood geometric kernels, the modeling engines that determined what kinds of shapes could be represented robustly and manipulated consistently. The rise of Parasolid, initially developed by ShapeData and later associated with Siemens, and ACIS, developed by Spatial Technology with important figures such as Ian Braid in the background of solid modeling history, changed the exchange landscape in subtle but powerful ways. When two applications used the same kernel, or closely aligned kernel implementations, reliable exchange often improved because the receiving system could reproduce geometry and topology using similar mathematical assumptions. This did not eliminate differences in application logic, features, or metadata, but it often reduced the geometric damage that occurred during translation.

Kernel dependency also had strategic consequences. If an ecosystem converged around Parasolid or ACIS, vendors could claim a form of openness through common modeling foundations while still differentiating heavily at the application layer. The kernel, in effect, became an infrastructural compromise between total proprietary isolation and fully neutral standards. Yet this compromise had limits. A common kernel did not guarantee preservation of parametric history, design intent, or enterprise metadata. Nor did it resolve competition between vendors who wanted customers to remain inside their own authoring, simulation, manufacturing, or lifecycle environments. In many workflows, a model exchanged “successfully” as a solid still required extensive healing, reclassification of faces, reapplication of dimensions, and rebuilding of downstream intelligence before it could be used in CAM, CAE, or digital mockup contexts with confidence.

Downstream consequences for CAM, CAE, PLM, and supplier collaboration

Format decisions were never isolated to CAD authoring. They shaped the viability of downstream manufacturing, simulation, lifecycle management, and supply-chain coordination. A CAM system needed trustworthy surfaces, trimmed boundaries, and often recognizable machining features. A CAE environment needed clean topology, material assignments, defeaturing pathways, and stable assembly references. A PLM platform needed persistent identifiers, revision semantics, product structure, and links between files, configurations, and documentation. Suppliers needed data they could open without expensive rework or legal uncertainty around translators and licensed interfaces. Therefore the question of format strategy affected not just who could model a part, but who could quote it, tool it, machine it, inspect it, simulate it, certify it, and maintain it over decades.

This is where the gap between marketing and practice became particularly visible. Vendors often promoted interoperability as if it were a solved problem, yet working engineers knew the everyday realities: imported models that looked correct but failed when sectioned; assemblies that lost symmetry or constraints; PMI that survived as dead graphics rather than semantic annotations; analysis models that required manual cleanup before meshing; CAM toolpaths that could not be trusted until surfaces were healed. The receiving organization often bore these costs, especially lower-tier suppliers with less bargaining power. In that sense, format politics had distributive effects. The burden of imperfect interoperability was rarely felt equally across a supply chain. It often fell on the party with less control over the originating software environment.

Conclusion

Control over knowledge, not just files

The history of engineering file formats is best understood as a history of control over industrial knowledge rather than a sequence of merely technical encoding decisions. Every major format embodied judgments about what should be preserved, what should remain vendor-specific, and what kinds of collaboration would be economically favored or obstructed. Native formats gave companies such as Autodesk, Dassault Systèmes, PTC, Siemens, SDRC, and Intergraph durable leverage because the fullest usable meaning of a design often resided inside their own software architectures. Standards initiatives through ANSI, ISO, and PDES/STEP did not eliminate that leverage, but they made its political character more visible. They showed that portability, archival durability, and multi-vendor collaboration were not fringe conveniences. They were central industrial requirements.

What file formats determined, in practice, was who could collaborate efficiently, who could change tools without catastrophic loss, and who possessed authority over the interpretable meaning of a model. A design file was not valuable because it contained coordinates alone. It was valuable because it carried relationships, tolerances, assumptions, manufacturing significance, and organizational context. When that meaning could only be fully activated in one vendor’s environment, customers were not simply buying software. They were entering a governed territory of data dependence. Today’s debates around cloud platforms, APIs, digital threads, model-based definition, and service-based engineering ecosystems are direct continuations of the same struggle. The interfaces have changed, and the scale of integration has grown, but the central question remains familiar: who controls the operational meaning of design data across time, tools, and institutions? In the long arc of design software history, the format was never merely a format. It was infrastructure, leverage, and strategy.