Open Standards Are Broken for the AI Age. Here’s How We Fix Them.

The framework that defined “open” for 20 years needs four new principles. Amir Hameed Mir explains why.

The Promise That Built the Internet

The internet works because of a miracle we’ve collectively forgotten to appreciate.

A server in Bangalore can communicate with a browser in Buenos Aires. A sensor made in Shenzhen can plug into a network built in Stockholm. An app written by a teenager in Nairobi can run on a phone designed in Cupertino. This is not capitalism. This is not innovation. This is open standards — the quiet, boring, utterly essential agreements that make communication possible between things made by people who will never meet.

For twenty years, the definitive answer to the question “What does ‘open’ actually mean?” has been a framework developed by Ken Krechmer. His ten requirements, published in 2005, decompose the fuzzy concept of openness into ten distinct, measurable criteria. They address the needs of standards creators (those who write the specs), implementers (those who build products), and users (those who depend on those products).

Krechmer’s framework is rigorous, it is elegant, and it is increasingly inadequate.

I know this because I am building a deep-tech company in a place that the global technology industry does not see as a technology place. Sirraya Labs operates from Srinagar, in the Kashmir Valley — a region known for its mountains, its crafts, its conflicts, and decidedly not its code. If we are to build technology that competes globally, we cannot rely on brand power, incumbency, or geographic privilege. We can only rely on the genuine openness of the systems we build upon.

And in 2026, those systems have changed in ways that Krechmer could not have anticipated.

The Three Stakeholders and Why They Matter

Before I explain what’s broken, let me explain why Krechmer’s framework matters.

The insight at its core is that “open” means completely different things depending on who you are in the ecosystem. This is not a matter of opinion. It is a matter of economic survival.

The Creator — typically a standards-setting organization or the engineers who volunteer within it — needs open meetings, consensus-based decision making, due process for appeals, and the goal of a single worldwide standard. Without these, the standard lacks legitimacy.

The Implementer — the company building products — needs something entirely different. They need fair intellectual property terms (ideally royalty-free), a stable standard that doesn’t change capriciously, clear documentation, and interfaces that don’t secretly favor a competitor. A standard that is procedurally open but economically predatory is worse than a closed standard; it’s a trap.

The User — the person or organization depending on the standardized product — needs yet another set of guarantees. Multiple sources of supply (no single vendor lock-in), access regardless of location or disability, backward compatibility so their investments aren’t destroyed, and long-term support.

Krechmer’s genius was recognizing that all three perspectives are valid and that a truly open standard must satisfy all of them. His ten requirements map cleanly onto these stakeholder categories. Requirements 1–4 serve creators. Requirements 5–8 serve implementers. Requirements 9–10 serve users.

The problem is that the world has changed.

Four Transformations the Framework Never Anticipated

Krechmer published his framework in 2005. To understand how much the world has changed since then, consider: the iPhone did not exist. Deep learning was an academic curiosity. Cloud computing was called “utility computing” and was mostly aspirational. The phrase “foundation model” would have been incomprehensible. And the idea that technical standards would become instruments of explicit geopolitical competition would have seemed paranoid.

Today, four transformations have fundamentally altered what “openness” must mean.

Transformation 1: Standards now embed opaque intelligence.

When a modern standard specifies how a network should route traffic, or how a security system should detect threats, or how a codec should compress video, it increasingly recommends or mandates machine learning components. These components make decisions that affect interoperability, performance, and security. But how they make those decisions is opaque — not just to users, but often to the implementers who embed them.

This is structurally new. A proprietary API is a known opacity; you know the vendor controls it and you can make economic decisions accordingly. An AI component mandated by an “open” standard is an unacknowledged opacity. The standard says it’s open. Your implementation is compliant. And yet there is a black box at the center of your system whose behavior you cannot explain, debug, or contest.

Transformation 2: Data has become inseparable from standards.

Krechmer’s Requirement 5 — Open IPR — addresses the patents and copyrights associated with the standard itself. It asks whether implementers must pay royalties to use the standard. This was sufficient when standards were documents that described interfaces.

But modern standards — in AI, in IoT, in healthcare — are increasingly about data. A standard for federated learning specifies how training data is aggregated. A standard for smart meters specifies what consumption data is collected and how it flows. The IPR framework that governs the standard’s interfaces says nothing about who owns the training data, who controls the model weights, or who can access the inferences generated by the system.

