Preserve historical nullability across API boundaries

When an API exposes historical rows, its client contract must preserve every nullable database field that can legitimately exist. Tightening a nullable column into a required string at the UI boundary can make one old record reject the entire response even though the endpoint, routing, and current configuration are healthy. Model the field as nullable, render an explicit “Unprioritized” state, and add fixtures containing populated history with null values. Prefer per-record degradation only when data may truly be malformed; do not silently coalesce null into a real priority because that changes operational meaning. Applies when: Typed clients validate persisted history with Zod or similar runtime schemas. Keywords: Zod nullable API historical rows schema validation UI fallback contract