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.
Three cases from the last eighteen months show the shape of the problem. A fourth, closer to my own daily work, shows what happens when the gap is left unfilled.
Case one: 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.
Case two: FAIR, and the limits of forking governance
The response was the FAIR Package Manager (Federated and Independent Repositories), launched at WordCamp Europe in June 2025 under Linux Foundation governance, with Carrie Dils, Mika Epstein, and Ryan McCue on the technical steering committee. FAIR's premise is exactly the one MX rests on: federated repositories, cryptographic identity using Ed25519 signatures, and an independent body holding the standard. Joost de Valk, who led much of the work, described it as solving a political problem with code.
The technical work succeeded. The political adoption did not.
By March 2026 de Valk wrote candidly that hosting companies would not invest in FAIR because the governance dispute that created demand for it had cooled, and taking sides was no longer commercially attractive. FAIR became, in his words, aspirational rather than actionable for WordPress. The project has now pivoted to TYPO3, the German enterprise CMS, an ecosystem that wants federated distribution as a technical property rather than as a protest vote.
Two lessons here. The first is that you cannot retrofit independent governance onto an ecosystem already dependent on a single party's infrastructure. The window for that closes the moment the dependency is established. The second is that a well-designed standard with neutral governance does find a home, even if it is not the home its founders originally intended. The technical work survives the political moment.
A structural footnote, while we are here. FAIR's identity layer uses did:plc, the same DID method as Bluesky, which resolves through plc.directory, a global directory operated by a single company. A project built to remove single points of failure routes its identity verification through one. This is not a criticism of FAIR's team; it is an honest engineering trade-off acknowledged in their own writing. The example still illustrates how hard truly independent infrastructure is to build, and why naming the dependency openly matters more than pretending it does not exist. REGINALD goes the other way: did:web by default, so each publisher's keys resolve through their own domain over DNS and HTTPS rather than through a shared directory.
Case three: C2PA and the coalition model
C2PA emerged from two Adobe and Microsoft-led initiatives, the Content Authenticity Initiative and Project Origin, merged in 2021 under the Joint Development Foundation. Steering committee membership is tiered. Membership fees apply. Adobe ships C2PA Content Credentials inside Photoshop, Lightroom, Firefly, and Adobe Express. The standard is technically open and well-engineered.
It is also, structurally, a coalition of large vendors whose commercial interests are tightly bound up with what the standard does. Adobe wants provenance because Adobe sells the tools that generate the assets. Microsoft wants provenance because Microsoft is building Copilot. The BBC wants provenance because the BBC is being attacked with deepfakes. These are aligned interests today. They may not be aligned in five years.
A coalition standard is better than a single-vendor standard. It is not the same thing as an independent standard. The difference shows up the moment the coalition members' interests diverge: over which formats are supported, which AI tools are blessed as "trustworthy generators", whose certificate authority is approved, what counts as a valid edit. None of this is hypothetical. It is the normal life of any multi-vendor standards body, and the only protection is governance that is not itself a market participant.
C2PA does its job. The job it does is bounded by who funds it.
Case four: Adobe Experience Manager, the elephant in my own room
I have worked with AEM for twelve years. I architected the world's largest AEM deployment, for the Renault-Nissan Alliance. This is not an anti-Adobe argument; it is a pro-clarity one, about what Adobe sells and what Adobe does not sell.
Adobe sells Content Credentials for media. Adobe does not sell a provenance layer for the pages an AEM author publishes. There is no native C2PA story for the body copy on a product page, the fee schedule on a banking site, or the terms a chatbot relays back to a customer. This is not because Adobe is incapable; it is because that layer is not where Adobe's revenue lives, and standards bodies tend to address the layers where the sponsors' revenue lives.
The records gap is real inside Adobe's own portfolio. Adobe customers will eventually need a records-provenance answer. That answer will come from somewhere. The question is whether it comes from a body whose interests are aligned with publishers, or from a body whose interests are aligned with vendors whose tools generate the records being attested. Those are different bodies. They produce different standards.
The structural failure modes
Three patterns recur across these cases. 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. This is 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. This is the C2PA pattern. 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. This is the risk FAIR ran, and which Joost de Valk has been honest about. Linux 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 FAIR uses, the same cryptography modern signing standards use generally. The mathematics is not where these standards differ from each other. The governance is.
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 a standard (MX, C2PA, FAIR, schema.org, anything that claims to be open) 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.