I
Why membership is individual
The single most useful thing we learned reading MCP’s governance is one sentence: membership is for individuals, not companies, and no seats are reserved for anyone. It reads like a modest administrative note. It is the load-bearing decision in the whole document.
A protocol with corporate seats has to answer an impossible question at the outset — which companies get one. Every answer is wrong. Reserve seats for the large firms and the small ones will not build on it. Weight it by contribution and you have invented a market in commit counts. Sell them and it is not a standard.
Tie membership to the person and the question disappears. A very large company can send three excellent engineers and they will earn exactly what three excellent engineers earn. A two-person startup sends one and she earns the same way. Nobody has to negotiate their way in, nobody can buy their way in, and — the part that matters for adoption — a competitor’s participation costs you nothing, so there is no reason to stay out.
II
The roles
Four rungs. Python, PyTorch and MCP all arrived at roughly this shape independently, which is the strongest argument available for it.
Contributor
- Scope
- Issues, pull requests, discussion, HEP authorship.
- Decides
- Propose anything. No standing required to file a HEP.
- How
- Open a pull request. That is the whole requirement.
Maintainer
- Scope
- One area — an SDK, the scope registry, a transport, a working group.
- Decides
- Decides within their area; escalates anything that crosses areas.
- How
- Sustained contribution in that area, nominated by an existing maintainer.
Core Maintainer
- Scope
- The specification and overall direction.
- Decides
- Accepts or rejects HEPs by majority. Appoints and removes maintainers.
- How
- Nominated by a Core Maintainer, confirmed by majority of the existing group.
Steward
- Scope
- Final authority while the specification has a single author.
- Decides
- Can veto any decision, and must publish the reasoning when they do. This role exists because pretending otherwise would be dishonest, and it is designed to be dissolved.
- How
- Held by HushOne today. Ends when the neutral-home trigger is met.
The fourth rung is the uncomfortable one. While a single company authors the specification, that company can override anything, and writing a governance page that pretends otherwise would be the exact species of dishonesty this protocol exists to argue against. So the Steward role is named, its power is stated, and it is built to be dissolved.
The trigger, published in advance
When: Three organisations other than HushOne ship a production implementation of PCHP.
Then: At that point we file to move the specification to a neutral foundation under an open licence, and hold no reserved seat in whatever governance replaces this document.
Named before it is met, because a promise to give up control is only worth something if the condition was written down while giving it up was still hypothetical.
III
How an organisation takes part
Not by signing anything. There is no membership tier, no fee, and nothing to countersign — which is deliberate, because every one of those is a reason for a legal department to say no to something that should take an afternoon.
A large company
Send engineers, not a delegation. They participate as themselves and advance on their own work. Nothing they contribute obliges you, and nothing you would have to disclose is required.
A startup
Implement it and tell us where it broke. A production implementation counts toward the trigger above, and an implementer's bug report outranks a maintainer's opinion in every review.
A university group
Take an open problem. Four are published on the specification and none of them are solved. A dissenting result is more valuable to us than a confirming one.
A regulator or institution
Tell us which tier assignments are wrong. The registry encodes judgements about sensitivity that we made and you may have standing to correct.
IV
Interest Groups and Working Groups
Taken from MCP unchanged, because it separates two failures that need different fixes: groups that discuss forever, and groups that build the wrong thing.
Interest Group
Identify and articulate a problem the protocol should address.
Produces: A written problem statement, and usually a Working Group.
Ends: When the problem is well enough stated that someone can build against it.
Working Group
Produce a concrete deliverable for a problem already stated.
Produces: A HEP, a reference implementation, or a conformance suite.
Ends: When the deliverable is merged. Working Groups are meant to close.
V
Design principles
What a proposal is judged against. The shape, and two of these outright, come from MCP’s design principles, which is the best short document written in this space and worth reading before ours.
Fail closed, always
An unknown scope is intimate, not commercial. An unreadable receipt is a failed access, not a permitted one. Every ambiguity resolves toward the answer that forbids more, because the cost of being wrong is asymmetric and lands on the person, not on us.
The untrusted circle is the default
Design for a counterparty you cannot inspect and would not trust. The trusted circle is the easy special case and must never be the assumption a guarantee rests on. A2A states this plainly for agents; it is even more true for data.
Consent over convenience
If a flow is materially easier without a grant, that is not an argument for skipping the grant. It is the exact point at which every consent system in history has quietly failed.
Derive, never type
Any published number that can be computed must be computed. We shipped a wire specification whose header size was declared 50 in two languages while its own field table summed to 53; the diagram that derived its total is what found it. A hand-typed constant is a claim with no maintainer.
Never infer what the person has not told us
A profile that guesses is a shadow profile with better manners. The whole inversion — one self-owned profile the world subscribes to, instead of a thousand shadow copies — collapses the moment we start filling in blanks.
Removal is a promise
A published scope is a contract. Three hundred and sixty-five days of notice, a permanent tombstone, and a test that fails the build if a scope vanishes without either. Adopted directly from MCP's twelve-month window for its own primitives.
Publish the failure with the fix
Corrections are dated, kept, and linked from the thing they correct — not quietly edited away. A team that only reports its good days eventually gets believed on none of them.
Standardisation over innovation
Taken from MCP unchanged, because it is right: codify what already works across implementations rather than inventing a paradigm and hoping. We would rather adopt UCP's capability intersection than invent a fourth way to negotiate scopes.
VI
On grace and candor
The tone of this page is deliberate, and it is owed to Luiz André Barroso, who was Manish’s mentor and his last boss at Google. Luiz taught a generation to treat the datacenter as a single computer, and to hold performance, energy and cost per watt as the numbers that actually decide an architecture. That lens is the intellectual backbone of the edge grid we are building.
But the habit we are trying hardest to keep is a different one. He led with rigour and warmth at the same time, and he was unembarrassed about saying what was not yet known. A governance page that overstated itself — that implied a foundation, or maintainers, or momentum we do not have — would be the easy thing to write and exactly what he would have gently taken apart. So the honest number at the top of this page is zero, twice, and it will stay there until it is not.
He died in 2023. Nothing here is endorsed by him or by his family, and we claim no affiliation with Google. This is gratitude, in the same register as the rest of our gratitude page.
🤫