This creates a new form of enclosure. A standards body can claim perfect openness under the original ten requirements while the standard itself creates architectures that siphon data from users to platform operators. The standard is open. The data extraction it enables is not governed at all.

Transformation 3: Standards have environmental costs that no one accounts for.

Standards are not environmentally neutral. A standard that mandates specific cryptographic primitives or consensus mechanisms imposes computational costs that translate directly into energy consumption. These costs are distributed globally — every implementer incurs them, every user pays for them in electricity and carbon — while the benefits may accrue narrowly.

This is a classic economic externality, and it belongs in the openness framework because it is a hidden cost. A standard whose implementation degrades the environmental commons is imposing an unacknowledged burden on users and non-users alike. That burden is antithetical to the spirit of open access.

Transformation 4: Standards have become geopolitical weapons.

The 2020s settled any doubt about whether technical standards could be politicized. The battle over Huawei’s role in 5G standards. US export controls on semiconductor equipment specifications. The emergence of competing Chinese and Western technology stacks. The quiet insertion of national security requirements into ostensibly international specifications.

When a standard contains a mechanism that requires trust in a specific nation-state’s certification authority, it is not a global standard. It is an instrument of jurisdictional control, dressed in the language of interoperability. A firm like ours — operating from a geopolitically sensitive region — cannot afford to be an unwitting vector for any state’s backdoor, nor to be locked out of markets because we cannot obtain certifications from a particular jurisdiction.

The Four New Requirements

The Krechmer framework remains the best tool we have for analyzing openness. It does not need to be replaced. It needs to be extended. I propose four new requirements, numbered 11 through 14 in continuity with the original ten.

Requirement 11: Algorithmic Transparency

Any standard that mandates, recommends, or permits the use of algorithmic decision-making systems shall specify explainability and auditability requirements sufficient to allow implementers and users to understand the logic by which decisions affecting interoperability, security, or functionality are made.

This is not a vague call for “ethical AI.” It is a specific, structural requirement. If a standard says “use a neural network for congestion prediction,” it must also say how an implementer can verify that the neural network is making reasonable decisions. If it cannot specify this, the standard should not mandate the opaque component.

This matters practically. An implementer who cannot inspect the decision boundaries of a standardized AI component cannot debug it, cannot optimize it for their specific deployment, and cannot explain to their customers why it behaves as it does. That implementer is not building on an open standard. They are renting opacity from whoever trained the model.

Requirement 12: Open Data Governance

Any standard that specifies data formats, collection methodologies, processing pipelines, or training procedures shall include governance provisions specifying ownership and control rights over data generated or processed under the standard.

This extends the royalty-free principle from software interfaces to data. If a standard creates an architecture that generates valuable data, the standard must specify who controls that data and under what terms. Training datasets necessary for implementation should be available under RAND or royalty-free terms, just as essential patents should be.

The alternative is a world where standards are “open” but the data assets they generate are concentrated in the hands of a few platform operators who happened to dominate the relevant working group. That is not openness. It is enclosure by another name.

Requirement 13: Environmental Accountability

Standards-setting organizations shall publish lifecycle environmental impact assessments for any new or revised standard whose implementation is reasonably expected to result in significant computational, energy, or material resource consumption.

This is the most straightforward of the four requirements. Before mandating a computationally intensive approach, an SSO should ask: is there a less intensive alternative that achieves the same goal? If not, have we accounted for the global environmental cost of our design choice?

This is not radical. It is basic cost accounting, extended to the commons.

Requirement 14: Sovereignty and Security Openness

Open standards shall not permit mechanisms for undisclosed government or third-party access to implementations. Standards shall provide sovereignty-neutral implementation paths that do not depend on trust in any single jurisdiction’s certification, key management, or trust infrastructure.

This requirement has two components. The first — no backdoors — is already established as a design principle (IETF BCP 188: “Pervasive Monitoring Is an Attack”). What is new is elevating it from a design principle to a conformance requirement. A standard that permits undisclosed access mechanisms is not open, full stop.

The second component — sovereignty neutrality — is more subtle. It does not mean standards must ignore national security requirements. It means they must disclose those requirements and, where possible, provide technical alternatives that eliminate the need for jurisdictional trust. A firm in Kashmir should not need the trust infrastructure of Beijing or Washington to implement a standard securely.

No One Meets These Requirements Today

