How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

Federation Aligns Schemas, But It Cannot Align People

September 17th, 2026 · Kin Lane
Federation Aligns Schemas, But It Cannot Align People

I have spent a good part of this series arguing for federation — as the thing MCP needs, as the right posture for governance, as the alternative to centralization in almost every place the two compete. So I want to be honest about federation’s hard limit, because I watch people reach for it as a cure for a disease it cannot touch. Federation can align schemas. It cannot align people. It can stitch a dozen technical surfaces into one coherent graph, reconcile field names, and give you a single place to query across systems that were never designed to agree. What it cannot do is make two departments actually agree on what a thing is, and that disagreement is where most real governance goes to die.

Let me give you the examples that made this concrete for me, because they are more persuasive than any abstract point. At a firm like Bloomberg, the buy side and the sell side do not merely use different systems — they mean genuinely different things by the same words, because their businesses relate to the underlying reality differently. You can federate their schemas all day. You cannot federate away the fact that a term of art means one thing to the people selling and another to the people buying, because that difference is not an accident of tooling — it is the shape of two different jobs. At a company like Daimler, “a car” has many definitions, and every one of them is correct for the department that holds it: the car engineering means, the car manufacturing means, the car finance means, the car legal means, and the car marketing means are all real, all in use, and all subtly incompatible. No federated graph resolves that, because there is no single right answer to resolve to. The disagreement is not a bug in the data. It is the organization.

The one that stays with me most is the government version, because there the disagreement has a budget attached. I have watched the fight inside large agencies — the VA is the example I keep coming back to — over which system holds the “authoritative record,” and it is never really a technical fight even though it is always dressed as one. It is a fight over money, headcount, and control, because the team that owns the authoritative record owns something that matters, and no amount of schema federation is going to make the other teams cheerfully concede it. When I say that API governance is seventy-five percent people work, this is the seventy-five percent. Federation is a technical answer, and technical answers are the easy quarter. The authoritative-record fight is the hard three-quarters, and it is a fight about people, incentives, and power that no registry can adjudicate.

This is the honest limit of everything I have been building and advocating, and I would rather name it than oversell the tooling. A federated governance registry, a federated discovery layer, a federated graph — these are real and valuable, and they solve the technical coordination problem cleanly. But they solve it by aligning the representations, and representation was never the whole problem. Underneath every federated schema is a set of human beings who have real, durable, often legitimate reasons to define the world differently, and federation politely renders those differences as fields to be mapped when they are actually positions to be negotiated. You can map “customer” from system A to “customer” from system B. You cannot map away the fact that sales and finance mean different people, with different boundaries, for reasons that are load-bearing to how each of them does their job.

So what do you actually do, given that the technical layer cannot finish the job? You stop pretending the federation is the governance and you start treating it for what it is — the part that clears the technical underbrush so the human disagreement becomes visible and addressable instead of hidden inside incompatible systems. That is not nothing. Making the disagreement legible is a real service; a lot of organizations cannot even see where they disagree because the schemas obscure it. But once federation has surfaced it, the work that remains is negotiation, authority, and trust — deciding whose definition wins where, and getting the humans to actually live with the decision. That work has no artifact. It has no registry. It is people in rooms, and it is the part that no protocol in this entire series can do for you.

I still believe in federation, completely, and nothing here walks that back. Federate your schemas, your governance, your discovery, your MCP servers — it is the right posture and centralization is still the wrong one. Just do it with your eyes open about where the technical layer stops and the human one starts. Federation aligns schemas beautifully. It surfaces the human disagreement it cannot resolve, and hands it back to you clarified but unsolved. The organizations that succeed are not the ones with the best federated graph. They are the ones that use the graph to see their disagreements clearly and then do the slow, unglamorous, deeply human work of actually resolving them. The schema was the easy part. The people were always the point.