Does the GraphQL specification define default property-based field resolution?

## What the specification actually says The GraphQL specification's execution section describes, in algorithmic steps, how a document turns into a response: collect the fields for the current object type, execute each one, complete the value against the field's declared type, assemble the response map. Inside the step that executes a single field, it calls out to obtain a raw value — and at that exact point the spec stops describing and starts assuming. It treats the resolver as an **internal function that the type system provides for that field**, takes it as given, and never specifies how the function is obtained or how it computes anything. That is the whole answer: **property lookup is not in the spec.** The spec defines the language, the type system's semantics, validation, and the shape of execution. It deliberately does not define how a field gets bound to host-language data. ``` # the spec's shape, paraphrased ExecuteField(objectType, objectValue, fieldDefinition, ...): argumentValues = CoerceArgumentValues(...) resolvedValue = <internal resolver the type system provides>(objectValue, argumentValues) return CompleteValue(fieldType, resolvedValue, ...) ``` The one value execution itself supplies is the initial value handed to the root operation type; from there on, every raw value comes out of a resolver the spec declines to define. ## Why leave it undefined Because "read the property of the same name" is not a portable instruction. GraphQL is implemented in languages where the parent value might be a class instance with private fields and getters, a struct with exported names, an immutable record, a hash map, a database row wrapper, or a lazily-evaluated thunk. A spec rule mandating property lookup would either be vague enough to be useless or specific enough to exclude most host languages. Leaving resolution to the type system also lets schema-first and code-first construction coexist: in one, resolvers are registered against a parsed SDL; in the other, the type system is built from host-language declarations and the binding is implicit. Both satisfy the same spec. There is a second, subtler reason. The spec's contract is about what a **client** can observe. A client cannot tell whether a field's value came from a hand-written resolver, a default property read, or a constant — the response shape is fixed by the document and the schema either way. Resolution is a server-authoring concern, and specifying it would constrain implementations without giving clients anything. ## What "convention, not spec" costs you Default resolution exists in every mainstream server, which makes it feel specified. The differences are in the details that bite: * **Name matching.** Whether a schema field `isExitRow` finds a member spelled `isExitRow`, `is_exit_row`, or a getter, and whether a boolean getter prefix is recognised, is per-implementation. * **Callables.** Some defaults invoke a same-named function they find; some return it, which then fails value completion. * **Map-like parents.** Whether a dictionary key counts as a member at all. * **Failure mode.** All of them agree that finding nothing yields null, not an error — which is why a binding difference surfaces as data-shaped nulls rather than a loud startup failure. So the portable artefact is the schema, not the server. Moving an SDL file plus a set of resolvers to a different implementation is a rewrite of the resolver layer, and the fields that were never written down — the ones the old default was quietly serving — are exactly the ones that break, because nothing in the SDL records that they were relying on a binding rule. ## The interview framing The reason this is worth knowing is not spec trivia; it is that it tells you where to look when a field returns null for no visible reason. If default resolution were specified, the answer would be in the spec. Because it is a per-implementation convention, the answer is in whatever binding rule your server applies, and the only durable defence is to stop relying on it for anything non-obvious: name the member explicitly, or write the resolver. A team that treats "the default will find it" as a spec guarantee has built on something no document promises. A candidate who can separate the specified layer — collection, execution order, value completion, error propagation — from the conventional layer around it is showing the thing this question is really probing: that they read GraphQL as a specification with an ecosystem on top, not as one library's behaviour.