When two dashboards disagree, the meeting is about the chart. Colour, grouping, a filter someone forgot. That is treating a symptom. The actual failure happened earlier, when "revenue" was defined inside each report instead of once, above the charts, where every consumer has to read it.
Dashboards were built to show numbers. They were not built to own them. If the logic lives in a Looker tile, a notebook, a spreadsheet, and a Python job, you do not have a metric. You have a rumour with a date picker.
The fight is almost always grain and time
Sales attributes revenue to the order date. Finance uses the invoice date. Operations uses ship date. One includes refunds. One does not. One is in UTC, one in the store's local time. One counts a customer as active if they logged in, another if they paid. None of these people are wrong inside their job. They are answering different questions with the same word.
A chart cannot reconcile that. A chart will happily aggregate whatever grain you hand it. If the underlying table is at line-item grain and someone sums it as if it were orders, you get a number that looks precise and is not. If a slowly changing dimension was never modelled, last week's "by region" silently rewrites history.
Logic in the chart is how drift happens
Someone builds a churn tile with a 30-day window. Six months later another team builds a churn tile with a 90-day window for a different review. Neither knows the other exists. Finance later decides refunds should come out of net revenue. In a world where definitions live in dashboards, that is a scavenger hunt: find every chart, hope you did not miss one. With a semantic layer, you change net_revenue once and every consumer moves with it.
This is also why "we need a better dashboard tool" is usually the wrong purchase. The new tool will embed the same fork unless you pull the measure up a layer. Visual polish on conflicting SQL is how leadership loses trust in the data team, then goes back to the spreadsheet they already believe.
Name the decision, then the grain
A dashboard that works starts with a question a person actually has to answer: which accounts are slipping this week, which SKUs we cannot fulfil, whether the funnel broke after the pricing change. Then you name the grain — one row means what? — the time grain, the canonical timestamp, and the filters that are allowed. That is the data model. The line chart is a skin.
If you cannot write the metric in one sentence that a sceptic in finance and a sceptic in sales both accept, you are not ready to plot it. You are ready to have the argument once, in a definition, instead of every Monday in a screenshot.
One definition, many surfaces
A semantic layer is the boring name for that contract: entities, joins, measures, and the descriptions that stop an analyst or an AI agent from guessing. It can live as versioned files next to the rest of the warehouse code, which means a change can be reviewed like any other change. GUI-only measures are shared until the person with admin access edits one and nobody else sees the diff.
You do not need to boil the warehouse. Pick the three metrics that already cause fights. Implement them once. Point the existing dashboards at that model and stop calculating them in the tiles. When the numbers match, you have earned the right to add the fourth. That is also the path that makes later AI-on-your-data honest: a model that writes SQL against raw tables will invent a fifth definition. A model that can only see certified measures has fewer ways to be confidently wrong.
If the chart is ugly and the number is trusted, you have a design problem. If the chart is beautiful and the number is argued, you have a data model problem. Only one of those is why the dashboard failed.