Shared Standards Without a Common Ruler

A standard is not the same as an authority

A standard can be understood broadly as a commonly agreed rule, guideline or characteristic for repeated use. ISO formally connects standards with consensus and common use; its international standards are generally voluntary, although they can become mandatory when legislation, contracts or another regime explicitly requires them.

That distinction is essential for THY-REALITY. A standard does not by itself require authority over the entire system. Two communities can agree that their connectors, data formats, medical reports, transport tickets or quality criteria will be mutually understandable without one community determining all of the other's internal procedures.

The problem begins when a shared interface turns into a universal prescription. If a standard starts prescribing not only the outcome or connection point but every permitted technology, organisational form and internal procedure, a tool for cooperation can become a tool of centralisation.

This article uses four different concepts that are often mixed together. A standard defines a shared requirement or interface. Interoperability means that two different systems can actually exchange data, energy, services or another function on that basis without unnecessary translation or locking the user into one provider.

Conformity assessment checks whether a product, process, service or system really meets defined requirements. Certification is one form of that assessment: ISO defines it as written assurance from an independent body that specified requirements are fulfilled; ISO itself does not issue certificates.

The fourth layer is mutual recognition. Two or more communities can use different laboratories, certification or accreditation bodies yet agree on the conditions under which they accept one another's results. A single global verifier is therefore not necessary for a certificate or test to travel across a boundary.

A common floor, different paths to it

“Education Without One Center: Freedom, Quality, and Common Standards” already established a useful pattern in education: a community can require literacy, safety, certain learning outcomes or another minimum quality level without prescribing one textbook, one provider or one method. This article generalises the same pattern.

A charging standard can define electrical and communication properties of a connector without defining the brand of vehicle. A data standard can define the format and meaning of fields without defining the entire software stack. A medical-device standard can define safety criteria and testing without necessarily defining the producer's organisational form. A good standard standardises the contact point or verifiable result, not the world around it.

This is also the strongest defence against unnecessary uniformity. Communities can retain local solutions, languages, institutions and technologies as long as they meet the agreed requirements at the boundary where cooperation with others occurs.

An open standard has more than one kind of openness

The word open can be misleading because it can refer to several different things. A development process can be open for comments while the final document is paywalled. A document can be freely available while implementation requires a patent licence. A specification can be public while one vendor controls the ecosystem through proprietary extensions.

This article therefore separates at least four questions: who may participate in development; who may read the specification; under what licensing terms it can be implemented; and whether multiple independent interoperable implementations exist. W3C is a useful example of a strongly open model: public review, consensus, standards available at no cost, royalty-free patent commitments and interoperability testing.

ISO represents a different model: consensus-based and generally voluntary international standards, while many full documents are purchased and protected by copyright. The label 'international standard' therefore does not by itself tell us how open the system is across all four dimensions.

When a standard links many autonomous units, the way it is produced matters. The WTO's principles for international standardisation emphasise transparency, openness, impartiality and consensus, effectiveness and relevance, and coherence. The aim is to reduce the chance that a standard privileges one supplier, country or interest group.

The IETF provides an interesting technical example with the idea of rough consensus and running code. Its discussion of consensus warns that standardisation is not merely counting votes: a significant technical objection must actually be addressed even when held by a minority, and the resulting solution should survive contact with implementation.

For communities the lesson is simple: a standard should not exist merely because the largest member has the most votes or money. Drafts should be published, objections given time, reasons recorded, implementations tested and appeals or revisions possible.

Interoperability is most convincing when multiple independent implementations prove it

A paper specification does not prove that systems really work together. W3C therefore explicitly includes implementation experience and interoperability testing among the strengths of its process. That is an important methodological correction: a standard should be testable at real contact points between independent implementers.

A smaller network does not need a huge laboratory for this. It can use a public test suite, reference examples, a shared demonstration event or several independent implementations proving that the system is not secretly dependent on one software library, manufacturer or central server.

If a standard can only be used successfully with the product of the company that wrote it, we may have a specification for that company's ecosystem rather than genuine interoperability.

Certification without a single certification monopoly

Certification is useful when users cannot personally verify every technical property of a product or service. But if only one organisation is allowed to confirm conformity and participation is impossible without its seal, the certification layer can become a new point of political or economic dependence.

