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 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
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 - how the grid, the projection and the formula sandbox actually work.