10.06 · Concept
Training and Serving Data Lineage
Trace a model prediction back to the data sources, feature definitions, transformations, and model version that produced it.
Training and serving lineage makes a prediction explainable as a chain of concrete system states: source data, feature definitions, transformation runs, training snapshot, model artefact, deployment, serving code, and request-time features. It turns debugging and audit questions into graph traversal instead of guesswork across current databases, branches, and dashboards.
What this lesson answers
- trace prediction back to training data and model
- what is training serving skew in lineage
- record identifiers for reproducible ML predictions
Notes
Training and serving data lineage is the practice of making every model output traceable back to the exact inputs and systems that produced it. For a working engineer, this means a prediction should not be treated as an isolated value; it should carry enough context to answer questions like: which raw data sources were used, which feature definitions were applied, which transformation code ran, which training dataset snapshot produced the model, which model artifact was deployed, and which version of the serving logic generated the prediction.
Common questions
- What should be captured to trace a prediction?
- Capture stable references for every important dependency: raw source versions, schema and feature definition versions, transformation runs, the training dataset snapshot, experiment and registry entries, deployed model artefact, serving code version, request details, retrieved feature values, and response metadata. The goal is to reconstruct what actually ran, not what the system looks like now.
- How does lineage help when a model prediction is wrong?
- Lineage narrows the fault domain. You can walk backwards from the prediction to the deployed model, request-time features, serving logic, training data, transformations, labels, and original sources. That makes it possible to distinguish stale inputs, broken pipelines, feature drift, training-serving mismatch, a bad model release, or changed business rules.
- Is ML lineage just logging more fields?
- No. Logging is part of it, but useful lineage forms a dependency graph across systems. Pipelines, feature stores, registries, orchestration jobs, and serving infrastructure emit connected identifiers. Those links show how artefacts were derived from one another, so an engineer can follow causality rather than search disconnected logs.
Short definition: what is Training and Serving Data Lineage?