It’s one of the most dangerous sentences you can hear on a factory floor: “The drawing is updated, and we’re good to go.”

It sounds like the finish line. We fixed it! Nothing else to do here.

I’ve watched this play out countless times in different hardware teams. A part caused a headache on the assembly line. The engineering team swoops in, does a root-cause analysis, and edits a tolerance. They move a hole pattern by a millimeter or change a material. The CAD model gets updated, the new drawing is released, and everyone is happy. The engineering problem is solved.

So they kick off the next production run. And then the wheels fall off. Again.

A supplier had still blindly churned out the old revision. Quality control was inspecting an outdated print. The operator on the floor is looking at work instructions that no longer make physical sense, and so on. You get the point.

The engineering team fixed the part, but they didn’t think about the factory.

This disconnect scales ruthlessly with complexity. A CAD file isn’t an island. It’s the center of a massive, fragile web of suppliers, machines, and inspection plans. When you pull one thread, the whole web moves. Making the engineering change is rarely the hard part.

The hard part is knowing what else you just broke with that decision.

If hardware ran like software

If you change a line of code in software, a compiler catches the error in seconds. Automated tests run. Continuous integration pipelines immediately tell you exactly what dependencies you broke before that code reaches a user.

If you change a dimension in hardware, you don’t have a compiler. You have a real factory. And you usually find out what broke a month later when the assembly line stops moving.

It’s time we start running hardware companies more like software companies.

Most hardware companies are already decently good at hoarding files. We have Github, PLM systems, ERPs, and approval gates. All kinds of systems to create thousands of PDFs. But a PDF doesn’t act like a codebase. Knowing which file is the latest version is indeed very different from understanding how that file compiles into a physical product.

Let’s take that mounting hole you just moved two millimeters to the left. In CAD, it’s a trivial drag and drop, Command-S (saved). In the physical world, the CNC machining program needs rewriting, and the CMM inspection probe needs new coordinates.

Technical debt in the physical world

Spend enough time around manufacturing, and you realize the most critical dependencies never show up in a 3D model. This is the hardware equivalent of “technical debt.”

A machine might be perfectly capable of hitting a new tolerance, but doing so adds a second setup and wrecks your cycle time. A material swap looks great on paper until you realize it doubles the supplier’s lead time or ruins a downstream anodizing process.

All that to say we need to stop treating manufacturing changes like administrative document updates. They are biological mutations in a living system. They really are! In software, you wouldn’t just push an update and ask, “Is the code saved?” You look at what breaks or needs some action to be taken.

Answering those questions in hardware means digging through Outlook folders, or opening three different software platforms and hunting down the engineer who built the prototype six months ago to ask him why he used that specific screw.

‘It works on my machine’

Software engineers have a running joke when code fails in production: “Well, it works on my machine.” Hardware engineers have the same problem. There’s a persistent myth that the latest released drawing perfectly matches the physical product rolling off the line (it rarely does).

Maybe a supplier couldn’t hit a spec, so a temporary deviation was rubber stamped. Maybe an operator figured out a faster assembly trick, and the floor adopted it before the paperwork caught up. Over time, the gap between the theoretical product (the drawings) and the physical product (the history of what was actually built) widens into a chasm.

If a unit bricks on the test stand, asking “What does the current drawing say?” is the wrong first step. You need to know exactly which revision this specific unit used, who supplied the subcomponents, and whether this has happened before.

Context before intelligence (black matter)

This is exactly why the current hype around AI in manufacturing starts in the wrong place. We don’t need AI chatbots; we need an integrated development environment (IDE) for physical products.

Manufacturers aren’t starving for data. They’re drowning in it. The bottleneck isn’t information. It’s context. An AI that can read a drawing or summarize a nonconformance report is a nice party trick. But it only becomes powerful when it maps that document to the breathing reality of the factory floor.

If a dimension changes, the system should automatically flag the specific supplier, the machining step, the fixture, and the test protocol that will take the hit, just like a software compiler throwing errors on broken dependencies. It shouldn’t make the final call, but it should eliminate the days of manual detective work required to make an informed decision. Instead of chasing down five different department heads to ask, “Does this affect you?” the system should already know the radioactive blast radius.

This is also why I founded Airsup. The model is not to replace CAD, ERP, PLM, or QMS, or to declare CAD the only source of truth. Those systems remain authoritative for their own domains. People work inside Airsup as the live coordination layer. Airsup can bring in data through APIs and structured imports where those connections are available, but it doesn’t assume every connector is already native or automatic. It links those records to the active build, shows the affected supplier, manufacturing step, work instruction, inspection plan, test result, deviation, and as-built unit, and gives the team one place to review the dependency chain. Approved updates can then be pushed back to the systems of record where the integration supports it. The goal is to illuminate the dark space between the tools manufacturers already rely on—the black matter.

The stress test

Want to know if your hardware team operates like a modern software team? Try this:

Pick a meaningful engineering change from the last three months. Pretend you just made the change this morning. Now, without asking the project lead, try to figure out exactly what dependencies it triggered. Which work instructions are now obsolete, and what happened to the WIP inventory?

If answering those questions requires scheduling a meeting, pinging three people on Slack, and digging through a spreadsheet, you’ve just found your bottleneck.

Try it in reverse, too. It’s fun. Grab a recent production failure and try to reconstruct its exact history. What was the active revision? The supplier batch? Were there open deviations?

If your product is simple, you might survive on brute force and spreadsheets. But if you’re building complex hardware with parallel changes, that hidden work will eventually bury you, and you will not feel anything like “fun” while doing this test.

We shouldn’t eliminate engineering changes or production failure documentation. Building hardware is hard, and the physical world is unforgiving. But we can eliminate the chaos that follows them.

That’s because “the drawing is updated” just means the engineers committed the code. It should never be mistaken for “the factory is ready.”