A GraphQL document validates cleanly and still returns 388,514 rows — why didn't validation stop it?

## The incident A payroll and benefits graph serves 4,182 employees. A reporting screen sends this operation: ```graphql query PayRunReport($runId: ID!) { payRun(id: $runId) { reference payslips { netPayCents employee { fullName } } } } ``` `PayRun.payslips` was declared as `payslips(first: Int, after: String): [Payslip!]!` — paging arguments were added, but as nullable ones so that nothing already deployed would break. The screen omits `first`. During the year-end run the field resolved every payslip attached to that run since 2019: 388,514 rows, a list that grew without a bound, one enormous response and a service under pressure. The document was valid, and validation was right to say so. `payslips` is declared on `PayRun`. `first` is nullable with no default, so omitting it breaks no rule. No literal is mistyped, no fragment is unused. Every rule the pass owns was satisfied. ## The three things the pass structurally cannot know **Values that arrive with the request.** The specification's validation rules are defined over a document and a schema. A rule that wanted to reject `first: 5000` could see it only when the client wrote it as a literal — and the moment the client sends `first: $pageSize` instead, the number is in the variables map, not in the document. A check that read variable values would also be unsafe to reuse: servers keep validated documents around precisely because validation's answer depends only on document and schema, and a value-dependent rule would make yesterday's answer wrong today. **What a type-correct value means.** Validation can prove `first` is an `Int`. It cannot know that anything above 200 is unreasonable here, that `E-4182` is not an employee in this company, or that a date range spans six years. Meaning lives in the domain, and the type system only carries as much of it as you chose to encode. **How much work a field will do.** Nothing static knows a list's length. A pre-execution cost check has to *assume* a page size for each list field, and a field with no required bound defeats that assumption too — the assumed number and the real one part company exactly where it matters. ## Where each check actually belongs **In the schema, first.** The strongest fix is to move the bound into the type system, because that is the only place a static pass can see it. Declare the argument `first: Int!` and every document that omits it becomes invalid at validation — the failure moves from production to the client's build. Be honest about the cost: making an argument required is a breaking change for every deployed client, so it lands as a new field, or behind a rollout that fixes callers first. **In a static analysis alongside validation, second.** Servers commonly run additional pre-execution rules of their own over the same document. They are not part of the specification, and the important thing here is that they inherit the same blind spot: they reason about shape, so they can only bound what the schema lets them count. **At execution, third and non-negotiably.** Whatever the schema says, the resolver clamps. A maximum page size applied where the data is fetched is the only check that sees the actual number after coercion, including the value that came from a variable, and it is the only one that holds when a client is wrong. ## The generalisation worth stating in an interview Ask what a proposed check needs as input. If it needs only the document and the schema, it can be a static rule and should be one, because a static rule fails fast, fails identically for everyone, and can run in an editor. If it needs a value, a row, a clock or an identity, it cannot be a validation rule at all, and pushing it there produces either a rule that is wrong or one that quietly cannot be reused. The last piece is operational. If nothing in the schema bounds a list, add the measurement that would have caught this: record returned collection sizes per field rather than watching only latency, because a list that grew without a bound looks fine on a latency chart right up until the day it does not.