Did the Caller Leave It Out, or Send No Reading?

Botie receives a temperature reading of zero. The helper checks whether the value is true or false in Python, sees that zero counts as false, and substitutes yesterday’s default. Nothing crashes. The model now receives a temperature the sensor never sent.

Before arranging values into the model’s feature order, we need to decide which values the service accepts. A field can be absent, present with no measurement, or present with a number. Those are different situations. Let’s keep them separate long enough to choose a sensible policy.

Botie must distinguish what each caller supplied before preparing model inputs.

[
  [
    "keep",
    "default"
  ],
  [
    8,
    5
  ]
]

A Python dictionary connects a name, such as temperature, to a value. First ask whether that name is in the dictionary. Then, if it is, inspect what was supplied. A present None says something different from an omitted name; JSON decoding represents a supplied null as Python None.

The expression record.get(name) returns None in both of those situations. One option is to test name in record first. Another is to give get a unique object to return when the key is absent. That object is called a sentinel: it marks absence without being confused with a real supplied value.

The field-order adapter from the earlier lesson still matters. We are now checking whether each named measurement is usable before arranging it.

Our contract makes temperature optional and gives absence a documented default. Explicit null is rejected because this particular model path needs a measurement. Zero remains a measurement.

A default is part of model behaviour. If a service uses a training-derived replacement, save it with the fitted model. Recomputing a replacement from each request would reintroduce the mutable fitted-state problem.

default temperature = 5
request {}                         → use 5
request {temperature:0}            → use 0
request {temperature:null}         → reject
request {temperature:"0"}          → reject

These are policy decisions, not estimates that the sensor is working correctly.

Converting every incoming value with float can accept text that a caller sent accidentally. It also hides which producer changed. Decide whether conversion belongs in a separately named compatibility adapter or whether the public boundary rejects it.

Python bool is a subclass of int. A numerical type check that accepts all int instances therefore also accepts True. Our small validator excludes booleans explicitly and rejects infinite or not-a-number values.

JSON does not define nonfinite numerical literals. The Python procedure checks them too because internal callers can bypass JSON decoding.

records = [{}, {"temperature": None}, {"temperature": 0}]
for row in records:
    print("temperature" in row, row.get("temperature"))

False None
True None
True 0

First decide whether the record is acceptable. That is validation. For an accepted record, put the measurements into the model’s feature order and apply its saved transformations. Those steps prepare the input for prediction. Keeping them separate lets us say which part failed.

If temperature contains text that this service rejects, return an input error identifying that field. Passing the text onward and waiting for NumPy to fail would make the caller diagnose a later calculation instead. Keep sensitive raw readings out of general-purpose logs.

The workshop keeps rejected entries visible as null beside a reject decision. Those entries are diagnostic output and must not be treated as model inputs.

A required property must be present. A nullable property permits the explicit null value. It is possible to require a property while allowing null, or make a property optional while rejecting null when it is supplied.

A complete service schema also specifies extra fields, collection sizes and accepted ranges. In JSON Schema, properties alone does not require a field, and additional fields are allowed unless the schema constrains them. These defaults deserve a deliberate review.

These rules let a caller distinguish an omitted optional input from an invalid supplied measurement.

The Python client library and the server can each supply a default. If they choose different values, two callers can get different predictions while sending messages that both look valid. Decide whether omission asks the server to choose, and keep that decision with the model release.

Track rejected fields so a change becomes visible. A sudden rise in nulls could come from a failed sensor or a change in the code that writes messages. The validation result tells us where to investigate; it does not identify the cause by itself.

Preserve the original request identity when reporting failure so the caller can correct that request rather than create an unrelated prediction.