A revenue dashboard shows a figure that finance says is wrong; how do you use lineage to find where the error entered?
answer
- start at the dashboard, walk upstream
- compare each hop against a trusted value
- look for the step whose output diverges
- check what changed and when
- fix at the source, then notify downstream
basics
~20 sStart at the dashboard and walk the lineage upstream one hop at a time, comparing each dataset's figure with a trusted reference. The first hop where the value diverges is where the error entered; then check what changed there recently.
solid answer
~50 sI would treat lineage as a search path. Starting from the dashboard, I walk **upstream** one hop at a time and, at each dataset, reproduce the same figure for the same period and compare it with a trusted reference such as the finance ledger total. The error entered at the **first hop where my figure diverges** from the reference while its inputs still agree — that bisects the problem instead of reading every model. At that step I check **what changed**: a code change, a late or partial run, a schema change in a source column, or a new filter. Run history in the lineage shows whether the step ran on stale inputs. Once fixed, I walk **downstream** from the faulty step to list every other dashboard and extract that inherited the bad value and tell their owners.
code
sql · 10 lines-- same period and filters at each hop on the upstream path
SELECT 'reporting_model' AS hop, SUM(net_revenue) AS total
FROM reporting.revenue_by_region
WHERE month = DATE '2026-03-01' AND region = 'EU'
UNION ALL
SELECT 'staging_invoices', SUM(invoice_amount - refund_amount)
FROM staging.invoices
WHERE invoice_date >= DATE '2026-03-01' AND invoice_date < DATE '2026-04-01'
AND region = 'EU';
-- if staging matches the ledger and the model does not, the error entered between themgo deeper
Know that you trace a wrong number upstream through the lineage graph and compare values step by step.
Explain the first-divergence method, what to check at the diverging step, and why the fix belongs at that step.
Show how run history separates bad logic from bad inputs, and how you contain the blast radius downstream while you fix it.
Discuss which reconciliation checks and ownership rules would make this investigation rare, and how to measure time-to-root-cause across the platform.
## The problem A **published number** — a revenue figure on an executive dashboard — is disputed. Somewhere between the source systems and the chart, a step produced a wrong value. Reading every model in the warehouse is hopeless; **lineage** turns the hunt into a bounded search along the path that actually feeds the figure. ## The method: bisect along the upstream path 1. **Pin the claim.** Agree the exact figure, period and filters in dispute ("net revenue, March, EU region") and obtain a trusted reference value, such as the finance ledger total. 2. **List the path.** Walk the lineage graph **upstream** from the dashboard: dashboard → reporting model → intermediate models → staging tables → sources. Column-level lineage narrows the path to the columns that feed this figure. 3. **Reproduce at each hop.** Recompute the same figure from each dataset on the path for the same period and filters. 4. **Find the first divergence.** The error entered at the step whose **output** disagrees with the reference while its **inputs** still agree. With many hops, test the middle first and halve the path each time. 5. **Ask what changed there.** Look at recent changes to that step's code, its run history (did it run on partial or stale inputs?), schema changes in the columns it reads, and new upstream values it does not handle. 6. **Walk downstream from the culprit.** Everything below the faulty step inherited the error, not just the disputed dashboard. ## Typical culprits found this way | Symptom at the diverging step | Likely cause | |---|---| | Output total lower, inputs complete | a new filter or a join that drops rows | | Output total higher | a join that fans out and duplicates rows | | Only recent days wrong | a late or partial upstream run was consumed | | A category missing | a new source value not mapped in a lookup | | Values in the wrong unit | a source column changed meaning or currency | ## What run history adds A static graph says *which* datasets feed which. **Run-level** records say *which run* of each job produced the data the dashboard read, and when. That distinguishes "the logic is wrong" from "the logic ran on yesterday's partial load" — the fix differs completely. ## Closing the loop - **Fix at the step where the error entered**, not with a correction in the dashboard, or every other consumer keeps the bad value. - **Notify downstream owners** found by walking the graph from the faulty step. - **Add the missing check** at that step (a reconciliation against the reference, or a row-count or uniqueness test) so the same failure is caught before publication next time. ## Why interviewers ask it It is the everyday use of lineage for both engineers and analysts. A strong answer shows a **systematic search** (reference value, hop-by-hop comparison, first divergence) rather than guessing, and remembers the **downstream blast radius** once the cause is found.
- What if there is no trusted reference value to compare each hop against?Compare hops against each other instead. Reconcile row counts and totals between a step's inputs and its output for the same period; a step whose output cannot be explained by its inputs is the suspect. You can also compare against the same figure from an earlier period that was accepted as correct.
- The diverging step's code did not change. What else would you check?Its inputs and its run. A source column may have changed meaning or type, a new value may not be handled by a mapping, or the step may have run before an upstream load finished and read partial data. Run history and source schema history answer those.
- How do you stop consumers using the bad figure while you investigate?Flag the affected datasets and dashboards as under investigation in the catalog or on the dashboard itself, and tell the downstream owners found through lineage. Pausing publication of the faulty step is sometimes safer than letting more consumers read it.
saying these in an interview costs you the question
- Patching the number in the dashboard instead of fixing the step that broke it
- Reading every model instead of following the figure's own lineage path
- Stopping at the dashboard owner without walking upstream
- Forgetting the other consumers downstream of the faulty step
- Assuming the step whose code changed last must be the culprit