A team hand-writes `interface Order` and a separate `isOrder(x: unknown): x is Order` guard. Months later a required field is added to `Order`, the guard is never updated, and nothing fails to compile. Why does nothing break, and how would you stop this class of drift?

## Why nothing breaks The interface and the guard have no relationship the compiler can enforce. ```ts interface Order { id: string; total: number; currency: string } // currency is new function isOrder(x: unknown): x is Order { if (typeof x !== 'object' || x === null) return false; const o = x as Record<string, unknown>; return typeof o.id === 'string' && typeof o.total === 'number'; // still compiles } ``` A predicate's body is not checked against the type it asserts — the only rule is that the asserted type be assignable to the parameter's declared type, and against `unknown` that rule is vacuous. So the guard compiles unchanged, keeps returning true for `{ id, total }`, and every consumer is now told `order.currency` is a `string` when it is `undefined`. The drift is not a bug in the guard; it is the absence of any mechanism that could have noticed. This is the general failure mode of hand-maintained runtime/compile-time pairs: a type, a validator, a database column, a serializer, a mock in a test fixture. Whichever ones the compiler does not connect will diverge, and the divergence is silent by construction. ## The durable fix: one definition, two outputs Invert the dependency. Make the **runtime** description primary — it is the only one that can exist at runtime anyway — and derive the static type from it: ```ts import { z } from 'zod'; const OrderSchema = z.object({ id: z.string(), total: z.number(), currency: z.string(), }); type Order = z.infer<typeof OrderSchema>; function handle(raw: unknown) { const order = OrderSchema.parse(raw); // throws on mismatch; order: Order } ``` Adding `currency` to the schema adds it to `Order` in the same edit, and the check comes along for free. There is no predicate to forget, because the validator *is* the definition. `safeParse` returns a discriminated result instead of throwing when you want to handle failure without exceptions. io-ts expresses the same idea with codecs and `t.TypeOf<typeof OrderCodec>`, returning an `Either` from `decode`. The conceptual shift matters more than the library: you stop *validating a value against a type you already claimed* and start *parsing untrusted input into a value whose type is now justified*. The parse call is the only place uncertainty exists; everything after it is genuinely typed. ## If you cannot adopt a schema library Sometimes the boundary types are few, or a dependency is unwelcome on a small client bundle. Then buy yourself a compile-time tripwire so the drift becomes a build error: ```ts const orderKeys: Record<keyof Order, true> = { id: true, total: true, // adding `currency` to Order breaks this line until it is listed }; function isOrder(x: unknown): x is Order { if (typeof x !== 'object' || x === null) return false; const o = x as Record<string, unknown>; return Object.keys(orderKeys).every((k) => k in o) && typeof o.id === 'string' && typeof o.total === 'number'; } ``` `Record<keyof Order, true>` requires an entry per key, so the object literal stops compiling the moment the interface grows. It does not force you to check the new field's *type* — nothing can do that by hand — but it converts a silent runtime hole into a red build, which is the whole game. Code generators that emit guards from declarations solve it more completely, at the cost of a build step. ## Testing what the compiler cannot Whichever route you take, guards deserve tests that assert *rejection*, not just acceptance. A test that feeds a valid payload passes for a guard that returns `true` unconditionally; a test that feeds a payload missing each required field in turn is the only one that catches a hollow check. If the guard is hand-written, that table of negative cases is the substitute for compiler verification, and it should be generated from the same key list where possible. ## The judgment being probed An interviewer asking this wants to hear that you know where types and runtime checks are *coupled by hand* and that you treat those seams as maintenance hazards rather than one-time work. The strong answer names the mechanism (predicate bodies are unverified), proposes the single-source-of-truth remedy, and is honest about its cost — a dependency, a bundle-size increase, and validation work on every request — versus the alternative of a hand-maintained pair that will drift the first week nobody is looking.