Given only the model version stamped on an eleven-month-old underwriting decline, how does the platform reach its training run?

seniorshould knowfreq 43%

answer

walk it backwards
digest is load-bearing, name is for humans
an alias resolves to today
append-only, written by the producer
traverse it on a schedule

basics

~20 s

Through a two-hop chain: the stamped version resolves to an immutable artifact digest, and a lineage entry written when the run finished maps that digest to its training-run identifier and pin set. A moving alias breaks the first hop.

solid answer

~40 s

Lineage is a chain of immutable edges, walked backwards. The decision carries a version stamp plus the artifact digest it was served from. The digest resolves, through a lineage entry recorded when the training run completed, to a training-run identifier, and the run carries the pin set that rebuilds it. Two properties make the walk work eleven months later. First, every hop names an identity rather than an alias: if the decision had stamped something like "the production model", resolving it today returns whatever is live now, which is a different model. Second, lineage entries are append-only - a promotion writes a new entry, it never rewrites an old one. Stamping the digest alongside the human-readable version also lets the audit detect the failure rather than silently answer from the wrong version.

Lineage is a chain of immutable edges, walked backwards. The decision carries a **version stamp plus the artifact digest** it was served from. The digest resolves, through a lineage entry recorded when the training run completed, to a **training-run identifier**, and the run carries the pin set that rebuilds it. Two properties make the walk work eleven months later. First, every hop names an identity rather than an alias: if the decision had stamped something like "the production model", resolving it today returns whatever is live now, which is a different model. Second, lineage entries are append-only - a promotion writes a new entry, it never rewrites an old one. Stamping the digest alongside the human-readable version also lets the audit detect the failure rather than silently answer from the wrong version.

code

pseudocode · 13 lines

pseudocode

stampedVersion = decision.modelVersion      // "underwriting-scorer/4.2.0"
stampedDigest  = decision.artifactDigest

artifact = registry.resolve(stampedVersion)
if artifact.digest != stampedDigest:
    fail("version alias has moved - trust the stamped digest")

runId = lineage.runFor(stampedDigest)
if runId == none:
    fail("no lineage edge - artifact was not produced by a recorded run")

pins = runs.pinsFor(runId)
return rebuild(pins)

go deeper

for a junior

Recall the shape of the walk: the stored decision names a version and a digest, the digest names a training run, and the run names what it was built from.

for a middle

Explain why each hop must be an immutable identity, and what goes wrong when a decision stamps an alias that keeps moving as new versions ship.

for a senior

Show that you rehearse the traversal on a schedule, and that a moved alias produces a loud digest mismatch rather than a confidently wrong audit answer.

for a principal

Decide what the organisation must be able to demonstrate about a past decision, and set lineage retention accordingly - the small edges usually outliving the artefacts they point at.

The question lineage answers

An applicant disputes a decline issued eleven months ago. The reviewer holds one thing: the model version recorded on that decision. Everything else has to be derivable from it - which artifact was loaded, which run produced that artifact, which data, code, config and environment the run consumed. Lineage is the set of recorded edges that makes that walk possible, and its value is entirely in the direction backwards, from a served prediction to the inputs of a training run.

The resolution chain

Decision to version and digest. The stored decision carries the model version identifier and, critically, the artifact digest the serving tier actually had loaded. The digest is the load-bearing part; the version string is for humans.
Digest to training run. A lineage entry, written when the run finished, maps the artifact digest to the training-run identifier. This edge is created by the producer, not reconstructed later by an auditor.
Run to pins. The run record carries the pin set: code revision, training-data snapshot digest, resolved configuration and seed, and environment digest.
Pins to rebuild. Re-execute, then compare against the recorded artifact digest and a stored audit sample.

Each hop is one lookup with no judgement in it. If any hop needs a human to decide what something meant, the chain is not lineage - it is archaeology.

Why an alias breaks the chain

The most common lineage failure is stamping a moving pointer on the decision instead of an immutable identity.

Stamped on the decision	What it resolves to eleven months later
"production" or "champion"	Today's model version - the wrong one, silently
A major version line such as "v4"	Whichever patch within it is current now
An immutable version plus artifact digest	The exact artifact that scored the application

The first two rows are dangerous precisely because they succeed. A lookup returns a model, the audit runs against it, and the answer is confidently wrong. Recording the digest alongside the version turns that into a detectable mismatch: if the alias has moved, the digest the registry now returns for that version differs from the digest on the decision, and the check fails loudly instead of lying.

What the lineage store must guarantee

Append-only. Promoting a newer version writes a new entry; it never rewrites or deletes the entry for an older one. A retired version's lineage outlives its service.
Written by the producer, at production time. The run records its own output edge, so the edge exists even for versions that never reach production.
Content-addressed at the joins. Digests, not paths. A path can be overwritten; a digest cannot be made to mean something else.
Independently retained. The lineage entry is small and should outlive the artifact and the snapshot it points at, so that even an un-rebuildable version can still be described precisely.
Covering the inputs too, not only the artifact. The run's edges point at the snapshot digest and the feature-definition version, so the walk can continue past the run into what fed it.

Where the chain usually snaps

The decision stores a version string only, so a repointed alias goes undetected.
The lineage edge is written by the promotion step rather than the run, so runs that were never promoted - including the one whose artifact was hot-fixed into place - have no edge at all.
The artifact is referenced by a storage path that a later run overwrote.
Lineage is kept in a mutable record that a subsequent promotion updates in place, erasing the older mapping.
Everything is recorded but nothing is ever walked, so the first traversal happens under audit pressure and discovers the gaps then.

The cheap test