ISO's separation of roles is therefore useful: ISO develops standards but does not issue certificates. Conformity can be assessed by independent third parties, while an accreditation system can assess their competence. This creates layers of trust without requiring the same body to write the rule, sell the certificate, assess itself and hear the appeal.

For THY-REALITY a sensible principle is functional separation: the body writing the standard should not automatically be the only permitted certifier; certifiers should themselves be reviewable; and lower-risk domains should allow lighter evidence such as supplier declarations, peer review or other proportionate forms of conformity assessment.

Mutual recognition: multiple verifiers, one accepted result

The international accreditation system provides a practical example of avoiding one global laboratory. Global Accreditation Cooperation Incorporated, which took over the former roles of IAF and ILAC in 2026, operates a Multilateral Recognition Arrangement intended to support cross-border acceptance of accredited conformity-assessment results.

The principle also works at smaller scale: we do not need the same verifier; we need confidence in comparably competent verifiers. Communities can agree on criteria for laboratories or certification bodies, peer evaluation and which results they accept automatically.

This reduces duplicate testing and cost while preserving multiple providers. Mutual recognition is therefore a kind of interoperability of trust: different institutions remain different, but their results can travel through a shared network.

Power-check: a standard can become a gate through which someone controls a market

Awakening to Natural Law notes a dual character of standardisation in the context of interoperability: technical compatibility can be genuinely useful while becoming entangled with economic dependence. This article turns this into a general power-check rather than relying on a single sectoral example.

We should ask who sits on the committee; who can fund long development cycles; whether patents are embedded in the standard; what documentation and testing cost; whether requirements disproportionately burden small providers; whether the certifier also sells consultancy; whether competing implementations are practical; and whether legislation or contracts turn a voluntary agreement into a mandatory gate to the market.

A standard can reduce monopoly by enabling supplier substitution. It can also entrench monopoly when written around an incumbent product, when implementation is too expensive for entrants, or when certification is practically accessible only to large actors. Standardisation therefore needs its own concentration-of-power audit.

Versions, backward compatibility and the right to leave

A standard is not finished forever. Technology, risks and needs change, so there must be a versioning process. Yet rapid change can force all existing users into costly upgrades, while complete immobility can freeze a poor solution.

A good network therefore defines transition periods, backward compatibility, version labels and when an old version will no longer be supported. Where possible, data should remain portable and a member should be able to change providers without losing its records or entire infrastructure.

This is the technical form of “Exit, Voice, and Loyalty: What Do We Do When a System Fails?”: the right to exit is real only when a standard does not turn a user's data, connectors or credentials into a hostage of one system.

A practical audit of a shared standard

Before several communities, firms or institutions adopt a shared standard, they can use the following audit:

1. What interoperability problem are we actually solving? 2. What is the smallest shared interface or outcome that must be standardised? 3. What can deliberately remain different? 4. Who can participate in development and who can object? 5. Is the specification accessible enough for independent implementation? 6. Do licences, patents, membership fees or testing costs create an unnecessary barrier? 7. How will we demonstrate interoperability with at least two independent implementations? 8. Who assesses conformity, and who assesses the assessor? 9. Can we accept another competent assessor's result instead of repeating the same test? 10. How can the standard be changed, withdrawn or replaced without trapping users in one solution?

Without answers, a standard may increase order while creating a new invisible dependence. With clear answers, a shared standard becomes the opposite: infrastructure for choice, because it lets different systems cooperate without complete uniformity.

“How Can Communities Cooperate Without a Single Center?” showed that communities can cooperate through agreements, consortia, federative bodies and polycentric networks. This article adds the technical and institutional language that lets such a network function: standards, interoperability, conformity assessment and mutual recognition.

The healthiest standardisation is therefore not the one that makes everything identical. It is the one that defines contact points precisely enough for different systems to cooperate while limiting its own mandate enough for diversity inside those systems to remain possible.

“Trade and Supply Chains: Mutual Benefit or a New Dependency?” will test this in a harder environment: trade and supply chains. Once shared standards make exchange possible, a new question appears — does specialisation and trade create mutual benefit, or a new form of dependence?