In TypeScript, a teammate silences an "Object literal may only specify known properties" error by writing `as Config` on the literal. What does that assertion give up, and what should they use instead — including where `satisfies Config` does and does not help?

## What the assertion actually does `expr as T` is a compile-time instruction: treat this expression as `T`. It performs no conversion, emits nothing, and checks nothing at run time. Applied to an object literal it also strips the literal's *freshness*, which is the flag that enables excess-property checking. That is why the error disappears — the check was switched off, not satisfied. The only thing `as` still enforces is a comparability rule: the two types must overlap sufficiently in one direction or the other, otherwise you get error 2352 suggesting a conversion through `unknown`. That guard is far weaker than people assume: ```ts interface Theme { color: string; size: number } // compiles — 'colour' is a typo that survives the assertion const t = { color: "red", size: 2, colour: "blue" } as Theme; ``` Because `color` and `size` are present, the overlap test passes and the misspelling rides along. The assertion did not fix a modelling problem; it hid one, permanently, for that whole literal. ## The honest alternatives Work through them in order of preference: 1. **It really is a typo.** Fix the key. This is by far the most common case, and it is exactly what the error was for. 2. **The property is legitimate and belongs to the contract.** Declare it on the type — as a required or optional member. Every other unknown key keeps producing an error. 3. **The contract genuinely accepts arbitrary keys.** Give the target an index signature. Be honest about what this buys: you have declared that any key is valid, so no typo in that object will ever be reported again. Correct for a headers bag or a free-form metadata map; wrong for a settings object with a fixed vocabulary. 4. **The value is wider than the slot but that is fine.** Bind it to a variable first; widening drops freshness for the same reason `as` does, but at least it does not lie about the type. This is a mild code smell, not a fix. ## Where `satisfies` fits — and where it does not `satisfies` is often reached for as "the modern way to silence this", which misstates what it does. `expr satisfies T` checks that `expr` is assignable to `T` and then **evaluates to the expression's own inferred type**, not to `T`. The operand is still a fresh object literal, so excess-property checking still applies: ```ts type Config = { host: string; port: number }; // still an error: satisfies does not permit undeclared keys const c = { host: "localhost", port: 80, timeuot: 5 } satisfies Config; ``` What it does buy you is inference. An annotation widens the value to the declared type; `satisfies` validates against the declared type and keeps the narrower one: ```ts const routesAnnotated: Record<string, string> = { home: "/", about: "/about" }; routesAnnotated.typo; // allowed — key type is string const routes = { home: "/", about: "/about" } satisfies Record<string, string>; routes.home; // known key // routes.typo would be an error — the inferred key set is preserved ``` So the rule of thumb is: **`satisfies` for validation without widening; a declared type change for legitimately extra keys; `as` almost never.** ## When an assertion is defensible There are honest uses. When you know something the checker cannot — a value you have just validated at a boundary, a narrow re-typing of an intentionally loose external declaration — an assertion is the tool. The discipline is to make it small and local: assert the smallest expression, next to the reason, with a comment saying what makes it true. What you should not do is assert a whole configuration literal to make a red squiggle go away, because that particular assertion buys nothing and destroys the one automated typo check the object had. ## The review-level point Excess-property checking is one of the few places where TypeScript catches a real class of production bug — a stale or misspelled key that silently takes a default. It is already deliberately full of holes (an intermediate variable defeats it entirely). Every `as` on a literal removes what remains. That is worth a codebase-level position: assertions concentrated at boundaries, reviewed like any other suppression, and never used as a general remedy for a shape mismatch that the type could simply describe. ## How to answer it Say what the assertion switches off, show that it silences future typos and not just this one, name the three honest fixes, and correct the common misconception about `satisfies` — it is not a way to allow extra properties, it is a way to check without widening.