Budgets plan money. The Objectives Grid (Business Intelligence → Objectives Grid) plans outcomes: a target on any governed measure in this chapter — revenue, gross margin, days sales outstanding, inventory value, donor income, win rate — set for a fiscal period and tracked against exactly the same governed actuals Ask and the cockpits read. A plan and its actuals can never become two different sets of numbers.
An objective is a record, not a setting. Each row names a measure, a target, the period it belongs to, and the part of the business that owns it — the company itself, or (see below) a branch, a department, a sales territory, or a campaign. Objectives can be revised in-year; every revision is kept on the row's activity log, so the history of a target is always visible.
Cascading is a company choice. By default objectives are company-level only, which is a complete and valid way to run. Turn on Objective cascade (Company → Features → Structure) and a company objective can be split onto its branches, departments and territories, each carrying its own target under the parent.
Splits are proposed, never imposed. Ask the grid to propose a split and it divides the parent target by what each node actually did over the trailing twelve months, blended with headroom — the distance between a node and this business's own best node (headroom is always relative to your own best, never to an outside benchmark). The proposal states its basis on screen; you can edit every figure before saving, or discard it.
The gap is always shown. When the children of an objective do not take the whole target, the remainder sits on an explicit Unallocated / centre line; if they take too much, the line says Over-allocated. The grid reports the gap — it never hides it inside a child's figure and never blocks you from saving.
Ratios do not add up, and the grid knows it. Percentage and ratio targets (OTIF, average order value, DSO) are set per node and read at that node's own scope, recomposed from their components there — never averaged across nodes into a parent figure. Position measures (receivables outstanding, inventory value, headcount) read at the period's last day, like every other plan in the system.
Drivers sit under outcomes. Under a revenue objective you can name its drivers — the open order book, orders awaiting invoice, the pipeline — each with its own target, so a slipping lead is visible while the outcome is still recoverable. Campaigns are drivers too: a campaign's spend and the sales or donations recorded under it can carry targets, and everywhere the grid shows them they are labelled ASSOCIATED — never caused. The system tracks what happened beside a campaign; it does not claim the campaign caused it.
Sensitivities — how much a driver moves its objective. Naming a driver says what steers the outcome; a sensitivity says how much: the movement you expect in the objective for each unit of movement in the driver, and the lag — in whole months — before that movement lands. A sensitivity of ×0.8 with a one-month horizon on the pipeline under revenue reads: for every unit the pipeline grows, expect revenue to grow by 0.8 units, a month later.
Every sensitivity is labelled, everywhere it appears, as one of two kinds. A DECLARED sensitivity is a value a person set — the form sits under each driver on the grid, and the line always shows who declared it and when. An ESTIMATED sensitivity is computed from your own governed history: the system reads the two measures' actual monthly movements before the period, fits the link, and then backtests the result on months the fit never saw. An estimate only takes over from the value in force when it beats both that value and a simple seasonal guess (the objective's own level a year earlier) on the same backtest — the same promotion discipline the Analytics Lab applies to its own models. The estimation is recorded as a Lab run, and the full evidence — the three error scores, the window, the verdict — sits one click away under History & evidence on the driver. A candidate that does not clear the bar is kept there, labelled Rejected; it changes nothing. Nothing is ever edited away: when a new declaration or a promoted estimate takes force, the value it replaced stays in the history, labelled Superseded, with its provenance intact. You declare first — estimation exists to challenge a declared value, never to invent one from nothing — and if there is too little history to judge honestly, the system refuses by name and says how much it found. Declaring and estimating need update objectives.
Forward reconciliation — does the plan add up? Under every objective that carries drivers, the grid reconciles the plan before the period starts: each driver's target change (against its actual over the equal-length window just before the period) is multiplied by the sensitivity in force, and the results are set against the objective's own target change. Within the stated tolerance — 10% of the larger side — the plan reads Reconciled. Outside it, the block reads Gap and names the amount: a prompt to revisit a target or a sensitivity, never an error. A driver with no sensitivity yet is named as not quantified, and if a figure cannot be read the block says why. Reconciliation is a report only — it never adjusts a figure to make the sum agree, and it never blocks a save. A horizon shifts when a driver's movement lands inside the period, not the period total the reconciliation judges. Campaign drivers reconcile like any other — as associations, under the same ASSOCIATED — never caused label.
Scenarios — what if the drivers land somewhere else? Under the same objectives you can record scenarios: named what-ifs, each a set of driver targets varied away from the targets the grid itself holds, under assumptions you declare on the record. The grid then compares them side by side — the plan in the first column, one column per scenario — showing each driver's target, the outcome the arithmetic propagates to (the governed baseline plus what the drivers explain, at the sensitivities in force), and the gap to the objective's own target, reconciled, gapped, or not fully quantified exactly as the plan's own reconciliation words it. A driver you do not vary counts at its grid target, so a scenario that varies nothing simply restates the plan. A driver with no sensitivity in force is named as not quantified in every column — its path is never silently counted as no effect. Each scenario's assumptions sit one click away behind its name; a scenario with none declared says so, plainly. Treat every scenario figure for what it is: arithmetic under declared assumptions — not a forecast, and not an actual. Nothing about a scenario ever writes to the grid: if a what-if convinces you, adopt it by revising the driver targets themselves, and the plan — not the scenario — becomes the commitment. Campaign drivers propagate as associations, under the same ASSOCIATED — never caused label.
Who can do what. Viewing the grid needs view objectives; setting and revising targets needs create and update objectives (company admins and managers hold these); recording, revising and removing scenarios needs update objectives; removing an objective is a super-admin act, like all deletion. A measure whose module is switched off for your company cannot be targeted, and a measure that cannot be read at a node — revenue has no department dimension, for example — is refused by name rather than shown with the company's figure under the node's label.