Engineering, production, governance, cost, communication · insight-1256
Validate requests at the serving boundary and refuse them instead of imputing silently
- Evidence type
- documented fact
- Difficulty
- medium
- Roles
- ML engineer
- Industries
- cross-industry
Summary: situation, action, reason, boundary
Situation
A scoring endpoint receives a request with a renamed field, a string where a number is expected, or an extra column, and the service quietly coerces it and returns a score.
Action
Ship the input schema (names, types, required fields, ranges) with the artifact, check every request, return a 4xx for violations, and count rejections per caller and field.
Reason
A model signature acts as a contract for inputs; checking it at the boundary turns silent misuse into a visible, attributable error.
Boundary
Endpoints and batch jobs whose callers the model team does not own.
Symptom or risk
A caller bug becomes a stream of plausible but wrong predictions, and the first signal is a business metric weeks later.
Exceptions
Where a fallback is safer than an error, let the caller route to it explicitly.
Trade-offs
Strict checks add caller friction; version the schema and announce changes.
Pitfalls
Treating a passed type check as proof of correct meaning.
Example
Hypothetical: a fare-quote service receives days_to_departure as the string '14'. A strict schema returns a 400 and increments a rejection counter; a lenient one scores it as a missing value.
Lessons and concepts
Claims and their sources
MLflow model signatures act as a contract for inputs, outputs and parameters; required input fields must be present, extra fields are dropped, and only safe type conversions such as int to long or float to double are applied.