Hardware: where everyone has their own source of truth
When I talk to engineers about version control in hardware engineering—and to clarify up front as usual, I mean planes, trains, automobiles, rockets, and circuit boards—I generally get one of a handful of reactions:
- The software engineer: surely there is version control — Git, right?
- The mechanical design engineer: we already capture “everything” in Onshape!
- The startup engineer: ahaaah, yeaaaah, well… our spreadsheets are fairly organised and serve us well (for now).
I realise I’ve left off systems engineers, who stake out two further camps: Jama solves everything vs. I see the chaos play out every day. This is all a dramatic and unsympathetic simplification. There is a continuum of opinions on this, but we can find some ground truth if we examine the hardware development software stack.
I’m turning over a new leaf of not burying the lede, so here’s my thesis up front:
- Many local/isolated versioning systems are strictly worse than one,
- Local is better than nothing, but that’s a low bar,
- Does your development stack merely manage releases or does it fuel exploration?
The software-for-hardware dev stack
| Layer | What it’s for | Typical artifacts | Representative tools/vendors |
|---|---|---|---|
| 1) Intent & obligations (RM) | Requirements, traceability, approvals | reqs, hazards, compliance, reviews | DOORS Next, Jama, Polarion, codebeamer |
| 2) System model (MBSE) | Architecture, behavior, interfaces at system level | SysML models, allocations, behaviors | Cameo/Magic, Rhapsody, Simulink/System Composer, Capella |
| 3) Interfaces & budgets (ICDs/budgets) | Cross-team contracts (envelopes, pinouts, power/thermal budgets) | ICDs, envelopes, keep-outs, budgets | often RM/PLM objects + docs (Confluence etc.) |
| 4) Domain realization (authoring) | The “thing you build” in each discipline | CAD parts/assemblies, schematics/layout, firmware | NX/CATIA/SOLIDWORKS/Creo/Onshape; Cadence/Altium/KiCad; Git for firmware |
| 5) Analysis & simulation (CAE) | Predict performance; de-risk decisions | solver decks, meshes, results, reports | Ansys/Synopsys, Simcenter, SIMULIA/Abaqus, Altair, SimScale, Luminary, Simscape, Modelica |
| 6) Release spine (PDM/PLM + ECO/ECR) | Baselines, part/BOM revisions, change workflows, “what’s released” | part masters, BOMs, ECOs, configs | Teamcenter, ENOVIA, Windchill (+ lots of PDM variants) |
| 7) Verification & evidence (test) | Prove it works; capture failures | test procedures, logs, HIL results, anomalies | NI/LabVIEW, Polarion test, Simulink Test, Nominal, Applied Intuition |
| 8) Ops & sustainment (field truth) | As-built/as-maintained + failures | FRACAS, MRO, fleet/asset history | Maximo, Servigistics, Teamcenter SLM, PI System |
A single source of truth, only more so
The first ground truth is that hardware development is complex. Each row in the table above is a deep technical specialization—entire careers, and entire software empires, live inside each row. There’s decades of serious scientific contribution here, and I’m not going to play that down.
But it is 2026. We get to stand on the shoulders of giants and dream of a better world (and yes, sprinkle a little AI on top) rather than accept that our approach must be rigid, and the software stack that supports it must remain as a hamlet of walled gardens.
The second ground truth: the reason everyone thinks there’s version control is that everyone has it. The problem is… everyone has it! That is, their own, isolated concept of it:
- Revision history: “this artifact changed.” Common in RM, shows up in MBSE, strong in CAD/ECAD file history. Useful, but local.
- Release configuration control: “this is the approved, buildable baseline.” This is where PLM/PDM have their moment—downstream of many messy cycles of design exploration.
- Exploratory branching: “try three directions in parallel and merge what works.” The not-so-secret sauce of software, and still oddly rare in most hardware domains.
- Legible intent capture: “this changed because…” RM is built for this; CAD is famously not.
The thing hardware development lacks is an intuitive, shared way to make system changes legible — to humans and machines — across the development cycle and the multi-modal artefacts that crop up between concept and product.
Two things have to be true at once for exploration to be cheap: the system’s state has to be legible to humans and machines, and changes to it have to flow through one coherent version-control plane. Most hardware stacks have neither. The rest of this piece is about what that costs — and what it looks like when a domain starts to get both right.
My favourite example — CAD
Mechanical CAD is my go-to case study (or punching bag) within the software-for-hardware development stack, for a few reasons:
Teams often treat CAD geometry as the system source of truth, and it’s tempting to think that because Onshape offers branching, the whole problem is solved. Onshape’s branching is genuine progress on the VCS axis — credit where it’s due. But branching a compiled artifact doesn’t rescue the legibility you lost at compile time. You can fork the geometry all you like; the why still isn’t there to diff. A lot of engineering design happens upstream of geometry.
I think of CAD as a lossy and hard-to-invert process of encrypting engineering design intent (thermal, structural, aero, manufacturing, cost, etc.) into 3D geometry; it’s not a complete source of truth. More importantly, from a systems point of view, many solids could satisfy the same intent, and many part trees could represent the same solid. So even if you have the geometry, you still don’t have the why. The intent, before it got encrypted, was the kind of thing a human or a machine could actually reason about. The geometry isn’t.
In software development, you version control the source code, not the compiled output. A lot of source code is intent-adjacent—people often refer to Python as executable pseudocode. If you version control your Python code, you version control both your system and your design intent. Nice. It would be a dick move to version control only the bytecode, and yet, we effectively do that in CAD land.
CAD illustrates the gap: hardware development needs both legibility and coherent versioning.
ECAD as the breakout contrast case
There’s a case study playing out in the electronics CAD (ECAD) space — the domain that’s furthest along on both axes. The native objects are already a little software-like: components from libraries, named nets, constraint rules. And the complexity is in (stable) topological space rather than 3D space with unstable topologies.
The interesting signal is that parts of ECAD are now being re-imagined and reshaped into explicitly source-code forms—domain-specific languages (DSLs). This makes the design definition itself readily diff-able and lint-able. You could version a circuit as a topology graph, but as a DSL you (and Claude) can actually do real work on it.
Diode.computer is a good example: Zener, their open-source DSL, is built on top of Starlark for describing PCB schematics (nets, interfaces, modules), and their pcb CLI compiles Zener designs into KiCad projects for layout. They’ve essentially made a good chunk of the ECAD design lifecycle code-based, and therefore machine-legible, diff-able, version-controllable, and friendly to agents and exploration — the promised land.
Machine-legible artefacts with common version control semantics through the development cycle (is all you need)
That’s not so much to ask, is it? I feel strongly that it’s the right north star to guide hardware engineers.
Software engineering has long demonstrated the rapid development velocity that’s possible when the source description and accompanying commentary are diff-able and version-controlled. AI agents have taken to this substrate like ducks to water.
I don’t think it matters whether you believe the hype — as I do — that AI will soon transform hardware development, and that it will need a legible context layer and a single, coherent, diff-able exploration layer to do so. You could just believe the lesser hype: that human engineers need it too.
Exploration is how game-changing hardware gets built, and exploration needs both legibility and coherent versioning.