# AI in the data layer

> The assistant works the data, builds the objects an app is made of, and leaves the requirements behind as a versioned repository instead of writing you a query and disappearing

Source: https://aipril.dev/docs/engine/ai

## 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](https://aipril.dev/docs/engine/data-model.md).
- **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.

```mermaid
flowchart LR
    ASK["What is wanted,<br/>in words"] --> REQ["Requirements<br/>clarified and structured"]
    REQ --> ART["Typed artefacts<br/>model, dashboard, process, pages"]
    ART --> REPO["Repository<br/>versioned, reviewable, diffable"]
    REPO --> REC["Reconciler<br/>brings the installation to it"]
    REC --> LIVE["Working application"]
```

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](https://aipril.dev/docs/engine/data-model.md) - what the assistant is actually writing when it builds a
  model, and why it is a description, not a query.
- [Under the hood](https://aipril.dev/docs/engine/under-the-hood.md) - where the model is compiled and what access is
  applied to it.
- [Analytics with AI](https://aipril.dev/docs/analytics/ai.md) - the same assistant on the reporting side of the same
  models.
- [Applications under the hood](https://aipril.dev/docs/apps/under-the-hood.md) - the repository and the reconciler this
  page's diagram passes through.