CADHub

Initial migrations page
Inserting your onshape keys
Solidworks input
Output transfer log
Onshape output + feature tree

Inspiration

We started CADHub because the way CAD moves between systems fundamentally does not match the way engineers actually design. A CAD model is not simply geometry, it is a collection of sketches, features, constraints, parameters, references, assemblies, and relationships that describe both what was designed and how it was designed. Yet when models move between CAD systems, engineers are often forced to export static representations that preserve the final geometry while losing much of the information that drove it.

A conversation with an engineer who had decades of experience with CAD migrations at GM made the scale of this problem clear to us. He described the difficulty of migrating a SolidWorks database into Siemens NX, where identities and relationships also had to be reconstructed. His description of what remains when those relationships disappear was simple: a "bucket full of parts."

The distinction that became most important to us was the difference between translating geometry and translating a feature tree. An AI system looking at a STEP model can infer a plausible way a part was built, but plausible is not the same as correct. The engineer already defined the features, parameters, constraints, and relationships they wanted. We wanted to preserve that information rather than ask another system to guess.

What it does

CADHub is a Git-inspired interoperability and version-control layer for CAD. Instead of treating a model as one opaque file, CADHub identifies the engineering objects inside it and creates persistent relationships between corresponding objects across CAD systems.

Rather than reconstructing a feature tree from final geometry, CADHub starts from the native model, extracts known features and relationships through CAD APIs, and maps that information into a representation that can exist independently of the original platform.

Existing PDM and PLM systems are extremely effective at managing files, revisions, BOMs, approvals, and engineering changes. CADHub explores a layer underneath that: not simply knowing that Revision C replaced Revision B, but understanding what changed inside the model.

How we built it

We connected directly to CAD APIs so that we could work with the information inside native models rather than beginning with exported geometry.

From each system, we extract information about parts, features, parameters, references, and identifiers, then associate corresponding objects through a backend mapping layer. This required us to distinguish between document identity, version identity, part identity, occurrence identity, and the persistent identity of the engineering object we actually wanted to track.

We then modified models and observed how those identifiers behaved. By storing relationships outside either CAD platform, CADHub can continue tracking corresponding engineering objects even when each system represents them differently.

Challenges we ran into

The largest challenge was identity. There is no universal identifier that simply means "this is the same engineering object" across CAD systems, and different APIs expose different persistence behavior.

We also ran into the problem of semantic equivalence. SOLIDWORKS, Onshape, Siemens NX, and other CAD platforms can represent the same engineering operation using different feature definitions, references, and dependency structures, meaning feature-tree translation cannot be solved by simply copying one API object into another.

Geometry alone does not solve this either. Two models can produce nearly identical solids while containing completely different sketches, constraints, feature histories, and design logic.

This became one of the principles behind CADHub: AI can help resolve ambiguity between systems, but it should not guess information that the engineer already explicitly defined.

Accomplishments that we're proud of

During MHacks, we built the beginnings of infrastructure for connecting multiple CAD environments, mapping corresponding engineering objects between them, persisting those relationships outside an individual CAD application, and observing how those identities behave as models change.

More importantly, we developed a clearer definition of interoperability. Successfully transferring geometry does not necessarily mean the design itself survived the transfer.

We started by trying to connect CAD files. We ended up building toward a system that can preserve the information behind them.

What we learned

We learned that CAD interoperability is fundamentally an information problem, not simply a file-format problem. Different CAD systems contain many of the same underlying engineering concepts, but represent them through different APIs, feature definitions, dependency structures, and identifiers.

We also learned that preserving known information is very different from recreating it. If an engineer has already defined a parameter, constraint, reference, or dependency, rebuilding the model from exported geometry unnecessarily turns something deterministic into something probabilistic.

As more engineering information moves directly into the model through Model-Based Definition, that distinction becomes increasingly important.

What's next for CADHub

CADHub currently begins with persistent identities and mappings between CAD objects, but the larger goal is to preserve more of the structure that gives a model its engineering meaning, including sketches, features, parameters, constraints, assemblies, references, and dependencies.

Eventually, we want a design created in one CAD system to move into another while preserving not only its geometry, but its editable feature history and engineering relationships.

Our long-term goal is simple: engineering data should not be trapped inside the tool that created it.