AI dashboards: how to build one where every number traces to a query

Monday, 8.40am. You ask Claude for a revenue dashboard ahead of the leadership meeting. Two minutes later there are twelve tiles: MRR, churn, net revenue retention, new logos by channel, a trend line heading pleasingly up and to the right.

Each of those tiles made a decision you didn't see. Which churn: customers or revenue? Which month: calendar or rolling 30 days? Were trials in the denominator? Did the channel chart drop rows with no UTM source? A dashboard looks like one finished object. It is really a stack of separate claims about your data, each resting on a query and a handful of assumptions.

We've been rude about dashboards for years. They are a crude interface: good at telling you last month's churn rate, poor at telling you why it moved (dashboards are dead; why a dashboard isn't enough). The complaint was always trust. A reader can't see what was filtered out or what the analyst assumed.

AI doesn't fix that. It makes dashboards nearly free to produce, which makes it worse, because the old check (a data team that had to build each chart by hand, and so thought about it) quietly disappears. The fair counter-point: for operational monitoring, where everyone already agrees what each number means, a generated dashboard is a fine thing to have. The trouble starts when the definitions haven't been agreed and the AI agrees them for you.

Most "AI dashboard" tools fall into two groups. Assistants that build a dashboard from whatever they can reach, and BI tools that add an AI author on top of a semantic model someone already maintains. The second group is slower to set up and much easier to trust.

Two things stand out. First, the BI vendors all say the same thing about quality: it depends on the model underneath. Microsoft is blunt: without preparing the semantic model, "Copilot can misinterpret the data and return generic or inaccurate results" (Microsoft Learn, August 2026). Second, only some put the query next to the chart. That one feature decides how fast you can check a tile; weigh it above the chart library. More in AI business intelligence.

This is our setup for an ad hoc dashboard: a board pre-read, a launch review. An afternoon the first time; minutes after that.

1. Connect the warehouse read-only. Add your warehouse's official MCP server as a custom connector (on Team and Enterprise, an Owner adds it for the workspace first). Snowflake's managed server runs SQL as SELECT only by default, and BigQuery's tools are all read-only except execute_sql, which you can block with an IAM deny policy (Snowflake docs; Google Cloud docs). See Claude connectors for the walkthrough.
2. Create a Claude project for the dashboard's subject and paste your definitions into the project instructions (below). This is the step people skip, and it is the one that matters.
3. Ask for the tiles one at a time first, with the SQL, before asking for the layout. Check each number against something you already trust.
4. Then ask for the dashboard from the Artifacts tab's Dashboards template, or in chat. Claude's help pages say each chart shows its query and when it was last refreshed (Anthropic Help Centre, checked October 2026).
5. Add a definitions panel to the dashboard itself, so the reader sees the decisions without opening the chat.

Project instructions to paste (illustrative; replace with your own definitions):

You build dashboards from our warehouse. Rules:
- Use only the tables in the analytics schema. Never query raw_ or staging_ tables.
- Churn = customers whose MRR went from above zero to zero in the calendar month,
  divided by customers with MRR above zero on the first day of that month.
  Report revenue churn separately and label it.
- Months are calendar months in UTC. Exclude accounts where is_test = true.
- For every chart, show the SQL, the row count it returned and the date range.
- If a metric isn't defined above, ask me before choosing a definition.
- Add a panel titled "Definitions and assumptions" listing every choice you made.

The last two lines do the most work. One stops Claude inventing a definition. The other puts the definitions it did use where your reader will see them.

A dashboard artifact in Claude is excellent for a dashboard with a short life: one meeting, one investigation. Nobody files a ticket.

It is a poor home for the dashboard the whole company opens every Monday, for practical reasons:

• Definitions live in a prompt. In a BI tool they live in a semantic model that a team reviews. Change a definition in Omni or ThoughtSpot and every answer picks it up; change it in one Claude project and the next project still uses the old one.
• Permissions follow the viewer, not the data. Claude's help pages say each person connects their own apps, so a shared artifact doesn't share your data access. Sensible for privacy. Awkward for a company dashboard.
• Limits. Artifact storage is 20 MB per artifact, text only, and connector tools that need approval for each action aren't available inside artifacts (Anthropic Help Centre).

So the split we'd use: build ad hoc and exploratory dashboards in Claude, against governed tables, with the checks below. Promote anything people will rely on weekly into the BI tool, where the definitions are shared and reviewed. More on artifacts in general in Claude artifacts.

If your company runs ChatGPT instead: its data analysis tool draws interactive bar, line, pie and scatter charts from uploaded files, but it works on exports of up to about 50 MB per spreadsheet rather than a live connection, so the dashboard is only as current as your last download. See Claude vs ChatGPT for data analysis.

Generated dashboards rarely fail loudly. A broken query throws an error. A query that runs perfectly against the wrong definition produces a clean chart.

On realistic text-to-SQL work, the best system on the BIRD leaderboard scores 82.95 against 92.96 for human data engineers (BIRD, September 2026). The original Spider 2.0 paper had its best agent solving 21.3% of enterprise tasks (Lei et al., 2024), and tuned agents now post far higher numbers on its leaderboards. Yet an audit found annotation errors in 52.8% of BIRD Mini-Dev items, mostly because the questions were ambiguous (Jin et al., January 2026). If benchmark authors can't agree what a question means, a model guessing what your VP meant by "active customers" will sometimes guess wrong.

Definitions are the usual culprit. ChartMogul's worked example has three customers paying $20, $30 and $50; the $50 one leaves. Customer churn is 33%. Revenue churn is 50%. Both correct, and they make very different tiles.

The vendors say as much. Google's Looker docs warn these products "can generate output that seems plausible but is factually incorrect". Tableau's help asks you to review results and notes the agent's defaults for date granularity and aggregation may not match your intent. Microsoft adds a subtler one: when a question isn't covered by the semantic model, Power BI Copilot "answers from the large language model's (LLM) general knowledge" (Microsoft Learn). That is a number from memory sitting in a dashboard.

A two-minute check before you share it

1. Pick the headline tile and open its query. Read only the WHERE clause and the date range.
2. Reconcile one total against a system you trust: Stripe's MRR, the CRM's customer count, finance's revenue figure.
3. Ask: "Which definitions did you choose that I didn't give you?" Anything it names goes into the definitions panel or gets fixed.
4. Check the segments add up to the total on every breakdown chart. Missing rows hide in the gap.
5. Change the date range by a month and see whether the trend still says the same thing.

This is exactly the work Count was built for. Connect it to Claude or ChatGPT, ask it to audit the dashboard's answer, and it returns a canvas where each claim is labelled as a citation, an assumption, model knowledge or a hallucination, with the reasoning chain behind it: the prompt, each query, and the source the number rests on.

The cost of making a dashboard has fallen to roughly the cost of typing a sentence. The cost of trusting one hasn't moved.

Ryan Dolley called badly fitted dashboards "ad-hoc generating machines": they show suggestive numbers, raise more questions than they answer, and bury the data team in requests to explain them (dashboards: the ad-hoc generating machine). An AI that produces a new dashboard for every question runs that machine at a speed no data team can keep up with. You get the sprawl of 2015 in an afternoon.

So our advice is unglamorous. Use AI to build the dashboards you already know you need, against written definitions, and check the tiles that drive decisions. For the questions a dashboard can't answer, ask for an analysis that shows its working (artifacts, not transcripts). The full checking method is in how to check AI answers.

A dashboard nobody can trace is a well-formatted guess.

Can AI create a dashboard?

What is the best AI dashboard generator?

Are AI-generated dashboards accurate?