Validate 86 fields to serve 6

The weather API returns six fields per station. The validator at its upstream boundary checks eighty-six. By the validate-what-you-use school, eighty of those checks are waste. They're the point.

The shape of the feed

The upstream is ARSO's XML feed of station observations. Before any of it reaches the application, the payload passes an XML well-formedness gate and then a 245-line validation DTO that checks the feed's full published shape — identity fields present, coordinates numeric-shaped, the observation array non-empty. Eighty-six fields verified, for an API that will serve six of them. Anything that fails surfaces as exactly one thing: a 502 at the edge.

The 502 is the mechanism. Inside the boundary, data is presumed sane — that presumption is what lets the rest of the code stay simple. So when garbage does get in, it fails far from its cause, wearing your code's fingerprints: an undefined three layers down looks like your bug, not their drift, and you'll debug it as yours. Strict validation at the edge converts that entire class of failure into one loud error at the point where the cause actually lives, labeled as what it is — a bad gateway, not a bad service.

The eighty fields you ignore

Why check fields the API never returns? Because shape drift rarely starts where you're looking. An upstream that renames, retypes, or empties a field you ignore is telling you something about its publishing pipeline — and the fields you depend on ride the same pipeline. The wide check is a tripwire strung across the whole boundary: it fires on the earliest sign of movement instead of the last one. That's the trade I'd name the boundary tripwire — you accept alarms about fields you don't care about, in exchange for hearing the floorboards creak before the beam goes.

Bought, not adopted

This rule wasn't imported from a best-practices list. The commit that hardened the boundary — "Fix Arso mapper for teperature field, tighten validation in controller query and response, add exception handler, and request retryer" — runs to nearly two thousand changed lines across thirty-three files, and it exists because a mapper bug in the temperature field got through first. The wide validation arrived as the response to a narrow failure. I'd have called an 86-field DTO overengineering if I'd seen it on day one; it reads differently as a scar.

The Monday check: pick one upstream response type in your codebase and count what fraction of its documented shape you actually verify. You don't have to close the gap; just knowing the number changes how you'll read your next "weird data" bug.

The strictness has an edge I can bound but not prove. An upstream adding an eighty-seventh field should never break you — the tripwire covers the shape you enumerated, it is not a ban on growth — and exactly where that line sits is judgment, not doctrine. Too strict and you page on their every release; too loose and you're back to undefined three layers down. This API's line sits where the temperature bug taught me to put it, which means I've already moved it once. I expect to move it again; I just can't tell you toward which side.