Record, for every training run, which dataset versions went in, which job and code version produced the model, who owned each step, and when it ran. With that, you can answer where a model's data came from, who is affected by a bad source, and which models to retrain after a deletion.
Questions lineage should answer
- A source turned out to be poisoned or mislabeled. Which models used it?
- A person asked for deletion. Which derived tables and training sets held their data?
- A model misbehaves. Which data and code version produced it?
- An auditor asks who approved the use of a sensitive column in training.
If you cannot answer these in an hour, you are missing lineage.
The minimum record
- Dataset identity: a stable name and a version or snapshot ID, plus location.
- Job identity: the code that ran, with a commit hash and the container image or environment.
- Run identity: a unique run ID, start and end time, and the result.
- Inputs and outputs: for each run, the exact input dataset versions and the outputs it wrote.
- Owner: a named team or person for each dataset and job.
- Classification: the sensitivity tags on the data, such as contains personal data.
- Model link: the trained model artifact and the run that produced it.
A standard vocabulary
The OpenLineage project describes three core entities: datasets, jobs and runs, plus facets, which it defines as atomic pieces of metadata attached to those entities. That model maps cleanly onto the list above, and you can add custom facets for things like classification or approval. You do not have to adopt the project to benefit from the vocabulary. See our short guide to OpenLineage basics.
Where lineage usually breaks
- Manual steps: someone downloads a file, tweaks it in a notebook and uploads it. No event is emitted.
- Mutable data: a table updated in place has no version, so you cannot say what the model saw.
- Copies outside the platform: an export to a shared drive leaves the tracked world.
- Naming inconsistency: the same dataset appears under three names in three tools.
Making it stick
Treat lineage as a requirement of the pipeline framework, not a documentation task. Make runs fail to publish a model unless the inputs are registered. Use immutable snapshots for training sets. Add a consistent naming rule.
Test it by running a drill: choose a source table and ask the team to list every downstream model within a set time. Fix whatever gaps the drill shows.
Where Safeguard fits
Safeguard covers the software side: dependency and SBOM scanning, so you can record which libraries ran in a training environment, and compliance evidence automation for the approvals. Try https://gold.safeguard.sh/scan.
Quick check
Why version datasets instead of updating in place?
An in place update erases what a model actually saw, so you cannot reproduce or scope an incident.
Do I need a specific tool to start?
No. Begin with the minimum record in a consistent format, and adopt a standard such as OpenLineage when you need tools to exchange it.
Sources
Last reviewed: 19 October 2026.
