In TypeScript, why does a lookup object typed `Record<Status, string>` — where `Status` is a union of string literals — start failing to compile when a new member is added to `Status`, while `Record<string, string>` keeps compiling?

## The mechanism `Record` is defined as `type Record<K extends keyof any, T> = { [P in K]: T }`. The mapped type iterates the key type. What the compiler can do with that depends on whether `K` is *finite*: ```ts type Status = 'draft' | 'live'; type Labels = Record<Status, string>; // expands to { draft: string; live: string } type Loose = Record<string, string>; // expands to { [x: string]: string } ``` A union of literals is finite, so each member becomes a named property. The mapped type adds no `?`, so each one is **required**. That single fact produces the exhaustiveness behaviour. ## What happens when the union grows ```ts type Status = 'draft' | 'live' | 'archived'; // one member added const labels: Record<Status, string> = { draft: 'Draft', live: 'Live', }; // Error: Property 'archived' is missing in type // '{ draft: string; live: string; }' but required in type 'Record<Status, string>' ``` The compiler flags **every** site annotated with `Record<Status, ...>` — the label table, the colour table, the handler map, the icon map. A single edit to the union produces a work list of exactly the places that need a decision. This is the type-level analogue of a switch that fails when a case is unhandled, and it is why teams reach for a union key deliberately rather than settling for `string`. The open version cannot do this: ```ts const loose: Record<string, string> = { draft: 'Draft', live: 'Live', }; // still compiles after 'archived' is added — nothing was ever required ``` An index signature is a statement about which keys are *permitted*, not which are *present*. There is no key the compiler could name as missing. ## The other half: keys you cannot invent Exhaustiveness has a mirror image. Because the generated type lists the legal property names, an object literal with a key outside the union is rejected by the excess-property check: ```ts const labels: Record<Status, string> = { draft: 'Draft', live: 'Live', archived: 'Archived', deleted: 'Deleted', // Error: 'deleted' does not exist in type 'Record<Status, string>' }; ``` So a literal-keyed `Record` catches both directions of drift: a member you forgot to handle and a stale key left behind after a member was removed. `Record<string, string>` catches neither. ## Ways to lose the guarantee by accident **A type assertion.** `as` is not a check; it only asks whether the two types are comparable in either direction. Since a three-property `Record<Status, string>` is assignable to a two-property literal type, the assertion is permitted and the missing key goes unreported: ```ts const labels = { draft: 'Draft', live: 'Live' } as Record<Status, string>; // no error ``` Annotate the variable instead of asserting the literal — that is the difference between the compiler checking your object and you telling it not to bother. **Wrapping in `Partial`.** `Partial<Record<Status, string>>` adds `?` to every generated property. That is the right type for a genuinely sparse map, but it discards exhaustiveness entirely: nothing is required any more, and each read becomes `string | undefined`. Choose it because the map really is optional, never to silence a missing-key error. **Widening the key.** `Record<string, string>`, or a key type that is really `string` after inference, gives you the open index signature again. ## Keeping the literal value types A plain annotation checks the object but also widens what you read out of it. If you want both the exhaustiveness check *and* the narrow value types of the literal you wrote, use `satisfies`: ```ts const routes = { draft: '/drafts', live: '/live', archived: '/archive', } satisfies Record<Status, string>; // routes.draft is '/drafts', not string — and a missing Status member is still an error ``` `satisfies` checks the expression against the type without changing the expression's inferred type, so you keep the literal types while the missing-key error still fires. ## Where the key set comes from The key union does not have to be hand-written. `Record<keyof Config, Validator>` forces a validator for every field of `Config`; a string enum works the same way, since its members are a finite set. Deriving the key set from the type that actually changes is what makes the guarantee self-maintaining — nobody has to remember to update a second list. ## What it does not do All of this is compile time. The generated type is erased, so a `Record<Status, string>` built from parsed JSON has whatever keys the JSON had; the annotation asserts completeness rather than establishing it. When the data crosses a runtime boundary, the exhaustiveness argument only applies to tables you write in source.