What does the @oneOf directive on a GraphQL input object type require, and is it in the specification?

## What the directive marks `@oneOf` is applied to an input object type definition, not to a field and not to an operation: ```graphql input LockerLookupInput @oneOf { lockerId: ID siteCodeAndDoor: String parcelBarcode: String } type Query { locker(by: LockerLookupInput!): Locker } ``` The marking turns an ordinary bag of optional fields into a **tagged choice**: exactly one way of naming a locker, chosen per call. Without it, the type says only "here are three nullable fields", and nothing in the schema forbids a caller sending all three, or none. ## The rule, stated precisely Three parts, and candidates usually remember only the first: 1. A caller must supply **exactly one** of the input's fields - not zero, not two. 2. The value supplied for that field must **not be null**. Providing the field with an explicit null does not count as choosing it; it is an error. 3. The input type itself is constrained: **every field must be nullable and must have no default value**. That is what makes rule 1 checkable - a non-null field would have to be supplied always, and a defaulted field would be implicitly present on every call, so either would make "exactly one provided" incoherent. Rule 3 is a schema-level constraint, checked when the schema is built. Rules 1 and 2 are checked per request, before execution, so a violation is rejected as an invalid request rather than surfacing as a failure inside a resolver. ## Where the checking happens Because a caller can supply the value either as a literal in the document or through a variable, the enforcement has two halves. A literal input object written into the document can be checked when the document is validated. A value arriving in the variables map is only known at coercion time, just before execution. Either way the request does not run, and no resolver sees a half-chosen value - which is the entire benefit over enforcing the rule yourself. ## Specification status, and why it matters here This is the part of the question with teeth. `@oneOf` came through the specification's working draft and is **not** part of the October 2021 ratified edition - the most recent ratified one at the time of writing. Several servers implemented it ahead of ratification, and several did not. The practical consequence is a toolchain question rather than a philosophical one. Before a schema depends on it, three things need to understand it: the server that builds and validates the schema, any schema-validation or composition step in the pipeline, and the typed client generators your consumers run. A generator that does not know the marking will emit an all-optional shape, so your consumers get no compile-time help and the rule is enforced only by a runtime rejection. That is still better than nothing, but it is a different value proposition from the one people imagine. The long-standing alternative, which works everywhere, is an all-optional input whose exactly-one rule is enforced in server code and written into the type's description. It costs a hand-written check per input and it is invisible to tooling, which is precisely the gap the directive exists to close. ## What an interviewer is listening for Nobody's offer turns on this. What a good answer shows is a habit worth having: knowing the difference between what the specification ratifies, what lives in its working draft, and what a particular server happens to support - and saying which of the three you are relying on before you build on it.