Working the data
The assistant reaches the data through the same tools a person uses, not through a side channel.
- Views from an intent. Describe the slice you need over the datasets you have and a view is built against them - a real, saved definition the rest of the platform can query, not a one-off result printed into a conversation.
- Models from a table nobody has described yet. A scan reads a dataset and proposes what it is: the domain, business labels for cryptic columns, the questions it usually answers, the rules it obeys, and metrics and dimensions worth defining. Suggestions are accepted, not applied silently - see The data model.
- Formulas written on request. A calculated column described in words comes back as an expression you can read and edit, in the same language the templates use.
- Cleansing that respects the data. The same value arriving as three spellings is a normal state of business data. The assistant groups the variants and proposes the grouping; it does not quietly rewrite what is stored.
- Palettes, themes, chart types and layouts - some of it deterministic instead of generated, because a colour palette does not need a language model and a rule gives a better answer.
Anomalies are found by statistics, explained by the model. Outliers are detected with a robust estimator - a trend resistant to a handful of extreme points, and a confidence corridor built from the spread of the typical ones - instead of by asking a model to eyeball a chart. What the assistant adds is on top of that: what to look at next, and what the deviation is likely to be about. The arithmetic is not a matter of opinion; the interpretation is.
Building the whole thing, not one object
Asking for an app does not produce a data model and leave you to draw the screens.
An application on this platform is a set of typed artefacts, and the assistant produces them together: the data model, the dashboards and the charts and KPI tiles on them, the tables, the processes with their routes and statuses, the automations that fire between them, the dictionaries and the org structure they resolve against, the workbooks, and the portal pages that present all of it.
They are produced to fit each other, because they are produced as one description, not as five requests to five different generators. A KPI on a dashboard resolves against the model that was built beside it; a page shows a board fed by the process that was declared in the same breath.
Not text-to-SQL: requirements become a repository
This is the difference that matters most.
The common shape of AI in analytics is text to SQL. You ask, a query is generated, a result appears. It works, right up to the moment someone asks why the number is what it is - and the answer lives in a chat log, unversioned, unreviewed, unreproducible, differing slightly the next time the same question is asked.
Here the assistant's output is not a query. It is requirements, structured and written down:
- Assembled, not guessed. What is being asked for is clarified into a description first - what the objects are, how they relate, what a metric means - instead of compiled straight into SQL from one sentence.
- Described as typed artefacts. Each one declares its kind, and the compiler rejects a kind it does not know. A malformed description fails at the point it was written, not at the point somebody opens the dashboard.
- Held in a repository. An app is a repository of those artefacts, holding the desired state, and a reconciler brings the installation to it. What you review is a description, and what you diff is a change to a description.
- Versioned, with a history. A published version is immutable: it does not change under the people using it. Changes go out as a new version, and what changed between two of them is a question with an answer.
- Idempotent. Re-applying a description that has not changed does nothing - the specification is compared by hash, not reapplied hopefully. So "run it again" is safe, which is the precondition for automating anything at all.
What this buys is an AI-built system you can review before it runs, roll back after it runs, and explain a year later - three things a generated query in a chat window cannot do. The assistant is fast; the repository is what makes it accountable.
Related
- Data model - what the assistant is actually writing when it builds a model, and why it is a description, not a query.
- Under the hood - where the model is compiled and what access is applied to it.
- Analytics with AI - the same assistant on the reporting side of the same models.
- Applications under the hood - the repository and the reconciler this page's diagram passes through.