Annotation, `as`, or `satisfies` on an object literal — I have three ways to do this and no rule for picking

All three answer different questions, and once you see which question each one asks the rule is obvious.

Annotation — const config: Config = {...}. This says "treat this variable as a Config". It checks the literal, and it also replaces what the compiler knows with the declared type. So if Config is Record<string, string>, indexing gives you string and the specific keys are gone. That is not a bug, it is the point: you asked for the general type.

Cast — const config = {...} as Config. This says "stop checking, I am telling you what this is". It is an assertion, not a check. It will accept a wrong shape as long as it is not wildly unrelated, which is exactly the typo problem you described — and your fear is correct, this is the dangerous one. A cast is a comment claiming something the compiler no longer verifies.

satisfies — const config = {...} satisfies Config. This says "check this against Config, but keep what you actually wrote". You get the validation of the annotation and the specific literal type. Typos are errors, missing keys are errors, and indexing still gives you the exact keys and the exact value types.

So the rule: satisfies by default. Annotation when you genuinely want the wider type. as almost never.

Adding the case where satisfies alone is not enough, because you will hit it immediately with route maps.

satisfies preserves the literal type as far as normal inference would, and normal inference still widens things. A string property infers as string, not as its exact value, and an array infers as an array rather than a tuple. So you keep your keys but lose the specific values, which is often the thing you actually wanted.

The pairing is as const satisfies Config:

• as const says infer everything as narrowly as possible — exact string values, readonly tuples
• satisfies Config then checks that narrow thing against your type

Order matters and that is the order.

This is what you want when you plan to derive types from the object — keyof typeof routes, a union of the exact path strings, a lookup type from key to value. Without as const those come out as string and the whole exercise is pointless.

One caution: as const makes everything deeply readonly, so if something downstream wants a mutable array you will get an error there instead. That is usually a signal worth listening to rather than a problem to work around, but it does mean you cannot sprinkle it everywhere without thinking.

Despite the name, as const is not a cast in the dangerous sense. It narrows inference; it does not silence checking.