# AI in spreadsheets

> Nobody has to build the budget model by hand any more - the assistant produces the sheets, the links and the formulas, and it arrives as part of an application with its approval route attached

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

## The skill this removes

A budget model is never one sheet. It is a set of them: a sheet per department, a rate table, a
headcount, a consolidation on top, and the web of links and formulas that ties them together so
that changing an assumption in one place moves the total in another.

Building one is a real and fairly rare skill, which is why in most companies the model belongs to
whoever built it - and why nobody wants to touch it, why it takes a fortnight to restructure, and
why it is usually a year out of date in some corner nobody has looked at.

## What the assistant produces

Describe the model in words: what is being budgeted, at what grain, per what period, what drives
what, which figures roll up into which.

What comes back is **the structure**, not a formula pasted into a cell: the sheets, the columns with
the right types, the links between them, the formulas, the totals, and the reference columns
pointing at the actual departments, cost items and periods and not at text that resembles them.

That is the difference from an assistant inside an ordinary spreadsheet. There, the AI helps you
write a cell, and the workbook remains a file somebody has to keep correct. Here the workbook is a
described object, so what the assistant writes is the description - which can be read, reviewed,
changed and versioned like anything else. See
[AI in the data layer](https://aipril.dev/docs/engine/ai.md) for what that description is and why it is the point.

## Working on the data in a column

The other half is smaller and used far more often: fixing what is already in the grid.

The shipped example is **cleansing a column**. The same thing arrives written three ways - a company
name with and without its legal form, a city with a typo, a status somebody capitalised differently
- and this is the normal condition of data people typed. The assistant reads the column, groups the
values that are the same thing spelled differently, and **proposes the grouping**. It does not
rewrite what is stored; you look at the groups and accept them.

That "propose, then a person accepts" shape is the mechanism and not a one-off trick, and it is
what the same column-level work is built from: sorting rows into categories somebody names, filling
a column from what is already in the row, flagging what looks wrong. The assistant's job is to make
the change reviewable in one place instead of leaving somebody to make it four hundred times.

The reason it can be trusted with a column at all is the one from everywhere else on this platform:
what it produces is shown before it is applied, and the underlying data is not touched until
somebody says so.

## It does not arrive alone

Because a workbook is an artifact of an application, what the assistant produces comes with
everything around it, generated together and fitting each other:

- the **data model** the figures resolve against, so the plan and the actuals mean the same thing
- the **process**: who submits, who approves, what happens on rejection
- the **pages** where people open it, and the **dashboards** the result feeds
- the **dictionaries and org references** the columns point at

One description, one published version, installed as one thing. Not a spreadsheet that later needs
a workflow bolted to it.

## The approval loop

```mermaid
flowchart LR
    F["Department fills<br/>its sheet"] --> S["Submit<br/>from the sheet's toolbar"]
    S --> T["Task in the<br/>approval process"]
    T --> A["Approver sees<br/>the figures and the route"]
    A --> ST["Status back in the<br/>sheet, live"]
    ST --> M["Approved figures read<br/>from the data model"]
```

Department heads fill their sheet the way people actually fill a plan - in a grid, at their own
pace. Submitting is a button on the sheet's own toolbar, which raises the task in the approval
process. The status comes back into a column and stays current, because it is read from the task
rather than typed. And once the figures are approved, everyone reporting on the plan is reading the
data model - not a copy of the sheet taken at some point by somebody.

## Keeping approved figures from drifting

Several mechanisms, and they compose:

- **Columns that cannot be typed into.** A computed column, a lookup, a status read from the
  process - these are read-only by definition, because the value belongs to somewhere else.
- **Access is per sheet, and carries a level.** The group that fills a plan and the group that reads
  it are not the same grant, so a submitted sheet can stop being editable by the people who filled
  it.
- **The published version of the application is immutable.** The structure itself cannot drift under
  the people using it - a change is a new version, with a history of what changed.
- **Approved figures live in the model, not in the grid.** This is the one that matters most: after
  approval the number everyone reports on is read from the data model, which is not a surface
  anybody can type into. The sheet stays what it was good for - entering and revising - and stops
  being the place the truth is kept.

Worth being precise about where locking lives: it is arranged in the **process**, not by a checkbox
on the grid - and the process has the means. A route can read a sheet's rows, find them by a
matching column, and write into them, so "approved" is a state the route sets and not a note
somebody remembers to add. Put beside a grant that changes when the submission is made, and columns
that are read-only by definition, that assembles the effect people actually ask for: after approval,
these figures stop moving.

It is also the more durable arrangement. A lock protects a file; a definition protects a number.

## Next

[Under the hood](https://aipril.dev/docs/spreadsheets/under-the-hood.md) - how the grid, the projection and the formula
sandbox actually work.