Data Contracts, Serving, and Monitoring

A model expects inputs in a particular form. A data contract makes those expectations explicit enough to test.

A contract might specify:

• required fields;
• data types;
• allowed ranges;
• units;
• missing-value behavior;
• timestamp freshness;
• version information.

Without those checks, a pipeline can feed technically valid numbers into a model while changing their meaning.

Correct shape does not guarantee correct meaning

Suppose a model was trained on distance in centimeters. A new sensor sends meters but uses the same field name.

45 cm becomes 0.45.

The software may accept the number. The model may return a score. Nothing crashes. The result can still be nonsense because the semantic contract changed.

A boundary check that only asks “is this a number?” is too weak. A stronger contract might require:

distance_cm: number
0 <= distance_cm <= 500
unit: "cm"
sensor_timestamp <= 2 seconds old

The exact contract depends on the system. The important idea is that model reliability begins before inference.

Serving introduces time and availability

A model that works in a notebook must still be made available to the application. That serving layer adds questions:

• How long may inference take?
• What happens if the model process is unavailable?
• Which model version is loaded?
• Can the caller detect a timeout?
• Is a failed request retried, rejected, or sent to fallback?

Monitoring asks whether the system still resembles the tested system

Useful monitoring may include:

• input ranges and missing values;
• latency;
• error rates;
• model/version identifiers;
• confidence distributions;
• drift indicators;
• fallback frequency.

Monitoring does not magically diagnose every problem. It preserves evidence that helps us notice when assumptions stop holding.

Before moving on

Design three checks for one input feature used by an AI system: one for type/shape, one for meaning or range, and one for freshness or provenance.