In a dispatch model, a feature computed from trip history has no online row at request time — what does the scoring path receive?

## Nothing is not an error A lookup against the online tier for a key that has no row returns an **empty result**, which is a perfectly ordinary outcome for a key-value read. It is not a timeout and not an exception, so nothing in the request path treats it as a failure. The scoring path still owes the rider a ranked list, so it puts *something* in the slot and calls the model. The model then does what models do: it consumes a number without knowing where the number came from. The request returns 200, the p99 is unchanged, the error rate is flat, and the dispatch quality for every affected request is lower than the offline evaluation promised. This is the archetype of the silent ML failure — a degradation with no failure signal attached — and it is why an interviewer asks about it. ## The admissibility rule Before a feature enters a served model, three things must hold. They are cheap to check and expensive to skip. 1. **Knowable before the prediction.** The value must exist at the moment of the dispatch decision. Anything that only exists afterwards — the final fare, the trip duration, the rider's rating, whether the trip was cancelled — has no request-time value at all. Such features can be reconstructed for training and never served. 2. **Keyed by something the request holds.** The feature must hang off an entity the request carries: the candidate driver's identity, the pickup zone, the rider. A feature keyed by something the dispatch path cannot name is unreadable no matter how it is stored. 3. **A materialization path exists.** There has to be a route from the columnar history to a row in the online tier, and the feature's registry entry has to say it is served online. "We compute it in the training pipeline" is not that route. ## Coverage is a served-path measurement Admissibility is a design-time check; **coverage** is the running one. For each feature group, measure on live traffic the fraction of candidate entity keys whose online read returns a row, and read it per feature group rather than in aggregate. - Measure it **before** promoting a model that depends on a new feature, on shadow traffic if you have it. - Expect coverage to be below 100% for legitimate reasons — a driver who signed up an hour ago has no 28-day aggregate — and decide deliberately what the model does for them. - Alert on coverage **falling**, because that is the shape a broken materialization path takes when everything else looks healthy. ## The three options when a feature has no row | option | what it costs | when it is right | |---|---|---| | materialize it | storage and a job; only possible if the value is knowable and keyed | the feature carries real signal and the key is cheap | | replace it with a servable proxy | some offline metric, and a new definition to maintain | the original depends on data not present at request time | | drop it from the model | the offline gain it showed | the signal is small or the key space makes a row infeasible | The honest version of the third row deserves emphasis: **an offline gain is not by itself a reason to serve a feature.** A model is a contract with the serving path, and a feature the serving path cannot supply is not part of that contract, however good it looked in the evaluation. ## In a design round Say the failure mode first — empty read, filled slot, no error, worse ranking — then the rule that prevents it, then the measurement that catches the cases the rule missed. That sequence shows you have operated the thing rather than read about it.