The type expands into a union: for each candidate key K, produce a shape where K is required and the other keys are optional, then union all of those shapes together. Pick<T, Exclude<keyof T, Keys>> keeps any non-candidate keys intact (useful when only a subset of T's keys participate in the constraint). The runtime sentinel only fills one key at a time, exactly the contract you want at the API boundary. Without this constraint, Partial<SearchInput> would silently allow {}, which usually means a buggy caller hitting the database with no filter.

The variant differs by setting the other candidate keys to never instead of optional, so passing two of them at once becomes a compile error. This shape is the right one for payment methods, login channels, or any union where exactly one of several mutually exclusive fields must appear. The Keys parameter lets you scope the constraint to a subset of T's keys (so amount stays free in the example) without rebuilding the type. Pair with a runtime guard to enforce the same shape against incoming JSON, since TS erases the constraint at the boundary.

The static type catches misuse in TS code, but the moment a request arrives from the wire (JSON body, query string, third-party SDK), the guarantee evaporates. Pairing the type with a tiny runtime helper lets the boundary code reject malformed payloads with a 400 instead of silently accepting them. Both helpers are O(k) over the candidate key list and accept any keyof T array, so callers can derive the keys from the same source as the type with Object.keys or a hand-maintained tuple. Wire these into your validation layer (Zod, valibot, custom) for end-to-end safety.