Standards Take Too Long

Every proposal to coordinate an industry eventually runs into the same weary objection from the people who have actually tried it: standards take too long. They are describing something real. A shared way to describe a work package, verify a supplier, and move a request between firms sounds like a standards effort, and standards efforts in manufacturing are measured in decades rather than quarters. The veteran has watched committees deliberate for years while the problem sat there getting worse, and concludes that a coordination layer is a generation away. I think the urgency is exactly right and the conclusion is exactly wrong. A fix that lands in 2045 is not a fix. Claim: a coordination layer does not need a finished industry standard, it needs a minimal protocol that delivers value on day one — the work-package minimums and the verification basics — and then grows with adoption; the comprehensive, anticipatory standard reliably loses to running code, and waiting for one is not caution, it is surrender.

The word doing the damage in that objection is "standard." A standard tries to specify everything before anyone uses it. A protocol specifies the minimum two parties need to transact, ships, and gets better in the field. Nobody has to standardize all of manufacturing to route one job.

The objection at its strongest

The timelines are real and they are brutal. STEP, the ISO 10303 standard for exchanging product model data, began development in 1984 and did not publish its initial international-standard release until 1994 and 1995, and it has kept expanding ever since into roughly seven hundred constituent parts. ISO's own process puts each deliverable on an eighteen-, twenty-four-, or thirty-six-month track before you count a single hour of real-world committee delay. EDI's ASC X12 committee was chartered in 1979 and has since produced more than three hundred transaction sets, a standardization effort now in its fifth decade and still growing. Anyone who has lived inside those clocks has earned their pessimism honestly. What they are wrong about is how much of a standard a coordination layer actually needs, which turns out to be far less than they assume.

You do not have to define everything to route anything

That is the error in one sentence, and MTConnect is the counterexample I keep coming back to. The manufacturing data standard released in 2008 deliberately declined to define every possible piece of data a machine could emit, and instead worked forward from real business and research objectives to specify only the elements needed to meet them. That is the posture. A minimum viable work package with hard gates and soft fields — revision lock and identity required, finish and inspection allowed to be marked unknown with a priced assumption — beats a complete schema nobody has finished writing. The web was built this way. Tim Berners-Lee's original 1991 HTTP was, in his own note, "a subset of the full HTTP protocol," shipped alongside the promise that "future HTTP protocols will be back-compatible." JSON beat the much heavier XML by being, in the words of its own specification, "minimal, portable, textual," and it was standardized in stages across 2006, 2014, and 2017 while people were already running it in production.

What happened to the standard that tried to do everything

The most expensive proof of this thesis is the one that lost anyway. Through the 1980s the telecommunications and computing establishment, governments included, built the OSI networking suite as the comprehensive, correct successor to a fragmented world. It collapsed, the historian Andrew Russell records, "in the face of a cheap and agile, if less comprehensive, alternative: the Internet's Transmission Control Protocol and Internet Protocol," because "the bureaucratic procedures used to structure the discussions didn't allow for the speedy production of standards." OSI is now often portrayed as the cautionary tale of overbureaucratized anticipatory standardization — a framing Russell himself handles more carefully than most of the people who quote him, and the careful version is the useful one. Richard Gabriel gave the operative principle its name in 1991: "It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing." Running code beats a perfect specification nobody can finish.

The governed design

A governed coordination layer ships the minimum and iterates in public. Standardize the work-package basics and the verification floor first — the fields without which a quote is meaningless, the identity checks without which trust is impossible — and let everything richer stay optional and additive: deeper PMI, fuller cert taxonomies, whatever the next hard industry brings with it. Keep the fallbacks for the messy tail, because a protocol that breaks on imperfect input is worse than the email it was supposed to replace. And expand backward-compatibly, so that adopting version 0.9 is never punished by version 1.0. That last one is not a technical nicety; it is the entire reason anyone is willing to go first. The control point is that the protocol delivers value before it is complete, which is the only kind of standard that has ever gotten adopted.

Operational test

The test is the adoption curve, and it is unforgiving. Does the minimal protocol let a real buyer and a real supplier complete a real transaction today, at version 0.9, without waiting on a committee? Is usage growing before the specification is finished? Do expansions ship without breaking the integrations that already work? If nothing functions until everything is specified, the effort has quietly become the anticipatory standard that history buries. If value shows up at the minimum and compounds from there, you are growing a standard rather than waiting for one.

Implications

If coordination waits for a finished standard, the critic is right, and the waiting itself hands the field to whoever is willing to ship something imperfect and fix it in the open. Start from a minimal protocol and the decade-long timeline stops being a barrier at all, because adoption and refinement happen at the same time instead of in sequence. No country gets to schedule its reindustrialization around a committee calendar while its supply chains fail in the present tense. The practical failure mode here is paralysis wearing the costume of rigor. The last objection in the series is the bluntest one, and it usually comes from an engineer who has personally watched an ambitious coordination project die: forget the law and forget the standards bodies, this is simply too hard to build.

Questions to Ask

1. What is the smallest protocol that lets one real buyer and one real supplier transact today?
2. Which fields are hard gates, and which can be marked unknown and priced as assumptions?
3. Does the system deliver value before the specification is complete?
4. When input is imperfect, does the protocol fall back gracefully or break?
5. Can we expand the protocol without breaking what already works?
6. Are we growing a standard through use, or waiting for one to be finished?