Data Lineage and Impact Analysis With an End to End Example

Data lineage describes how data moves and changes between assets or processing steps. Impact analysis uses known dependencies and business context to assess what may be affected by a proposed or observed change.

A lineage graph is evidence of captured relationships. Its usefulness depends on source coverage, granularity, observation time, and how the relationships were established. A missing edge is not proof that two assets are unrelated.

Distinguish levels of lineage

Table-level lineage connects datasets or tables. Column-level lineage can show how individual fields contribute to downstream fields. Business lineage connects technical dependencies to concepts such as a metric, report, process, or accountable owner.

Those views serve different decisions. A table-level graph can identify a potentially affected report, while a column-level relationship may help isolate which calculation needs review. Neither automatically establishes whether the resulting data values are correct.

Follow a change from source to report

Use an illustrative dependency chain: source orders.discount_amount feeds a net revenue transformation, which produces a daily regional revenue table used by a finance report.

The source team proposes changing discount_amount from a currency amount to a percentage. The column name remains the same. A schema check might see no change if the physical type remains numeric, but the meaning has changed materially.

This example shows why business meaning matters alongside physical metadata.

Establish how relationships were captured

Ask whether a relationship came from parsed SQL, execution events, imported lineage, manual curation, or another method. Record observation time and supported granularity. A declared relationship and a recently observed execution can provide different evidence.

Check unsupported sources, dynamic queries, external transformations, and manually maintained files. Public platform documentation, including Google's lineage documentation, describes source-specific coverage and limitations. Treat those boundaries as normal evaluation questions rather than assuming a graph covers every path.

Calculate the impact of a changed discount definition

Consider an illustrative order with gross sales of 200 and a discount field containing 10. Under the original currency-amount definition, net revenue is 190. If the source changes the field to mean 10 percent, the expected discount becomes 20 and net revenue becomes 180. The old subtraction still produces a plausible number while implementing the wrong meaning.

The impact review should therefore include the transformation expression, the units attached to the source field, and the effective condition for the change. Determine whether old and new records can coexist. If they can, the target needs an approved way to distinguish their semantics rather than applying one formula indiscriminately.

Use the lineage path to find where that distinction matters. The daily regional table may need a revised calculation, the finance report may need an explanatory note, and a validation rule may need a new expected result. Assign those decisions to owners and retain the relevant test cases with the approved change.

Turn impact analysis into a review

For the discount change, identify the known transformations, tests, terms, reports, and owners. Ask each owner to confirm whether the captured relationship is sufficient to assess the effect. Record additional dependencies found during review.

Agree on the new mapping and expected values before deployment. If the meaning changes from amount to percentage, test representative cases that make the difference visible. Include historical periods if old and new semantics can coexist.

Validate after the change

Check that the deployed mapping implements the approved meaning. Reconcile critical outputs where required and inspect the affected consumer report. Update metadata and dependency records so future reviewers see the implemented state.

Preserve the decision and the evidence, including any coverage gaps. A visually clean graph should not conceal an unknown source or an untested transformation.

Evaluate lineage tools with a traceable business question

Ask a vendor to start with a field used in an important report and trace its supported dependencies in both directions. Check whether a displayed connection identifies the relevant column, transformation, and observation time. A graph with many nodes is less useful when reviewers cannot determine why a particular edge exists.

Include a calculation with a join, an intermediate view, and an external export where those reflect your environment. Confirm which steps are captured automatically, which require imported or manually maintained information, and which remain outside scope. Repeat the review after a changed query to see how the lineage view is updated and how prior evidence is retained.

Check access to the lineage information itself. Object names, business relationships, and source descriptions can reveal sensitive context even when underlying values are hidden. Ask how different roles see the graph and how investigation proceeds when an owner cannot access a restricted upstream asset.

Use lineage with other controls

Lineage helps explain dependencies and support investigation. Validation tests specific requirements. Reconciliation compares populations and values. Access controls govern who may use the data. Combine them according to the business risk instead of asking lineage to prove every aspect of trust.

RightSight supports metadata and impact context. Demonstrate your required sources, dependency types, granularity, and change workflow before making coverage claims. Read active metadata management for the action workflow and ETL mapping for transformation specifications.

Use backward tracing when a report has already failed. Begin with the affected measure and follow the known upstream calculations to identify candidate causes. Then test those candidates against the observed values. A dependency explains where an error could propagate, but investigation still needs evidence that a particular change caused the failure.

Capture the consumer's explanation when a visible dependency is not material to the proposed change. For example, a report may use another column from the same table. Record that conclusion at the available granularity so future reviewers can distinguish a reviewed exemption from an overlooked dependency.

Keep dependency coverage under review

Maintain an inventory of the critical assets expected in the lineage scope and compare it with successfully captured relationships. Investigate missing sources, stale observations, and unsupported transformation paths. Distinguish a reviewed asset with no known downstream consumers from an asset whose dependencies were never captured.

For recurring changes, retain the question, affected path, owner decisions, and validation results. Review incidents where a missed dependency caused an unexpected effect. That feedback helps the team improve capture and manual review without claiming that any graph provides complete knowledge of the data estate.

Frequently asked questions

Request a Demo using one source change and the downstream business decision that depends on it.

Further reading

Google Cloud lineage coverage and limitations