We built 500 parts to the wrong spec: the stale-revision tax

"The guy at the desk is looking at a drawing from March, and the customer is sending a revision from June. Nobody updates the file, and we build 500 parts to the wrong spec."

That's Tom Krause, running a 120-person fabrication shop in Wichita, in a trade interview on order-entry errors — five family-owned fab shops talking about what actually caps their output. The answer wasn't welding speed or machine time. It was the front-office paper trail.

The failure mode is always the same

A customer emails a revised PDF. It lands in someone's inbox. The traveler never updates. The BOM never updates. The shop builds the stale revision.

The numbers from those five shops, in their own words:

• 500 parts built to the wrong spec — the worst single event.
• $40,000 — the cost of one mistake.
• ~$180,000 in labor and material recovered by one shop — through manual discipline, not tooling.
• 11 → 4 revision errors per half — by requiring every revision to be logged in a shared spreadsheet before work begins.

Read that last one again. A spreadsheet that every revision must pass through before work starts — logged by a human, checked by a human. That's a merge gate. Built by hand, in a spreadsheet, because nothing else was enforcing it.

It's the same disease at every layer

This is not a "fab shop problem." It's a revision-propagation problem, and it shows up everywhere hardware moves between hands:

• Stale BOMs. One team extracted BOMs from PDFs by hand — four engineers, six 40-hour weeks — and "each revision [was] almost like a restart… requiring a manual update of anything connected with the project."
• Stale datasheets. An AI agent for electronics support answered the max operating temperature of an STM32F407 from a discontinued datasheet revision — 85°C instead of the current industrial spec of 105°C. Same failure: the old revision was reachable, so it won.
• Stale board state. ECO-drift between schematic and PCB — the board was fabricated from an earlier schematic revision and a later edit broke the merge. Caught, if at all, by someone hand-building drift detection into their own tooling.

Different layers, identical structure: a revision exists somewhere, it doesn't propagate, someone builds on the old one. The cost is denominated in dollars and weeks, and it's always silent until it isn't.

The workaround is a person

Look at what the fab shops actually did. Krause put his estimators on the shop floor one day a month — rework dropped ~40%. Another shop physically moved quoting next to engineering so revisions get caught desk-to-desk instead of inbox-to-inbox.

Every one of these workarounds is a human being acting as the propagation layer. A person walks the revision from the inbox to the traveler. A person checks the spreadsheet before the shift starts. It works — $180k recovered proves it works. But it doesn't scale, it doesn't run on weekends, and it fails the first time someone is on vacation.

The pattern that works — one shared change thread, every revision bound to the active configuration, release blocked until the owning station acknowledges it — is exactly the merge gate. The fab shops invented it in spreadsheets. The industry needs it as infrastructure.

What this means for your stack

If your engineering change process depends on a person noticing that the file changed, you have the same exposure as the shop that built 500 parts to the wrong spec. The fix isn't "be more careful." The fix is: every revision enters through one gate, the gate binds it to everything it affects, and nothing downstream moves until the change is acknowledged against the current revision.

That's the whole argument for an orchestration layer above the systems of record. The spreadsheet version works at 120 people and one shop. It doesn't work across ECAD, MCAD, PLM, and a contract manufacturer.

---

The fab-shop interviews quoted here are from "Order entry errors, not welding speed, cap output at mid-sized shops" (Industrious Insights). The STM32F407 stale-datasheet case is from Rapidflare's eval write-up.