Use case · finance and planning
The planning model, answering in the assistant.
A planning model holds the numbers everybody argues about and almost nobody can query themselves. The report exists, it is a week old, and the question they actually have is a variation on it. So they ask a person, and that person opens the model.
The change here is small and it is the whole point: they ask the assistant instead, it reads the model live on their behalf, and the answer arrives with the environment named on it. Nobody exported anything, and there is a row afterwards saying who asked what.
The questions
What people actually type, once they can.
Not "analyse our finances". The real ones are narrow, repetitive and currently expensive because they need somebody who knows the model to sit down and look.
| What somebody types | What it costs today |
|---|---|
| What changed in the payroll plan since last week? | An export, two versions, and a spreadsheet compare. |
| Which cost centres moved more than three percent? | A filter somebody has to build, or a report request. |
| Show me the five-year plan for this entity by period. | Knowing which cube and which hierarchy to open. |
| Is this figure from Test or from Prod? | Nothing answers this. It is why the figure gets argued about. |
| What does "contribution" mean in our model? | Asking the one person who remembers. |
The last two are the ones worth noticing. "Which environment is this from" and "what does this word mean here" are not data questions, and they are the two that go wrong quietly. A model that answers confidently from the wrong environment has done more damage than one that refused.
The two rules that shaped this
Never infer the environment. Never widen at runtime.
Both came from a real planning implementation with Dev, Test and Prod running at once, where change control across environments is the daily pain rather than a policy document.
Every answer names its environment
- The model graph carries the project and the environment, so no answer can be silent about where it came from.
- An ambiguous request is refused, with the list. Two candidate environments and no default is a refusal, not a pick.
- Guessing is the failure mode, because a plausible number attributed to the wrong environment survives the meeting.
Writes are a separate decision
- Writes are off on every project. Not a setting somebody forgot: no write tool is deployed here at all.
- Turning them on needs a gate and a ledger, which is a piece of work rather than a checkbox, and it is per environment.
- So this use case is reading, and everything on this page is a read.
Who sees what
Two people, same assistant, different answers.
A planner on one entity and a group controller on all of them ask the same question and get different results, because the narrowing happened before the read rather than after it.
| The planner | The group controller | |
|---|---|---|
| Environments reachable | Test only, because that is the grant somebody created. | Test and Prod, as two separate grants rather than one wider one. |
| Tools offered | Describe the model, read a slice, list members. | The same, plus validation across environments. |
| What a refusal says | That this is not a skill they hold, and who to ask. | The same wording. A refusal never teaches anybody about somebody else's access. |
| On the audit trail | Both, identically, under their own names. Allowed and refused calls sit in the same list. | |
Revoking either takes effect on the next call, because the grant is read per request rather than cached into a session. The four gates explain the narrowing in full.
Before this is real for you
What has to be true first, including what is not true here.
This is the section a use-case page usually leaves out. It is the one that decides whether the first week is configuration or a project.
Your model has to be reachable
A connection string in your own vault, reaching a database we can open from a hosted service. If your security review will not allow that on any environment, this stops here and it is better to find out in the first conversation.
Somebody has to write the vocabulary
What your member names mean, which segments are governed, what "contribution" is in your model. It is drafted from what you connect and then approved by a named person. Without it the answers are literal rather than right.
No client planning database has been read yet
Stated plainly because it is the most important line on this page. The platform is deployed and serving, and this specific path, a live read of a customer's planning model, has not happened. You would be the first, and the pilot should be sized that way.
The rest of what is unfinished is on the limits page, with no date attached to any of it.
Bring the question your planners keep asking each other.
One real question against one real model is a better first meeting than a demo, because it tests the two things that decide the project: whether we can reach it, and whether the answer is right.