GraphQL has no packages, so how do you keep type names unique across many teams?

## What "flat" means precisely The specification requires that all types within a GraphQL schema have unique names, and it gives you no construct for scoping them. There are no packages, no modules, no namespaces, no import aliases — one pool of names, drawn on by every object type, interface, union, enum, input object and custom scalar in the schema. Directive names live in their own pool with their own uniqueness rule, and the root operation types are ordinary members of the type pool: `Query`, `Mutation` and `Subscription` are simply the default names, and a schema definition may point the query root at a differently named type. Two things are *not* in that pool, and saying so is what separates a precise answer from a vague one. Field names are scoped to the type that declares them, so `Employee.status` and `PayRun.status` are unrelated and neither constrains the other. Enum values are scoped to their enum, so two enums may both offer `ACTIVE`. Only type names are global. The first consequence bites inside a single service: an object type and an input object type cannot share a name. You cannot write `type Enrollment` alongside `input Enrollment`, which is the entire reason the ecosystem writes `EnrollmentInput` — a convention with no specification backing, adopted because the flat namespace left no alternative. ## The problem is a scale problem With one team and one service, a flat namespace is invisible; you notice a duplicate the moment you write it. It becomes structural when one schema is assembled from many. On a payroll and benefits supergraph composed from 62 subgraphs and carrying 1,148 named types, every team is drawing from the same pool without seeing each other's picks. Three of them will define `Enrollment` — benefits enrollment, pension plan enrollment, training enrollment — and each is right within its own service. There are only two outcomes and both are bad. Either composition fails because the definitions are incompatible, which is loud and blocks whoever composed last rather than whoever chose the name; or the definitions are similar enough to merge and you now have one type whose meaning is a blend of three domains, which nobody owns and which quietly grows fields from all three. The second is worse, because it never produces an error. ## Which names collide first Not domain nouns. The collisions that actually happen are on generic ones: `Status`, `Type`, `Item`, `Filter`, `Metadata`, `Error`, `Result`, `Connection`, `Edge`, `Node`. Enums called `Status` are the single most common case, because every domain has a status and none of them means the same thing. `Node` is worth calling out separately: the Relay server specification's global object identification convention claims that name for the interface implemented by every re-fetchable object, so a domain type called `Node` takes a name a large part of the ecosystem expects to mean something specific. ## Strategies that survive Qualify by concept, not by owner. `BenefitsEnrollment`, `PensionEnrollment` and `CourseEnrollment` describe what the type is, and they stay correct after a re-org. `HrEmployee`, `PayrollEmployee`, `TeamAlphaEmployee` encode who happened to own it this quarter, and they turn every re-org into either a lie or a rename. A schema whose type names are systematically prefixed by team also reads like packages leaked into a contract that has no packages, and it pushes the noise onto every consumer. Keep the bare, generic nouns out of the shared pool entirely. An enum meaning "the state of a benefit enrollment" is `EnrollmentStatus`, never `Status`; the extra word costs nothing and removes the collision permanently. Decide before composition, not during. The realistic control is a check that runs against the pooled set of names before a subgraph is published — mechanising that check is the schema-linting concern next door, but the naming policy it enforces is the thing this leaf is about, and it has to be written down somewhere every team can read. ## Why a collision found late is expensive Type names reach clients. A named or inline fragment carries a type condition written with the type's name, and the meta-field that reports an object's concrete type returns that name as a string, which clients routinely branch on and normalized caches routinely key on. So resolving a collision by renaming a type is not an internal tidy-up; it is a change every consumer sees. That is the real argument for spending time on names at the point a type is created, when the rename costs nothing. ## The senior framing The point to make is that GraphQL pushes a global-uniqueness problem onto an organization that has no global coordination mechanism, and that no amount of local discipline solves it — each of the three teams that wrote `Enrollment` made a defensible local choice. What solves it is a shared vocabulary decided at graph level, generic nouns treated as reserved, and a check that runs before publication rather than after composition.