Product · How it works
A reviewable plan for this question.
Reusable company context for the next.
Spotonix puts the company meaning, analytical plan, logic, and sources between a business question and the answer—so the responsible person can inspect the work instead of reconstructing it afterward.
One product · three behaviors
Ask. Show. Remember.
No hidden leap from prompt to answer.
Each behavior removes a different piece of invisible expert work: deciding what the question means, checking what will run, and teaching the same term again later.
01 Human ControlAsk
Pause on meaning that changes the analysis.
Spotonix grounds each business term in the context available to the workspace. If an unresolved term could materially change the plan, it can ask your team to define it.
02 Visible LogicShow
Put the interpretation between question and query.
The selected definitions, scope, filters, measure, time window, and grain become a plan a responsible person can read before execution.
03 Compounding KnowledgeRemember
Make a supplied definition available later.
A newly supplied term can become workspace context for another question. Reuse is scoped to the supported persistence and retrieval path—not arbitrary chat memory.
One question · six checkpoints
The product path stays visible
from question to evidence.
The checkpoints below describe the observable workflow. Connector details and deployment controls remain explicit evaluation inputs, not assumptions hidden behind the diagram.
Question
A person asks an ordinary business question in the model surface the deployment supports.
Ground terms
Spotonix looks for names, descriptions, measures, relationships, and workspace context it can use.
Clarify
If missing company meaning could change the analysis, the workflow can pause and ask.
Show the plan
The interpretation, scope, measure, filters, time window, and grain are made visible.
Generate and run
Query logic is generated, material bindings are checked, and the selected customer-VPC warehouse path executes it.
Inspect and reuse
The answer exposes its basis. A newly supplied definition can be available as workspace context later.
The interpretation checkpoint
See what Spotonix thinks you mean
before the analysis runs.
Origin belongs to each concept, not the plan as a whole. One row can come from your team, another from the model you maintain, and another can be assembled for the question.
Why row-level origin matters
The same plan can combine several kinds of meaning.
A single plan-level badge would erase that distinction. In this example, the team defines “habitual customers,” the model supplies the store dimension, and Spotonix assembles the decline comparison and grain for the analysis.
Which stores are losing habitual customers this quarter?
Interpretation
habitual customers
Customers who purchased in at least three of the previous six months.
Defined by your teamAnalytical plan
- Segment
- Habitual customersDefined by your team
- Change rule
- Customer count down vs prior quarterAssembled by Spotonix
- Group by
- StoreFound in your model
- Comparison
- This quarter vs previous quarterDefined inline
- Grain
- Store × quarterAssembled by Spotonix
Read the interpretation and plan. Missing meaning is visible before the analysis runs.
Inspect the basis of the result. The answer does not have to hide behind a chat response.
Where the workflow can pause
Clarification and plan confirmation
are different checkpoints.
Conflating them makes the product sound more universal than it is. The missing-meaning gate applies across supported modes; the additional plan-confirmation pause is specific to Copilot mode.
Supported modes
Clarify material ambiguity.
When unresolved company meaning could change the analysis, the workflow can ask and wait for a definition before continuing.
Copilot mode
Add plan confirmation.
After required clarification is resolved, Copilot mode adds another pause so the person can review the plan before query generation continues.
Product boundary
What this workflow proves.
And what it does not.
A visible plan and evidence trail improve inspectability. They do not turn a generated answer into a universal guarantee.
The plan is not a correctness certificate.
It gives the accountable person something concrete to inspect before and after execution. The reviewer still decides whether the interpretation and result are usable.
Repeated questions need not produce identical SQL.
The question and plan inform query generation, and material bindings are checked. Spotonix does not claim a stable public plan hash or identical query text across runs.
A remembered term is not an authority system.
A concept-origin label does not establish authorship, permission, version history, expiration, or conflict resolution.
Input coverage is format-specific.
Model, SQL, BI, warehouse, and LLM support must be named at the tested subset. The Integrations page holds those boundaries.
Continue the evaluation
Inspect the inputs. Test the boundary.
Then run your questions.
How It Works describes the observable product path. The next two pages state exactly what can enter that path and what your security review must decide.