Model Lineage Across Retraining

The simple case is a model trained once from a recorded dataset. The real case is a base model fine-tuned on one corpus, further tuned on preference data, merged with another checkpoint, quantised, and distilled into a smaller student. Each step is a derivation, each derivation has its own inputs, and the deployed artefact's provenance is a path through that graph. Losing any edge means the artefact's history is unreconstructible.

What each edge records

For every derivation: the parent model version, the operation applied, the data used, the code version, and the resulting version. That is enough to replay the path and enough to answer the question that eventually gets asked, which is whether a particular dataset influenced a particular deployed model.

The operations that create edges are more varied than "training". Fine-tuning, continued pretraining, preference optimisation, distillation, quantisation, pruning, adapter merging and weight averaging are all derivations, and several of them are performed by teams who do not think of themselves as training a model and therefore do not record a run.

Adapters make this sharper. A LoRA adapter is a derivation whose parent is a base model and whose deployment combines both, so the served artefact is a pair. Serving many adapters over one base model means the deployment configuration, not the model version, determines behaviour, and the lineage has to cover the combination.

Why the graph matters practically

Vulnerability and contamination propagation. If a training corpus is found to be contaminated, poisoned, or to contain data that must be removed, the affected set is everything downstream of that corpus in the graph. Without the graph, the answer is "we are not sure", and the remediation is either too broad or incomplete.

Licence propagation. A model derived from one with usage restrictions inherits them, and a chain of three derivations often ends with a team unaware of a constraint two steps back. This is a genuine and increasingly enforced exposure.

Debugging inherited behaviour. A behaviour observed in a deployed model may originate in the base model, in one fine-tuning stage, or in the interaction. Bisecting along the lineage is the effective diagnostic and is only possible if intermediate versions were retained.

When it breaks

Intermediate artefacts get deleted. Storage pressure removes the middle of the chain, so the path can be described and not replayed. Retaining intermediates is expensive, and the cheaper compromise is retaining the metadata and the recipe even when the weights are dropped, so the derivation can be re-executed rather than only recounted.

External base models are opaque. A chain rooted in a third-party checkpoint has a first edge whose inputs are unknown, so lineage is complete only from that point forward. Recording exactly which published version and revision was used, by digest, is the most that can be done and is frequently not done.

Merges make lineage a DAG with real ambiguity. Model merging combines several parents, and attributing a behaviour to one of them is not generally possible. The lineage records that a merge happened and cannot record which parent contributed what, which is a genuine limit rather than an implementation gap.

Continuous retraining generates more versions than anyone reviews. A daily retrain produces 365 versions a year, most never inspected. Retention policy has to distinguish versions that were deployed, which need indefinite lineage retention for audit, from those that were never promoted, which can be summarised and dropped.