Which schema lint rules cannot be judged from a schema diff alone?

## Two families of rule, distinguished by what they have to read Every schema lint rule has an input footprint. Some rules need one definition: does this `@deprecated` carry a reason, does this field have a description, is this list's item type nullable. Read the definition, decide, move on. Others need the schema as a graph: is this type reachable, is this interface implemented by anything, is this input type used by any argument, do two enums differ only in the case of their values. That distinction decides whether a rule can be scoped to a change at all, and it is not the same distinction as "cheap versus expensive". Reachability over a schema is a single graph traversal over a document that is, even for a large federated graph, one artefact of a few thousand definitions — milliseconds. The reason people reach for diff scoping is not runtime; it is that a schema which predates the rules carries violations nobody is going to fix today, and scoping to the change is the obvious way to stop the new ones without drowning in the old. ## How reachability is actually computed Start from the root operation types the schema declares — the query root, and the mutation and subscription roots if present. Then walk: - from an object or interface field, to its return type and to the types of all its arguments; - from an input object field, to its type; - from an interface, to every object type declared as implementing it, and to any interfaces it itself implements; - from a union, to every member type; - from a directive definition, to the types of its arguments. Unwrap list and non-null modifiers as you go. Anything never visited is unreachable. It is still a perfectly legal part of the schema: type-system validity says nothing about reachability, the schema builds, and — for a schema built from an SDL document, where every definition in the document becomes a type — introspection still lists it among the schema's types. So it is shipped to every explorer, every generated client and every human browsing the graph, as a type that nothing can ever return. ## The case a diff-scoped run cannot see ```graphql # Before type Query { shipment(id: ID!): Shipment } type Shipment { id: ID! manifest: CarrierManifest # the only edge into CarrierManifest } type CarrierManifest { id: ID! sealNumber: String! } ``` Delete one line from `Shipment` and `CarrierManifest` becomes unreachable. The diff touches `Shipment` only. `CarrierManifest`'s definition is unchanged, character for character, so a run that lints changed definitions never evaluates a rule against it — and the rule it would have failed is not a rule about `Shipment` at all. This is the general shape: a whole-schema rule can be broken at a distance from the edit, so the set of definitions a change touches is not a safe unit of evaluation for it. The reverse also happens. A change can *fix* a whole-schema violation far from itself, so a diff-scoped run cannot tell you the total either. ## Which artefact you lint, on a composed graph On an eleven-service graph the question sharpens, because there are now two candidate artefacts. Each service's own SDL is what the authoring team edits and what their pull request diffs. The composed schema is what consumers actually see. Reachability is only meaningful on the composed schema. A type contributed by one service may be reached exclusively through a field declared by another, so a reachability rule run against a single service's SDL produces false positives by construction. There is a second trap in the same place: under a federated composition specification, a service's published schema gains an entity-lookup root field through which the router addresses any type carrying a key, so entity types are reachable there even when no ordinary field returns them. Run a naive reachability check against the author-written SDL, before those additions, and it will call live entity types dead. The workable arrangement is therefore two runs with different scopes. Per-definition rules run in each service's pipeline, scoped to the definitions the change touched, where the feedback is fast and lands on the person who wrote the line. Whole-schema rules run once against the composed schema after composition, unscoped, because there is no smaller correct input for them. ## What to say in an interview The answer that lands is not a list of rules; it is the reasoning that produces the list. Ask what the rule has to read. If the answer is "this definition", the diff is a valid scope. If the answer is "the reachable graph", or "every enum in the schema", or "every type implementing this interface", then scoping to a diff silently weakens it, and the honest fix is to run it on the whole schema rather than to pretend the diff covered it. Then add the corollary that matters operationally: an unreachable type is legal and harmless at execution time, so this is a tidiness and consumer-surface finding — whether it is safe to actually delete the stranded type is a breaking-change question with its own answer.