Your AI can write SQL. But who defines revenue?

A valid query can still answer the wrong question

Imagine an order worth $100 placed in December. In January, the customer returns $20 of it. When you ask for December revenue, should the answer be $100 or $80?

Both answers can follow a reasonable reporting policy. One records the return in January; another adjusts the original December order. For this simplified example, assume no other orders, taxes, discounts, or currency conversions. The difference comes from a business decision, not a SQL syntax error.

An AI assistant might generate executable SQL for either policy. A column name and a database schema do not necessarily tell it which policy your team uses. That is the problem I want Vizz Analytics to address.

Start with the decision behind the number

For the example used in Vizz, the decision is explicit: accepted returns are attributed to the original order date. A dataset describes what one row represents, exposes the relevant fields, and carries the context behind the calculation.

Total net revenue is SUM(net_revenue). Gross profit is SUM(gross_profit). Gross margin is total gross profit divided by total net revenue, with a zero denominator returning no value. It is a ratio of totals, not an average of individual order margins.

These formulas still depend on the warehouse source implementing the documented policy correctly. Writing a description does not repair source data. It makes the policy visible so that an author and reviewer can assess whether the source and definition agree.

Make publication a human decision

In Vizz, an author saves a draft, validates it, and submits it for independent review. A different reviewer must approve it before publication. Authors cannot approve their own submissions, including administrators.

The previous published definition stays available while an update is reviewed. Version and review history provide a record of the decision. A published definition is an approved business contract that can be inspected and challenged; approval does not make it infallible.

Give the assistant tools that use that meaning

Consider the question: “Compare net revenue and gross margin by sales channel.” Through the Vizz MCP server, a compatible assistant can find a published dataset, inspect the available fields, and request a grouped query using those published definitions.

Vizz resolves the definitions and executes a bounded, read-only query in the warehouse. The tools return results with version and health context. The assistant does not need to invent a revenue formula from column names or receive the warehouse password. The MCP client authenticates with a scoped Vizz API token.

Where deterministic calculations help—and where they stop

For a given published definition, query request, and warehouse snapshot, the calculation is explicit and repeatable. That gives the assistant a firmer basis for an answer. Results can still change when source data changes.

The model still interprets the user’s question, selects tools, and writes an explanation. It can choose the wrong metric or misrepresent a result. Human-reviewed meaning reduces the space for guesswork; it does not eliminate hallucinations or replace checking the answer.

What I want to test with early users

It stores metadata and governance records; business data is queried in the warehouse, and results go to the requesting user or AI application.

I’m looking for data teams willing to test a handful of their own business metrics. The useful test is concrete: can an author explain the policy, can a reviewer assess it, and can someone else use the published definition to get an answer they understand?

If your team has debated what “revenue,” “active customer,” or “margin” means, I’d like to hear where that ambiguity enters your workflow.