Data Lineage

Data lineage records relationships between data sources, transformations, and outputs. It helps explain where an output came from and which downstream resources may depend on a changed input. Depending on the system, records can describe tables, columns, or particular processing runs.

Trace a changed payment state

An order source feeds a cleaned table, which feeds a daily report and an assistant's search index. If a new payment state changes the cleaned table, lineage identifies paths that may carry the change to both consumers. The team can then contact their owners and inspect the relevant rules.

For an incorrect result, work backward along the recorded path: which input version, transformation, and run produced it? This narrows investigation but does not automatically identify the cause.

A recorded path has a coverage boundary

Manual spreadsheets, exports, dynamic queries, or unsupported services may be missing. An absent edge does not prove that no dependency exists. Confirm important consumers before making a breaking change.

Carrying a classification along the derivation path

One common use of the graph is to find out where sensitive data ended up. A field classified as personal in a source system does not stay in one table: it is copied, joined, aggregated, and exported, and the copies rarely inherit the label by themselves.

Lineage gives you the candidate paths, and that is genuinely most of the work. What it does not give you is the decision at each step, because whether a derived column still carries the classification depends on what the transformation did.

Transformation	Reasonable default	Why it needs a person
Direct copy or rename	Inherit the classification	Little judgment involved; this is the case automation handles well
Hash, tokenize, or truncate	Inherit until argued otherwise	A reversible or linkable value still identifies someone; the strength of the transformation is the question
Drop the field, keep the row	Do not inherit	Unless the remaining columns identify the person between them, or the rows were selected or joined on a sensitive condition: membership in the result can then reveal that condition even though the column is gone, so assess what the selection discloses before declassifying
Aggregate to a group	Needs an assessment	Small groups are the warning sign, not the verdict: what the group is defined by, what a reader already knows, and what the figure can be joined to all bear on it. A large group is not automatically safe either — repeated or overlapping queries can narrow it

So propagation should be automatic and conservative — inherit by default, since a missed label is the costly direction — with a recorded exception where someone judges that a derived field no longer carries it. That exception needs to say who decided, on what basis, and when, because it is the entry a later review will question. A downgrade that exists only as an untracked change to a tag is indistinguishable from a labeling bug.

Three things are separate here and are frequently conflated: collecting the graph, running the classification policy over it, and judging whether an output is genuinely no longer personal. A complete graph does not produce correct labels, correct labels do not establish anonymity, and the anonymity assessment is a legal and statistical judgment about what could be re-identified with the means reasonably available — not an output of the lineage tool.

Lineage shows derivation and dependency, not factual truth. A perfectly recorded pipeline can faithfully propagate an incorrect source value. Combine lineage with versioned definitions, quality evidence, and responsible contacts.

References

• Google Cloud: Data lineage