Use case · finance and planning
Understand the plan. Update it. Keep submissions moving.
Ask what changed, validate a planning template and review the proposed updates before saving them to the source. With an agreed workflow, the assistant can also remind owners whose submissions are still outstanding. Each action stays within the enabled scope.
The planning model already holds the answer. It is just that three people know how to ask it.
They ask the assistant instead, and the answer arrives with the environment named on it.
The change is small and it is the whole point. The model was read live on their behalf, 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 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
- Start with a template. Validate the structure, mappings and values against the target model.
- Review before saving. Show the proposed changes and obtain approval before an important update reaches the source.
- Confirm the outcome. Check the saved result and use agreed reminders to follow up on missing submissions.
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.
| environments | Test |
| grants held | 1 |
| describe the model | offered |
| read a slice | offered |
| list members | offered |
| validate across environments | not held |
| environments | Test, Prod |
| grants held | 2, separately |
| describe the model | offered |
| read a slice | offered |
| list members | offered |
| validate across environments | offered |
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. So the first week is configuration, not a project.
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.
Somebody has to say what a good answer is
Which figures get argued about, which comparison is the one that matters, what an answer has to name before anybody will act on it. That is the part only somebody who does the job can define, and it is what a pilot is sized around.
The boundaries of the design, including the ones we would argue for keeping, are on the limits page.