The trick is the intersection with { readonly __brand: B }: the structural part stays compatible with the underlying primitive, but the phantom property makes two brands incompatible because their __brand literal types differ. The __brand field never exists at runtime; it is purely a compile-time marker. Wrapping construction in asUserId is the convention so the cast happens in exactly one place. After that point, loadUser cannot accept a raw string or an OrderId, which catches the entire family of mixed-up-id bugs.

Pairing brands with parser-style constructors gives you 'parse, do not validate': any value of the brand type has already been checked against the regex (or schema), so downstream code can trust the shape without re-running the validation. Returning Email | null forces the caller to handle invalid inputs at the call site, which is far easier to catch in review than a thrown exception buried deep in a stack. The value as Email cast is the one place where the compiler trusts the runtime check; all other code in the codebase consumes the brand without casts.

The real power of brands shows up across a domain: each entity id, each money type, each unit gets its own brand, and the compiler refuses to swap them. Cents versus a raw number catches the classic 'I passed dollars where cents were expected' bug at the type level, with zero runtime overhead. Constructors handle any normalisation up front (Math.round for Cents), so downstream code does not duplicate that logic. This pattern scales to dozens of brands without ceremony and is the lowest-friction way to encode units, currencies, and id namespaces in a TypeScript codebase.