When does a GraphQL schema need a type for the relationship itself rather than a plain list?

## The two shapes A plain relationship is a list field on each side: ```graphql type Vehicle { id: ID! drivers: [Driver!]! } type Driver { id: ID! vehicles: [Vehicle!]! } ``` A promoted relationship puts an object type between them: ```graphql type Vehicle { id: ID! assignments: [DriverAssignment!]! } type Driver { id: ID! assignments: [DriverAssignment!]! } type DriverAssignment { id: ID! vehicle: Vehicle! driver: Driver! role: DriverRole! startedAt: DateTime! endedAt: DateTime authorisedBy: Employee! } ``` The first says a pairing exists. The second says what the pairing *is*. ## The signals that force the promotion **The pair has attributes.** `role`, `startedAt`, `endedAt`, `authorisedBy` are facts about the combination of a driver and a vehicle. They are not properties of the driver — a relief driver on a rigid this week and a primary on an artic next week has two roles at once — and not properties of the vehicle either. The failure mode is concrete: hang `role` on `Driver` and the field has no single correct value the first time someone holds two assignments, so it either lies or goes null. **The pair has a lifecycle.** It is created, amended and ended by real operations. Mutations need something to target, and "the assignment between driver 8812 and vehicle v-7731" is not a stable address — the same two can be paired twice with a gap between. An id on the relationship gives `endAssignment(input: { assignmentId: ID!, endedAt: DateTime! })` something unambiguous to act on. **Callers want to query it directly.** "Show every open assignment in depot 4, newest first" starts from the relationship, not from either end. That is a root field returning assignments, which is only possible if assignments are a type. **It needs to be filtered and ordered on its own terms.** Selecting within a plain `drivers` list can only filter by driver attributes. Once the interesting predicate is *when the pairing started*, the predicate has nowhere to live until the pairing is a type. ## The signals that say leave it alone A pure many-to-many that carries nothing — the tags on a maintenance job, the fault codes a device can emit — gains only ceremony from a join type. If the pairing has no attributes, no identity anyone refers to and no mutation of its own, `job.tags: [Tag!]!` is the honest shape and a `JobTag` type is noise, forcing every caller through a hop that reveals nothing. Be honest, too, about the direction of travel. It is easy to promote later in a way that is additive: add `assignments` beside `drivers`, deprecate `drivers`, remove it once usage is gone. It is much harder to demote, because callers will already be selecting the attributes you invented. ## The costs you should name before an interviewer does **Every document gains a hop.** `vehicle { drivers { name } }` becomes `vehicle { assignments { driver { name } } }`. That is more typing for every caller and, for the one screen that only ever wanted names, pure overhead. **More resolvers, more amplification.** Each hop is a field that must be batched per request, or a list of assignments turns into one driver lookup apiece. **Ownership gets political.** In an 11-service fleet platform, drivers were mastered by the people system and vehicles by asset management, while assignment was dispatch's business. Had `role` and `startedAt` been hung on `Driver`, a dispatch concern would have been written into a type another team owns, and every change to assignment semantics would have needed their release. A relationship type lands the fields where the behaviour lives. ## Where else the attributes could go, and why those options are weaker A paging convention that wraps each item in a per-item wrapper gives you somewhere to put metadata about the pairing, and for a read-only annotation that is a reasonable home. It is weak for anything with a lifecycle: the wrapper is a position in a result, not an addressable object, so mutations have nothing to target and no root field can return it. Computing the attribute as a field on the far type — `driver.roleFor(vehicleId: ID!): DriverRole` — works for a single lookup and collapses immediately for lists: you cannot render "all assignments for this depot" from a function you must call once per pair. ## The short version to say out loud Promote the relationship when it has facts, identity or verbs of its own; leave it as two list fields when it is nothing but the fact that two things are connected. The question to ask is not "is this many-to-many?" but "if I delete one side, is there anything left worth naming?"