Daniel picked up on something from the engraving episode. The military ran durability tests on pigments, figured out which orange survives sunlight, and that data fed into military standards. He wants to zoom out from that and look at the whole world of standard-setting that exists beyond the ISO. Classified military specs, proprietary standards, and organizations that write their own internal compliance standards. His questions: how many major families of standards are actually out there, what threshold defines one, what kinds of organizations develop internal standards and how do they document and update them, and how viable is that internal route compared to just writing SOPs.
The pigment detail is the perfect entry point, because it shows the military running a parallel standards universe with its own lifecycle, its own databases, and its own classification levels. The public sees the output, a spec that says use this orange, but the underlying research that told them which orange survives is restricted. That two-tier structure is the whole story in miniature.
So let's start with the map. How many standard-setting ecosystems are actually out there?
The honest answer is hundreds, and the exact number depends on where you draw the line. The Searle Center on Law, Regulation, and Economic Growth has cataloged standard-setting organizations, and estimates put the number of active SSOs worldwide at over six hundred. That's formal bodies with governance structures, membership rules, and published documents. It doesn't count the proprietary layer or the internal layer.
Six hundred formal bodies. And the ISO is one of them.
The biggest one, but still just one. The landscape breaks into layers. At the top you've got the formal international bodies, ISO, IEC, ITU. Then regional bodies like CEN in Europe, ASTM in the US, which started as a materials testing society and now publishes standards across everything from steel to toys. Then national bodies, ANSI, BSI, DIN. Then government and military standards, which is its own universe. Then industry consortia, IEEE, IETF, W3C, groups that form because the formal bodies are too slow or too generic. And then the proprietary layer, companies whose internal specs become de facto standards because everyone has to interoperate with them.
And then the purely internal layer, which is what Daniel's really asking about.
Right. An organization that decides the external standards don't fit and writes its own. That's the deepest layer, and it's the one most people never see.
The thing about standards is they're not just technical documents. They encode power. Who gets to set the standard decides what the market looks like. The military doesn't just write specs because it likes paperwork. It writes them because it's the largest buyer in the world and it can impose its requirements on every supplier.
And that's the political question underneath all of this. Standards look neutral. A table of pigment durability data looks like chemistry. But the decision about which standards body gets to publish it, whether it's public or classified, whether competitors can read it, that's power being exercised.
Let's go deep on the one we know best from the engraving episode. The military's parallel standards universe.
The scale of it surprised me when I started looking. The Defense Logistics Agency manages something called the ASSIST database, which holds roughly twenty-seven thousand active military standards documents. That's more than the ISO's entire catalog, which is over twenty-five thousand standards. A single national military system is comparable in size to the entire international civilian standards apparatus.
Twenty-seven thousand documents. For one country's defense establishment.
And that's just the active ones. The historical archive is much larger. The lifecycle is formal. Each standard has a preparing activity, which is the military branch or agency responsible for keeping it current. They draft it, it goes through review, and then it gets revised every five to ten years. That cadence mirrors the ISO's periodic review but it's completely independent. The military doesn't wait for the ISO to update a spec on hydraulic fittings. It updates its own.
The five to ten year cycle is interesting. It means some military standards are sitting there for a decade between revisions, which in a fast-moving technology area is an eternity.
And that's a real criticism of the system. The revision cycle was designed for mechanical parts and materials, where the physics doesn't change fast. But when you apply it to electronics or software, you get specs that are obsolete before they're revised. The military has been fighting that problem for decades.
What about the classified piece? Daniel mentioned it, and the engraving episode hinted at it.
Most military standards are actually unclassified and publicly accessible through ASSIST. Anyone can download a spec for a bolt or a paint pigment. That's a misconception worth clearing up. The military isn't hiding its bolt specifications. But a subset is restricted. The durability data on pigments, the research that told them which orange survives sunlight, that may feed into an unclassified spec. The spec says use pigment orange thirty-six. But the underlying research, why thirty-six and not thirty-four, how they tested it, what the failure modes were, that can be classified.
So the public sees the output but not the reasoning.
It's a two-tier system. The spec is public because suppliers need it to bid on contracts. But the knowledge that produced the spec is restricted because it might reveal something about military capabilities or vulnerabilities. If you know which pigments the military uses for desert environments, you might infer something about where they expect to operate.
Or how long they expect equipment to sit in the sun before it gets replaced.
That's the kind of second-order inference that classification is designed to prevent. The spec itself is harmless. The pattern of specs, the priorities they reveal, that's intelligence.
So how many major families of standards are we talking about? Daniel asked for a threshold.
The term is fuzzy, and any threshold is going to be somewhat arbitrary. But a reasonable definition of a major family would be a body that publishes at least a hundred active standards, covers multiple domains, materials, processes, infrastructure, and has a formal governance structure. By that measure, there are perhaps fifty to a hundred major families globally.
Fifty to a hundred. And the fuzziness comes from the nesting.
Right. The ISO is a family. The IEC is a separate family but they cooperate closely. The ITU is another. But then ASTM is a family that overlaps with ISO on materials testing. And the military standards are a family that overlaps with civilian standards on things like fasteners and wiring. Some organizations are nested inside others. ANSI is the US national body but it doesn't write most of the standards it accredits. It delegates to other bodies.
So the map is less a set of distinct families and more a tangled web.
A web with clusters. The formal international cluster, the national cluster, the military cluster, the industry consortium cluster, the proprietary cluster, and the internal cluster. Each has its own logic, its own governance, its own update cadence.
Let's talk about the proprietary layer, because that's where things get interesting. Microsoft file formats, Apple design guidelines, Qualcomm communication protocols.
These are de facto standards. They're not open in the way an ISO standard is open. You can't join a committee and vote on the next version of the Windows file format. But they function as standards because of market dominance. If you want to write software that reads a Word document, you're implementing Microsoft's spec, whether you like it or not.
And those proprietary standards interact with formal standards in complicated ways. Sometimes they're built on top of formal standards, sometimes they compete with them, sometimes they get submitted to a formal body eventually.
The classic pattern is a company develops a proprietary technology, it becomes dominant, and then the company submits it to a standards body to get the legitimacy of an open standard while retaining control through patents or implementation details. Qualcomm's CDMA technology became the basis for cellular standards, but Qualcomm still holds essential patents.
So the proprietary layer is a farm system for the formal layer.
Sometimes. Other times the proprietary standard just stays proprietary forever and everyone works around it. The PDF format was proprietary for years before Adobe opened it up. The Flash format never really opened up, and it eventually died because the web moved to open standards.
But the military isn't the only one writing its own rules. Let's look at what happens when organizations decide to go internal.
This is the practical core of Daniel's question. Who writes their own compliance standards instead of adopting external ones? The answer is organizations where external standards are too generic, too slow, or too public.
Too public is the interesting one.
Aerospace and defense contractors are the obvious case. They have to meet MIL-STDs, but they also have proprietary internal specs that go beyond the military requirements. A contractor might have an internal standard for a manufacturing process that's more precise than the MIL-STD because their own quality requirements are tighter. Or they might have an internal standard for something the military doesn't spec at all, like how to handle a particular material in a particular environment.
Automotive OEMs do this to their suppliers.
Ford's Q1 program is the classic example. Ford doesn't just say meet ISO nine thousand one. They have their own quality standard that suppliers must meet, and it's more demanding than ISO in specific ways. Toyota has its own supplier standards, its own production system requirements. These are internal standards that function as external requirements for anyone who wants to sell to them.
So the internal standard of a big customer becomes the external standard of the supply chain.
That's the mechanism. And it's how standards propagate through industries without ever going through a formal body. A supplier meets Ford's internal standard, then they use that same standard for their other customers because it's easier than maintaining two quality systems. The internal standard leaks outward.
Tech giants are another case. Google's internal coding standards, Apple's design guidelines.
Google's coding standards are interesting because they're public. Google publishes its style guides for C plus plus, Python, Java, and they've become de facto standards for the entire software industry. But they're not maintained by a standards body. They're maintained by Google engineers, updated when Google's needs change. If you're a startup writing Python, you're probably following Google's style guide, and you have no say in how it evolves.
And regulated industries. Pharmaceuticals.
Pharma is a good example because the FDA sets minimum requirements, but companies routinely exceed them with internal standards. A pharmaceutical company might have an internal standard for clean room operations that's stricter than the FDA's current good manufacturing practice requirements. They do that because they know the FDA will eventually catch up, or because their risk tolerance is lower than the regulator's.
So the pattern is: external standards set the floor, internal standards set the ceiling.
Or the internal standard fills a gap the external standard doesn't cover. That's the too generic case. An ISO standard for quality management is deliberately generic because it has to apply to a bakery and a semiconductor fab. A semiconductor fab needs something much more specific.
How do they document these things? What does an internal standard actually look like?
Typically a hierarchical system. At the top you have a standards manual or policy document that says what the organization's standards are and how they're governed. Then domain-specific standards documents, one for manufacturing, one for quality, one for information security. Then work instructions or SOPs that reference the standards. The whole thing is managed in a document control system with versioning and audit trails.
So the internal standard is the what and why, and the SOP is the how.
That's the crucial distinction. A standard says the product must withstand this temperature range, and here's why that matters. An SOP says heat the part to four hundred degrees for two hours, then quench in oil. The standard is the requirement, the SOP is the procedure that satisfies it.
And Daniel's question was about viability. Is writing internal standards a viable route compared to just writing SOPs?
It depends on the organization. Internal standards are viable when you have the resources to maintain them and the domain is specialized enough that external standards don't fit. A machine shop probably doesn't need internal standards. A aerospace contractor absolutely does. The risk is that internal standards become stale, or they're not recognized by customers or regulators, or they require ongoing investment in document control and training that the organization can't sustain.
The stale problem is real. An internal standard that says use revision C of a military spec, and revision D came out three years ago, is worse than no standard at all.
Because it gives you false confidence. You think you're compliant because you're following your internal standard, but your internal standard is wrong. That's the failure pattern.
How do they get written? What's the process?
Usually a cross-functional team drafts them. Engineers, compliance officers, legal. Then a standards committee within the company reviews them. Then management approves them. They borrow language from external standards, ISO, MIL-STD, but tailor it to the organization's specific processes and risk tolerance. The drafting process is slow, because every department wants its concerns reflected.
And the update cycle?
Most internal standards have a review cycle, often annual or biennial. Triggered by regulatory changes, incident investigations, or technology shifts. The military's five to ten year cycle is slow by comparison. Tech companies may update internal standards continuously, every time a problem surfaces.
So the cadence varies enormously. The military is glacial, tech is continuous, and most organizations are somewhere in between.
The cadence reflects the risk profile. A military spec for a hydraulic fitting doesn't need annual review because the fitting hasn't changed in fifty years. A tech company's internal security standard needs continuous review because the threat landscape changes weekly.
The relationship to SOPs is where mature organizations distinguish themselves. The SOP cites the internal standard it implements, and the standard gets updated when SOPs reveal gaps.
That linkage is the sign of a mature system. In an immature organization, the standards and the SOPs drift apart. The standard says one thing, the SOP says another, and nobody notices until there's an audit finding or an incident. In a mature organization, there's a mechanism that keeps them synchronized.
You know, this talk about internal standards reminds me of something that happened at a job I had in the late nineties.
Hilbert: I was a standards coordinator for a defense subcontractor. We made cable assemblies for military aircraft. My job was to track which MIL-STDs applied to our products and make sure our internal drawings referenced the right revisions. It was mostly reading document updates and updating spreadsheets.
Hilbert: The orange pigment incident. Our quality manager had written an internal standard years earlier that said use a specific orange paint for a component. The MIL-STD it was based on had been updated to a new pigment number, and the old one was no longer approved. But our internal standard still said the old number. We painted a batch of parts with the wrong orange. Had to scrap the whole batch.
The internal standard was the problem. It froze the external standard at an old revision.
Hilbert: The internal standard was one line in a forty page quality manual. Nobody read the manual. The quality manager had left two years earlier. The new guy didn't know the standard existed. The paint shop just looked at the drawing, saw a paint number, and used it.
Hilbert: After the scrap, I wrote a new internal standard. It was a single page. It said use the current MIL-STD revision, check ASSIST quarterly, and if the revision changes, update the drawing before the next production run. That was the whole standard.
One page replaced forty.
Hilbert: The one page worked better. Because it didn't try to capture the requirement. It pointed to the source of truth. The military updates the standard, we check the database, we update our drawing. The old manual tried to freeze the requirement at a moment in time, and the moment passed.
That's the difference between a standard that encodes knowledge and a standard that points to knowledge. The forty page manual encoded knowledge, and it went stale. The one page standard pointed to external knowledge, and it stayed current.
Hilbert: The military has twenty-seven thousand standards. What matters is the one that applies to your part on Tuesday. And whether your drawing says the right revision.
Hilbert: I still have the one page standard. It's in a box somewhere. With the old orange paint chip.
The paint chip is a nice touch. A physical artifact of a documentation failure.
What strikes me is that the one page standard worked because it tied the internal requirement to an external source of truth. It didn't try to be self-contained. It said go look at ASSIST, check the revision, update your drawing. The internal standard was a process, not a fact.
And the forty page manual was a fact. A fact that went stale.
That's the risk with internal standards. They want to be self-contained, but the world they're standardizing keeps changing. The only way to keep them current is to tie them to something external that changes in sync.
The pigment orange thirty-six, or whatever the number was, is a tiny example. But the pattern is everywhere. Internal standards that freeze external knowledge go stale. Internal standards that point to external sources stay current.
And the pointing requires a process. Someone has to check the database, compare revisions, update the drawing. That's what Hilbert's job was. Standards coordination. The unglamorous work that keeps the whole system from drifting into scrap.
So where does this leave us on Daniel's question about viability?
Internal standards are viable when the organization is willing to invest in the maintenance. The writing is the easy part. The maintenance is the hard part. If you're not going to check the external sources regularly, don't write the internal standard. Just point to the external standard directly.
If the external standard doesn't cover your situation, that's when you write your own. But you have to accept that you're now responsible for keeping it current, and that's a real cost.
The other piece is that internal standards can diverge. Two companies in the same industry write internal standards for the same process, and they diverge because they have different risk tolerances or different equipment. That's fine internally, but it creates friction in the supply chain. Suppliers have to meet multiple incompatible internal standards.
The proliferation of internal standards creates its own coordination problem.
Which is the irony. Standards are supposed to solve coordination problems. But the proliferation of standard-setting bodies, including internal ones, creates a new coordination problem at the meta level. Which standard do you follow when there are six that apply?
That's the open question. As standards ecosystems proliferate, military, proprietary, internal, is there a risk of fragmentation, or do they converge over time?
Both happen. The ISO and military standards cross-pollinate. Military specs become commercial ones, commercial specs get adopted by the military. But internal standards can diverge indefinitely because there's no external force pushing them to converge. A company's internal standard only has to satisfy the company.
The future implication is about AI. If an AI can read a company's SOPs and incident reports, could it draft an internal standard? Could it keep the standard updated continuously?
That's plausible. The military's five to ten year revision cycle might become obsolete if standards can be updated continuously by systems that monitor changes in external standards and internal incidents. The one page standard that says check ASSIST quarterly could become a script that checks ASSIST daily and flags changes.
The forty page manual could become a living document that updates itself. But then you have the question of who's responsible when the AI gets it wrong.
Same as always. The organization. The standard is only as good as the process that maintains it, whether that process is a person checking a database quarterly or an AI checking it daily.
Standards are a form of collective memory. They encode what an organization or a society has learned about what works. The diversity of standards ecosystems reflects the diversity of human coordination problems. The military needs standards that are durable and sometimes secret. Tech companies need standards that change fast. A machine shop needs standards that are stable. One size doesn't fit all.
The internal standard is the most personal form of that memory. It's what this organization has learned about what works for this organization. It's not meant to be universal. It's meant to be specific.
That's a good place to land. If you've ever wondered who decides what good enough means, in your industry, in your company, or in the military, now you have the map. Next time you see a spec, ask whose standard it is.
Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the one page standard that outlived the forty page manual.
This has been My Weird Prompts, the human AI collaboration podcast. Email us at show at my weird prompts dot com.
We'll be back soon.
