You own a GraphQL graph twelve teams publish to — what fails the schema-check gate, what only warns, and who may override?

## Start from what the gate is for With twelve teams publishing into one parcel-locker graph, the gate is an organisational instrument, and the first move is to say plainly what it protects: **a live consumer must never be broken without a decision someone made on purpose.** That is a narrower goal than "the schema is good", and the narrowness is the point — every additional job you give the gate (naming conventions, description coverage, house style) costs it credibility on the one job that matters. ## The policy, class by class **Safe.** Report nothing. Additive edits are the normal traffic of a healthy graph, and a gate that comments on every one trains people to skim. **Description-only and formatting edits.** Filter them out entirely. This is not pedantry: the fastest way to get a real breaking finding waved through is to bury it under twenty cosmetic ones. **Dangerous.** Pass, but require a reviewer from the owning team who acknowledges it. These are type-legal and cannot be adjudicated by a machine — whether a new enum value hurts depends entirely on how consumers read the field, which no diff can know. Attaching a human is the whole value of the middle class. **Breaking with observed usage.** Hard fail, and do not offer an override in the tool. Evidence says a live consumer selects it; the way forward is deprecation, coordination and time, not a button. **Breaking with credible zero-usage evidence.** Pass with a named approver, and require the evidence — window, coverage, which consumer classes it covers — to be attached to the publish record. This is the case the whole system exists to handle well: without it, the graph can only grow. ## Where the gate runs Run it twice. On the pull request, so the author gets the finding while they still have context. And again **at publish time**, resolving the baseline at that moment, because a branch cleared on Monday can be published on Thursday against a schema two other teams have moved since. Only the publish-time run is a statement about what is actually happening. ## The escape hatch is not optional A gate with no override is a gate that will be bypassed — by publishing out of band, by a team standing up its own endpoint, or by someone quietly disabling the step. Every one of those is worse than an override, because the organisation goes on believing it is protected. So build the hatch, and make its cost **visibility, not friction**: an override requires a named approver and a written reason attached to the publish, and it shows up in a place the graph's owners read. Also decide *who* approves. In a twelve-team graph, routing every override through the platform team makes a queue that becomes the bottleneck for everyone's release. The workable shape is that the owning team approves its own overrides, the platform team owns the *policy* and reviews the record after the fact, and only a specific class — breaking edits on the graph's most widely consumed types — needs a second pair of eyes from outside. ## The number to watch The health metric is the **override rate**: overrides divided by total checks, reviewed on a regular cadence. It reads in both directions. Persistently high, and the policy is miscalibrated — usually the gate is failing on findings that are not real risks, and people are clicking through by reflex, which means the next genuine one goes through too. Persistently zero across all twelve teams, and either the graph is purely additive (check whether anything has ever been deprecated for more than half a year) or teams are avoiding the removals they should be making. A second useful number is the deprecation age distribution — how many fields have carried a deprecation for longer than two quarters. A graph that only ever grows is not a graph with a strict gate; it is a graph whose gate has stopped anyone from cleaning up. ## What the gate structurally cannot do Be explicit about this with the teams, or the gate manufactures false confidence. A structural diff sees types, never meaning. A field that changes units, a list whose default order flips, a cursor whose encoding changes, an argument whose runtime validation tightens — all leave the schema byte-identical and all break consumers. No policy setting catches them; only announcement discipline and a changelog do. The gate is one control among several, and saying so is more principal than tightening it further. ## Consumer tiers Finally, twelve teams do not have one consumer profile. An internal console you redeploy today and a kiosk fleet on a quarterly firmware train cannot share one removal window. Either the policy carries per-consumer-class windows, or the graph is tiered — parts consumed only by fast-moving internal clients evolve on a short clock, parts on the embedded contract move on the fleet's. Pretending one window fits both either paralyses the fast half or breaks the slow half, and choosing which of those you are doing is exactly the call the role owns.