The Additive Revenue Mistake
You are the data engineer on call for this production path. A balance-like metric is summed across dates and produces inflated totals. What would you investigate, how would you fix it safely, and how would you prove the issue is resolved?
Scenario context
The incident centers on additive, semi-additive, and non-additive facts. The current implementation or operating process does not make that contract explicit, so the team needs a diagnosis supported by evidence rather than a tool or configuration guess.
Business requirement
Identify the most likely failure mechanism, propose a reversible production-safe fix, and explain validation, trade-offs, monitoring, and recovery.
Schema
Data Modeling evidence is shown below. Treat it as a production review artifact rather than a toy exercise.Broken logic / code
-- Current model review
fact_table(grain = 'not documented')
dimension_relationship = 'flattened'
effective_time_rule = 'current row only'
metric_definition = 'copied into each dashboard'Logs / error
[Production review] Scenario 176: The Additive Revenue Mistake
Observed symptom: A balance-like metric is summed across dates and produces inflated totals. What would you investigate, how would you fix it safely, and how would you prove the issue is resolved?
Core contract at risk: additive, semi-additive, and non-additive facts.
Evidence to collect: Track referential integrity, fanout ratio, unmatched members, metric deltas by version, and reconciliation to approved examples. Add contract tests for grain and temporal joins. Run usage of governed metrics versus direct-table alternatives.Actual output
A balance-like metric is summed across dates and produces inflated totals. What would you investigate, how would you fix it safely, and how would you prove the issue is resolved?Expected output / expected logic
A strong response should define the contract, rank likely causes, propose a safe fix, and prove correctness with monitoring and reconciliation.Your attempt
Write your answer
Think before revealing the answer. A partial but honest attempt is better practice than reading the model solution first.
Saved
Interview-style explanation
Now explain your solution as if you are in an interview: symptom, root cause, fix, edge cases, trade-offs, monitoring, and prevention.