The problem shape
Reach for this when more than one team can change the schema and no one is accountable for its shape.
The failure is gradual and looks harmless at every step. Two teams add fields meaning nearly the same thing under different names. A type accumulates optional fields until nothing about it can be relied on. A field is removed because "nothing uses it," and something did. Nobody can answer who owns Customer, because everybody has edited it.
Federation makes this sharper rather than softer. Distributing authorship across subgraphs is the point, and it means the composed schema, the thing consumers actually see, is nobody's artifact by default. It is an emergent result of independent decisions, and emergent results are not designed.
The underlying issue is that a GraphQL schema is a public API that does not look like one. Adding a field is a one-line change in a subgraph, so it never receives the scrutiny a published interface deserves, right up until a consumer depends on it and it becomes permanent.
The structure
Every type has exactly one owning team, recorded in the schema itself rather than in a wiki, so ownership travels with the definition and shows up in review.
type Invoice @owner(team: "billing") {
id: ID!
amountMinor: Int!
status: InvoiceStatus!
customer: Customer! # resolved by the customers subgraph
}Cross-boundary references go through keys, not through reaching in. A subgraph that needs customer data references the entity by key and lets the owning subgraph resolve it. It does not duplicate the fields it wants, because duplicated fields drift and then disagree.
Additive change is cheap, removal is governed. Adding a field is a normal pull request. Removing or changing the meaning of one requires deprecation with a reason and a date, and evidence that traffic has actually stopped.
type Customer @owner(team: "customers") {
legalName: String!
displayName: String @deprecated(reason: "Use legalName. Removal after 2027-03-01.")
}Composition is enforced in CI, not in review. The pipeline composes the full graph, fails on breaking changes against the published contract, and fails on naming and ownership violations. A rule that only a careful reviewer catches is not a rule, and schema review is exactly where a tired reviewer approves the thing everyone regrets.
Deprecation is driven by field-level usage data. Without per-field traffic, "nothing uses it" is a guess, and the deprecation window is theater. With it, removal becomes a fact you can check.
Trade-offs
Governance is real overhead. Ownership directives, composition checks, and usage instrumentation all cost time to build and keep working.
Deprecation cycles are long. Once a field is public, removing it takes quarters rather than days, and you carry the old field the entire time.
It slows the first schema down. Early on, when one team owns everything, the ceremony feels like pure friction, and the benefit only becomes visible when the second and third teams arrive.
Ownership can calcify. Strict boundaries can make a field that logically belongs in two places into a negotiation. That is usually better than the alternative, but it is a real cost paid in coordination.
When not to reach for it
One team, one consumer. With a single team owning the schema and a single client consuming it, ownership is unambiguous and coordination is a conversation. Add governance when the second team arrives, not before.
Internal-only schemas with fast redeploys. If every consumer ships in the same pipeline as the schema, breaking changes are caught immediately and fixed together. Deprecation windows exist to protect consumers you cannot redeploy.
When the real problem is modeling rather than governance. A schema that is confusing because the domain was never modeled clearly will not be improved by ownership directives. Fix the model first; governance preserves clarity, it does not create it.
Before there is anything to protect. Governance is a mechanism for keeping a contract stable. If the schema is still being discovered, locking it down converts useful exploration into paperwork.