The most sobering finding of our analysis is that no standards-setting organization — not the IETF, not W3C, not ISO, not IEEE — adequately addresses any of these four new dimensions. We evaluated the major SSOs using Krechmer’s scoring methodology (0–4 scale) extended to the new requirements.

The IETF, which scores highest on the original framework, achieves only 2 out of 16 possible points on the new dimensions — and that is entirely due to BCP 188’s contribution to R14. No SSO scores above zero on Open Data Governance. The gap is not marginal; it is categorical.

What This Means for Builders Outside the Centers of Power

I want to be clear about why this matters from where I sit.

Sirraya Labs is building deep technology in Kashmir. We do not have the lobbying power to shape standards in our interests. We do not have the legal budgets to negotiate patent pools. We do not have the geographic proximity to participate in every working group meeting in Geneva or Silicon Valley.

What we have — what we must have — is the genuine openness of the standards we build upon. If the standards are truly open, our location is irrelevant. Our code will interoperate. Our products will compete. Our users will be served.

But if “open” means procedurally open creation while the standard embeds opaque AI, extracts ungoverned data, externalizes environmental costs, and serves as a vector for jurisdictional control — then “open” is just a marketing slogan, and we are locked out regardless of what the specification says.

This is not abstract. Every design decision in our products begins with the question: which standards do we depend on, and what does their “openness” actually guarantee? The original Krechmer framework helps us answer that question for the interface layer. The extended framework helps us answer it for the intelligence layer, the data layer, the environmental layer, and the sovereignty layer.

The Pashmina Standard

In Kashmir, we have a tradition of Pashmina weaving that spans centuries. A genuine Pashmina shawl is defined not just by its materials or its patterns but by the integrity of its entire creation process — the provenance of the wool, the transparency of the supply chain, the skill of the weavers, the promise that it will last for generations.

I think about open standards the same way.

A standard that is open at creation but closed at implementation is like a shawl woven from genuine wool but dyed with toxic chemicals — it looks right but poisons the wearer. A standard that is open at creation and implementation but ignores data governance is like a shawl whose pattern is beautiful but whose wool was stolen from the herder. A standard that is procedurally perfect but contains a sovereignty backdoor is like a shawl with a hidden thread that someone else can pull to unravel the whole thing.

Genuine openness, like genuine craft, requires integrity at every layer. The original ten requirements addressed the layers visible in 2005. The four new requirements address the layers that have become visible since. Together, they define what I call the Pashmina Standard: a standard so thoroughly open that it can be trusted from any vantage point, by any builder, in any jurisdiction, for any user.

What Comes Next

This framework is a proposal, not a final word. The quantification levels we’ve suggested for Requirements 11–14 need validation through multi-stakeholder review. The scoring of SSOs on these new dimensions needs refinement through participant observation, not just documentation analysis. There may be additional dimensions — quantum computing, brain-computer interfaces, synthetic biology — that will require their own extensions in the years ahead.

But the direction is clear. The era of standards as purely interface specifications is over. The era of standards as socio-technical-economic-political agreements is here. Our frameworks for evaluating openness must evolve accordingly.

If you are a standards creator: look at your working group charters. Do they address algorithmic transparency? Data governance? Environmental impact? Sovereignty neutrality? If not, why not?

If you are an implementer: look at the standards you depend on. Do you understand the AI components they embed? Do you know who controls the data they generate? Are you comfortable with the jurisdictional trust assumptions they require?

If you are a user: ask your vendors which standards their products implement, and what “open” means in each case. The answer should not be one word. It should be a matrix.

The question, as Ken Krechmer wrote in 2005 and as I repeat in 2026, is not “Is this an open standard?” The correct question is: “Which of the fourteen openness requirements does this standard and its governing body satisfy — and for which stakeholders?”

Anything less is not a standard. It’s a story someone is telling you. And from where I sit, in a valley far from Silicon Valley, stories are not enough. We need the real thing.

Sirraya Labs is a deep-tech company based in Srinagar, Kashmir, building infrastructure for the algorithmic age. We believe that genuine openness is the only competitive advantage available to builders outside the centers of power, and we are committed to advancing open standards at every layer of the stack — from interfaces to intelligence, from data to sovereignty.

*The extended Krechmer framework presented here is based on original work by Ken Krechmer (2005, 2009) and our own analysis of standards-setting organizations in 2026. A full academic paper with detailed methodology, citation trail, and SSO evaluation is available from the authors.