AI business intelligence for your database questions

A business question with a checkable answer

A sales manager asks: “For tenant A, show paid USD orders placed September 1–4, 2026, net of refunds recorded before September 5. Break the total down by region.” This specifies the business definition before requesting a chart. An analyst should first confirm that these are the right dates and refund rules for the decision.

The following figures come from the synthetic SQL dashboard worked example. They are a reference answer, not a recorded AI response or a customer result.

The overall average is $279 ÷ 4 = $69.75 per order. Averaging the two regional averages ($75 and $54) would give $64.50 and answer a different question. The reference excludes cancelled orders, another currency, another tenant and orders outside the period; refunds are aggregated per order before joining so repeated refunds do not duplicate sales.

Next ask: “Show the daily breakdown, keeping the same filters and refund cutoff.” The reference totals are $105, $134, $40 and $0 for September 1–4. A chart should preserve the zero-sales day and reconcile to $279. Ask the analyst to check both the result and the query or execution record available in your chosen product workflow; do not assume every end-user chat exposes SQL.

This definition reports net sales for an order cohort. It is not a cash-flow statement, a profitability calculation or proof of why revenue changed. For a causal question such as “Did our campaign cause the change?”, bring in the relevant attribution design and supporting data rather than treating a plausible explanation as evidence.

Use the existing PostgreSQL reference SQL in an isolated test database with your analyst, then follow the full guide for KPI and filter validation. The downloadable reference contains synthetic data and is not an AskYourDatabase import.

From approved data to a useful BI evaluation

1. Choose the workflow and owner. Start with Desktop for conversational exploration, Dashboard Builder for a repeatable view, or Website Chatbot for an application. Confirm the required plan and product controls before planning a team rollout.
2. Prepare a reporting source. Ask the database owner for appropriate network access and a restricted account. Prefer approved reporting tables or views. Follow the connection guide; availability of multiple connectors is not a promise of cross-database joins.
3. Add business context. Document the meaning of revenue, customers, valid statuses, relationships and date boundaries. Use documentation and verified SQL examples where supported. Keep evaluation questions separate from the examples you use to configure the assistant.
4. Ask, refine and reconcile. Start with a question whose answer an analyst already knows. Change one filter, test an empty period and check a follow-up. Record errors and manual corrections, not just successful demonstrations.
5. Promote recurring questions deliberately. Use Dashboard Builder for a stable view. Check refresh behavior, query cost, date filters and actual recipient access before following the dashboard embedding workflow.

Use the text-to-SQL acceptance kit for a fuller evaluation. Record correct answers, unresolved questions, time spent reviewing and database or model costs separately. There is no universal accuracy percentage or promised time saving for every dataset.

For rollout responsibilities and adoption measurement, see the data democratization guide. This page helps you choose the product workflow; that guide covers operating it across a team.

Check where data goes and who can read it

Desktop connects from your machine; hosted Chatbot and Dashboard workflows use server-side connections. Relevant schema, context or query results may still reach the configured model provider. A local connection or private application deployment does not by itself establish offline inference. Review data flow and security and private deployment requirements for your configuration.

Use database permissions and reviewed access controls for reporting restrictions. A prompt saying “read only” is not a permission boundary, and hiding a field from the interface does not prove that the execution identity cannot read it. If warehouse column-level rules are a requirement, test them using the actual connection identity. Do not assume that a shared credential automatically inherits each viewer's warehouse role.

Before sharing, ask a permitted and a forbidden question as distinct test users, inspect backend results and confirm how sessions identify recipients. A working link or a refusal sentence is not enough to certify isolation. The embedded chatbot implementation guide explains that separate integration task.