The revenue numbers don’t reconcile across decks. Same question, three different answers.

“Top products by change in revenue, year over year” sounds like one question. It’s really a composition: a scope of what you’re measuring, the calculations that define change and ranking, and a comparison period. Each one hides a choice — which revenue (gross, net, recognized), which comparison period, ranked how. Ask a tool to write the SQL and it commits to one reading inside generated query logic. Spotonix is the AI analyst that interprets before it queries: it composes the question from explicit Calculations and shows you the plan before SQL executes.

The alternative

Two ways to answer it today. Both leave the definition unstated.

The movement question is only hard because the words carry hidden choices. Neither of the usual paths pins them down where anyone can see — one hard-codes a single cut, the other buries the choices in generated SQL.

A dashboard with one fixed cut

It answers one version of the question, forever.

A dashboard bakes in one revenue definition and one comparison period. That’s fine until the question shifts — net instead of gross, quarter-over-quarter instead of year-over-year — and now you’re back to ad-hoc SQL or a new ticket. The one cut it shows can’t tell you whether a different, equally defensible cut would rank the products differently.

Point an LLM at the warehouse

It picks a revenue — and may pick differently next time.

A frontier model writes fluent SQL, so it silently commits to one revenue, one comparison period, and one way to rank. Ask again next quarter, phrase it slightly differently, and it may compose the number another way. Two decks, three answers, and no one can point to which definition each one used.

Cost of delay Every board deck you build on an unstated definition, you risk ranking the wrong products — and you can’t compare this quarter’s movement to last quarter’s, because “revenue” and “year over year” may have meant something different each time you asked.

The outcome

One conformed definition of revenue. Comparisons that actually compare.

The three hidden choices get resolved in the open and represented as Calculations in the plan. Persistence and cross-question reuse are evaluated separately for the workflow that needs them.

01

Conformed Calculations, chosen by you.

“Revenue,” “change,” and “year over year” become explicit Calculations you approved — recognized revenue, net of returns, against the aligned prior period — instead of assumptions baked silently into a query. The choices are visible, and they’re yours.

02

Consistent comparisons.

“By product” then “by region” then “by channel” — each composes the same conformed revenue against the same comparison period. The ranking changes because the business changed, not because the definition drifted between slides.

03

Reviewable next quarter.

Next quarter’s plan exposes its revenue definition, comparison period, and ranking method. A changed interpretation is visible; identical SQL is not promised.

How it works

Compose the question. Show the plan. Then generate and validate.

Ranking is not deciding — the constraints underneath the ranking have to be governed. Intent Algebra composes scope, Calculations, and a comparison period into a plan you can see before SQL executes.

1

Intent Algebra composes.

It reads “top products by change in revenue, year over year” and resolves it into a scope, the Calculations for change and ranking, and a comparison period — a plan you can see, before any query is generated.

2

It surfaces the choices.

Which revenue — gross, net, recognized? Which comparison — prior year, prior quarter? Ranked by absolute change or by percent? Instead of guessing, it shows the defensible readings and asks which conformed Calculations you mean.

3

You approve; it generates and validates.

You confirm the definitions. In Copilot mode, query generation continues only after plan acceptance. Semantic checks validate material bindings before execution.

4

Reuse becomes a proof criterion.

If later movement questions must retrieve the same Calculations automatically, verify the persisted identity, retrieval path, version behavior, and audit trace in the proof.

Representative questions

The movement questions that all hinge on the same definitions.

Once you’ve settled which revenue, which comparison, and how it’s ranked, each of these composes from those same conformed Calculations — so the cuts line up instead of quietly redefining “revenue” between slides.

  • “Which products moved revenue the most, year over year?”

    Scope Products Calculation Change in revenue, YoY Pattern Top-N ranking

  • “Where did that growth come from — which regions carried it?”

    Scope Regions Calculation Change in revenue, YoY Pattern Contribution

  • “Same cut, but quarter over quarter instead of year over year?”

    Scope Products Calculation Change in revenue, QoQ Pattern Top-N ranking

Proof

Watch it compose the plan, then inspect the query bindings.

The differentiator is a behavior you can watch, not a claim. In the demo, ask “top products by change in revenue, year over year” and see the plan surface which revenue and which comparison period before SQL executes. Then inspect the generated query and the bindings checked against the plan. The worked trace uses the public TPC-DS retail schema and is illustrative.