How do you set a breaking-change policy for a GraphQL schema with un-updatable clients?

## Policy starts with the callers, not the schema The question "is this edit breaking?" has no answer that lives inside the schema. An edit is breaking relative to somebody, and the only thing that turns a class of edit into a *policy* is knowing who that somebody is and how fast they can move. So the first artefact is not a rulebook, it is a census of consumers with one column that matters: **upgrade latency**, the time between you shipping a change and the last caller that must adapt having adapted. Typical bands, using a clinical-trial registry graph as the example: * **Your own web client.** Redeploys in minutes, from a repository you control. Its documents are knowable and changeable in the same change as the schema. * **A native application for site coordinators.** Old versions persist for months; a hospital-managed device fleet may sit on a build for a year or more. You cannot force an upgrade and you often cannot even measure adoption precisely. * **A sponsor's partner integration.** Changes when the sponsor schedules engineering work, which is a contractual conversation, not a technical one. * **Batch and reporting jobs.** Frequently the forgotten class: they run monthly, so a break can lie dormant past your rollback window. The policy is a function of the longest tail that touches a given part of the graph. Which is the first real insight to state in an interview: **write the policy per surface, not per schema.** A region of the graph that only your own web client selects can evolve aggressively, because breakage is a same-day fix by the same team. The types a two-year-old device build reaches are effectively frozen except for additions. Treating one endpoint as one compatibility regime forces the whole graph down to the slowest caller's rules, and that is how schemas ossify. ## Publish the client's half of the contract Compatibility is a two-sided property, and most organisations only ever write down the server's side. State the obligations that make additive change genuinely safe, and treat them as a condition of being a supported consumer: * Handle an unrecognised value in any output enum with a defined fallback rather than an exception. * Never assume a nullable field will be populated, and never assume a list is non-empty. * Name every operation, so usage can be attributed to a caller rather than to an anonymous document. * Select only the fields you use, because a selection is a dependency you are asking to be preserved. A client that meets those four is one you can ship additively to for years. A client that meets none of them makes even a value addition an incident, and no amount of server-side discipline fixes that. ## Decide the price of never breaking anything The reflexive answer — "we simply never make breaking changes" — is a position, not a policy, and it has a bill. Its currency is parallel surface: `investigator` beside `leadInvestigator` beside `investigatorV2`, three shapes with drifting semantics, all resolved, all tested, all needing an answer to "which one do I use?" for every new engineer. Every field you cannot remove is a field you maintain forever, and the aggregate cost lands not on the team that added it but on everyone who reads the schema afterwards. So a serious policy names the escape valve as explicitly as the default. Something like: additive by default; a break to a frozen surface requires a named owner, evidence about who is calling, a window tied to the version-adoption curve rather than to the calendar, and a decision recorded about what happens to callers who do not move. And it names the override — a field that leaks participant identifiers under a privacy obligation, or a value that is actively wrong — where correctness or legal exposure beats compatibility and the break happens now, with communication rather than a window. ## What a principal is actually being asked The interviewer is not checking whether you can list breaking-change classes; that is a mid-level question. They are listening for four things: that you derive the rules from consumer upgrade latency rather than from taste; that you are willing to segment the graph rather than applying one regime; that you can articulate the cost of *not* breaking as clearly as the cost of breaking; and that you know a policy without usage evidence is a document nobody can enforce. The candidate who says "never break anything" and stops has answered half the question — and the half they skipped is the one that produces a schema people can still understand in three years.