Pick a decision from six months ago at random and walk the chain to a rebuild, as an exercise, on a schedule. Every broken link found that way is found while there is time to fix the writer that produced it. A lineage graph that has never been traversed backwards is an assumption, not a guarantee - and the traversal is the only thing that distinguishes the two.

What lineage does not do

Lineage tells you what produced a decision, not why that decision was what it was. The reasoning behind a single prediction, and the record of the inputs it saw, belong to the decision-logging surface and to attribution work; the rollback of a live version in an incident is an operational concern with its own path. Lineage's job is narrower and unglamorous: given an identity that was stamped in the past, return the exact inputs that built it.

## The question lineage answers An applicant disputes a decline issued eleven months ago. The reviewer holds one thing: the model version recorded on that decision. Everything else has to be derivable from it - which artifact was loaded, which run produced that artifact, which data, code, config and environment the run consumed. Lineage is the set of recorded edges that makes that walk possible, and its value is entirely in the direction *backwards*, from a served prediction to the inputs of a training run. ## The resolution chain 1. **Decision to version and digest.** The stored decision carries the model version identifier and, critically, the **artifact digest** the serving tier actually had loaded. The digest is the load-bearing part; the version string is for humans. 2. **Digest to training run.** A lineage entry, written when the run finished, maps the artifact digest to the **training-run identifier**. This edge is created by the producer, not reconstructed later by an auditor. 3. **Run to pins.** The run record carries the pin set: code revision, training-data snapshot digest, resolved configuration and seed, and environment digest. 4. **Pins to rebuild.** Re-execute, then compare against the recorded artifact digest and a stored audit sample. Each hop is one lookup with no judgement in it. If any hop needs a human to decide what something meant, the chain is not lineage - it is archaeology. ## Why an alias breaks the chain The most common lineage failure is stamping a **moving pointer** on the decision instead of an immutable identity. | Stamped on the decision | What it resolves to eleven months later | |---|---| | "production" or "champion" | Today's model version - the wrong one, silently | | A major version line such as "v4" | Whichever patch within it is current now | | An immutable version plus artifact digest | The exact artifact that scored the application | The first two rows are dangerous precisely because they *succeed*. A lookup returns a model, the audit runs against it, and the answer is confidently wrong. Recording the digest alongside the version turns that into a detectable mismatch: if the alias has moved, the digest the registry now returns for that version differs from the digest on the decision, and the check fails loudly instead of lying. ## What the lineage store must guarantee - **Append-only.** Promoting a newer version writes a new entry; it never rewrites or deletes the entry for an older one. A retired version's lineage outlives its service. - **Written by the producer, at production time.** The run records its own output edge, so the edge exists even for versions that never reach production. - **Content-addressed at the joins.** Digests, not paths. A path can be overwritten; a digest cannot be made to mean something else. - **Independently retained.** The lineage entry is small and should outlive the artifact and the snapshot it points at, so that even an un-rebuildable version can still be described precisely. - **Covering the inputs too, not only the artifact.** The run's edges point at the snapshot digest and the feature-definition version, so the walk can continue past the run into what fed it. ## Where the chain usually snaps - The decision stores a **version string only**, so a repointed alias goes undetected. - The lineage edge is written by the **promotion step** rather than the run, so runs that were never promoted - including the one whose artifact was hot-fixed into place - have no edge at all. - The artifact is referenced by a **storage path** that a later run overwrote. - Lineage is kept in a **mutable record** that a subsequent promotion updates in place, erasing the older mapping. - Everything is recorded but nothing is ever **walked**, so the first traversal happens under audit pressure and discovers the gaps then. ## The cheap test Pick a decision from six months ago at random and walk the chain to a rebuild, as an exercise, on a schedule. Every broken link found that way is found while there is time to fix the writer that produced it. A lineage graph that has never been traversed backwards is an assumption, not a guarantee - and the traversal is the only thing that distinguishes the two. ## What lineage does not do Lineage tells you *what* produced a decision, not *why* that decision was what it was. The reasoning behind a single prediction, and the record of the inputs it saw, belong to the decision-logging surface and to attribution work; the rollback of a live version in an incident is an operational concern with its own path. Lineage's job is narrower and unglamorous: given an identity that was stamped in the past, return the exact inputs that built it.

Why stamp the artifact digest on the decision when the version identifier is already there?
Because the version identifier is a name and names can be repointed. If the registry entry for that version was ever overwritten - a hot fix pushed under the same label, a retag during an incident - resolving the name today returns a different artifact and the audit never notices. The digest turns that silent substitution into a failed comparison, which is the difference between a wrong answer and no answer.
The lineage entry survives but the training-data snapshot it points at was deleted. What can the audit still say?
Quite a lot, precisely. It can name the exact snapshot digest, code revision, configuration and environment the version was built from, and show that the version served is the one stamped on the decision. What it cannot do is re-execute the run. That is a weaker but honest position, and it is why the small lineage entry should be retained longer than the large artefacts it references.

saying these in an interview costs you the question

Stamps a moving alias such as production on the stored decision
Writes the lineage edge at promotion time instead of when the run finished
References the artifact by a storage path that a later run can overwrite
Updates a lineage record in place when a newer version is promoted
Has never walked the chain backwards outside of an actual audit

Given only the model version stamped on an eleven-month-old underwriting decline, how does the platform reach its training run?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The question lineage answers

The resolution chain

Why an alias breaks the chain

What the lineage store must guarantee

Where the chain usually snaps

The cheap test

What lineage does not do

▾common follow-ups2 questions

▾red flags5 flags

The question lineage answers

The resolution chain

Why an alias breaks the chain

What the lineage store must guarantee

Where the chain usually snaps

The cheap test

What lineage does not do

answer

go deeper