Whose standard is it anyway?
Most conversations about standards focus on the technical specification. Which fields. Which signatures. Which file format. Almost nobody asks the question that determines whether a standard will still mean what it says in five years.
Who owns it?
A specification is a static document. Governance is the live process that decides what the specification means tomorrow, who is allowed to implement it, what happens when the sponsor's commercial interests diverge from the community's, and who can be cut off from the registry on a Monday morning. The technical detail can be excellent and the governance can still be broken. When that happens, the people who built on the standard discover, often too late, that they were building on someone else's business model.
Records provenance, the layer MX addresses, is too important to belong to vendors whose products generate the records. This post is the argument for why.
The principle
A standard that determines whose content is trusted should not be controlled by anyone who profits from generating that content. The conflict of interest is structural, not personal. Decent sponsors do not change the equation, and an open specification does not change the equation. If the body that ratifies the standard is also a market participant in the layer above or below the standard, the standard will eventually bend toward the sponsor's interests. Sometimes slowly. Sometimes in a single keynote.
A case from the last eighteen months shows the shape of the problem.
The case: WordPress and the kill switch
WordPress powers somewhere around 43% of the web. The plugin directory at WordPress.org is the supply chain that keeps those sites secure and functional. WordPress is open source. The WordPress trademark is owned by the WordPress Foundation. The WordPress.org domain, the actual distribution infrastructure, is owned personally by Matt Mullenweg, co-founder of WordPress and CEO of Automattic.
In September 2024 Mullenweg used a keynote at WordCamp US to complain that competitor WP Engine was not contributing enough to the WordPress ecosystem. Within weeks, WP Engine's access to WordPress.org was blocked. The Advanced Custom Fields plugin, owned by WP Engine and used by hundreds of thousands of sites, had its slug taken over by an Automattic-controlled fork. A US court granted WP Engine a preliminary injunction in December 2024 forcing the restoration of access and ownership.
A group of WordPress contributors then asked Mullenweg to propose community-minded governance reforms. Mullenweg responded by deactivating their WordPress.org accounts.
The technical specification of WordPress did not change during any of this. The governance did, in public, in real time. Enterprise legal teams started phoning agency CEOs to ask whether WordPress was still a defensible platform choice. Karim Marucchi, CEO of Crowd Favorite, later said the question they put to him was direct: why should we trust WordPress if one person can unilaterally make changes that put our supply chain at risk, with no apparent checks and balances?
There was no answer.
The structural failure modes
The WordPress story is one shape of governance failure, but it is not the only shape. Patterns recur across the standards bodies in this space, and they are worth naming directly so buyers know what to look for.
Capture by infrastructure ownership. The specification is open, but the domain, the registry, the certificate authority, or the directory service is owned by a single party. The WordPress.org pattern. It looks fine until the owner decides it isn't.
Capture by sponsor concentration. The specification is governed by a coalition, but the coalition is dominated by vendors with commercial interests in adjacent products. It works while the sponsors agree, and produces stalemates or unilateral extensions when they don't.
Capture by founder dependency. The specification is excellent, but the project depends on a small group of founders who can be politically exhausted, commercially co-opted, or simply move on. Independent foundation governance helps, but it is not a guarantee.
A buyer evaluating a standard should ask, in order: who owns the infrastructure the standard runs on, who funds the governance body, and what happens to the standard if the founders leave. If the answers are uncomfortable, the standard is not as independent as the marketing claims.
How MX is governed
MX is structured to fail differently.
The standard, COG (the Community Owned Governance Standard), is open. The format is Markdown, YAML, and HTML. No proprietary container. No required toolchain. A publisher with a text editor and a static host can produce a compliant record.
The registry protocol, REGINALD, is open. Anyone can run a REGINALD instance. The Gathering operates a public registry. Enterprises run private registries behind their own firewalls. Closed-network and air-gapped REGINALD deployments are explicitly supported at Level 5 of the MX market chain, because regulated industries cannot send signed records to a public service.
The standards body, The Gathering Administration Ltd, is an independent UK company whose sole purpose is to govern the MX standard. The Gathering does not sell consultancy, does not sell tooling, does not sell hosting, and does not certify implementations it has commercial stakes in. Implementation work happens elsewhere, including in my own firm; the boundary between standards body and market participant is structural, not aspirational.
The signing primitive, Ed25519 over canonical bytes, is the same cryptography modern signing standards use generally. Standards differ from each other in their governance, not in their mathematics.
The identity layer, did:web by default, distributes trust rather than concentrating it. Each publisher hosts their own DID document on their own domain; resolution uses DNS and HTTPS that already run everywhere. A publisher with sloppy ops is genuinely less trustworthy than they would be under a shared directory, and that cost has to be named honestly. Failure modes are local rather than global, and the dependencies are public, checkable with any standard library, and documented by IETF and the CA/Browser Forum. When a deployment needs a stronger binding from DID to legal entity, W3C Verifiable Credentials sit on top of the base protocol.
None of this makes MX immune to the failure modes above. A standards body can still be captured. Infrastructure can still concentrate. Founders can still leave. What it does mean is that the design choices have been made with the failure modes in mind, rather than discovered after the dispute starts.
The test
The useful question for anyone evaluating an open standard is not "is the specification good?" The specification is almost always good. The useful questions are these.
If the sponsor went bankrupt tomorrow, would the standard survive?
If the sponsor's commercial interests shifted, would the standard bend?
If the registry operator decided to block a participant, would the participant have recourse?
If the answers are not clearly yes, yes, and yes, the standard is something other than what its marketing says it is. Use it anyway if it earns its keep, but understand what you are buying and price the governance risk into the decision.
The CMS industry is currently learning this lesson the expensive way. The institutions that learn it first will be the ones whose content infrastructure is still working when the next dispute starts.