Prediction Logging and Traceability

A customer disputes a decision made in March. Reproducing it requires knowing which model version ran, what features it saw, what it output, and what the system did with that output. If any of those was not recorded at the time, the answer is a reconstruction, and a reconstruction is exactly what a dispute process cannot accept.

What a prediction record contains

A request identifier that joins to the rest of the system's traces, so the prediction can be placed in the request that caused it.

The model version, and for a composed system every version involved: the retrieval index, the prompt template, the reranker, the calibration layer.

The feature vector as the model received it, after all preprocessing. This is the field that matters most and is most often replaced by the raw input, which is not the same thing: the whole class of preprocessing bugs is invisible if you log only what came in.

The output, including probabilities rather than just the class, since calibration analysis and threshold changes both need the full distribution.

The decision, which is what the system did after applying thresholds, business rules and overrides. The model's output and the action taken are different objects, and confusing them makes it impossible to tell whether a bad outcome came from the model or from the logic around it.

Timing and resource use, for the operational half of observability.

When the eventual label arrives, it joins to this record by request ID, which is what turns a log into a training set and a performance measurement.

Sampling and cost

Logging every feature vector at high request rates produces large volumes. The workable arrangement is tiered: log a small structured record for every prediction, since identifiers, version, output and decision are cheap; log full feature vectors for a sample; and log everything for requests that are unusual, low-confidence, overridden, or belonging to a segment under investigation.

Sampling must be deterministic on the request ID rather than random per stage, so that a sampled request is fully sampled through the pipeline rather than appearing in some logs and not others.

When it breaks

Logs become training data without anyone deciding. Once predictions and labels are joined, the temptation to retrain on them is immediate, and the resulting feedback loop is a design decision that deserves to be made explicitly rather than inherited from a convenient join.

Personal data ends up in logs with a different retention policy. Feature vectors frequently contain personal data, and inference logs are often retained longer and secured less carefully than the source systems. This is a common gap between what a privacy review covered and what the platform actually stores.

Volume forces sampling that breaks rare-case analysis. A uniform 1 percent sample contains almost nothing from a segment that is 0.1 percent of traffic, which is usually the segment being investigated. Stratified sampling with recorded weights preserves the ability to analyse rare cases and to compute unbiased aggregates.

Schema drift makes old logs unreadable. Feature sets change, and logs written a year ago have a different shape. Versioning the log schema and retaining the mapping is what keeps historical records analysable, and adding it retrospectively is not possible.