A type is a promise. Check its source.
Static compatibility does not validate external input.
Generated code can satisfy a type checker while relying on values that never receive runtime validation. Follow data from its source, especially when it arrives through an API, a configuration file, or storage. Ask what establishes each assumption before trusting the declared type.
Validate at the point of entry
Use the repository's existing schema or parsing pattern for untrusted values. Check required fields, unknown values, and the difference between absent and explicitly null data. Avoid type assertions that merely silence a mismatch. The error behavior belongs in the contract as much as the successful return type.
Follow the value through serialization
Dates, large numbers, optional fields, and discriminated variants can change meaning across a transport boundary. Inspect representative serialized payloads and their consumers. When extending a union or response shape, check the callers that make exhaustive decisions. A compatible-looking local change can still leave a remote or older consumer unable to interpret the result.
- SOURCE
- External values begin as unverified data.
- PARSER
- Establishes the internal representation.
- CONSUMER
- Receives the documented shape and errors.
WORKING REQUEST / SPEC 04
Inspect the parser before changing this response type. Cover absent, null, and malformed field values. Reuse the current schema library and error format. Find consumers affected by a new variant.
An assertion changes what the compiler believes; it does not inspect a value.