The argument in brief
- One flow, five stages, four of them unattended. The planner's first contact with the cycle is a decision to approve or overrule, not a spreadsheet to assemble.
- The override is the interface, not a failure of the system. It is the mechanism by which what an experienced operator knows enters a model that does not yet know it. Suppressing overrides destroys the only learning channel the architecture has.
- Uniform logic, local data, local parameters. Confusing uniform with identical is how global process programmes die, and the regions are right to resist when it happens.
- Simulation is added last, not first. Testing a decision against futures that have not happened is worth a great deal once the ledger exists, and produces unpriceable scenarios before it does.
- Start with one decision in one unit. The first deployment is manufacturing evidence, not capturing value, which is why the largest and most resistant unit should go last by design.
The shape of the machine
The first three papers argued that the planning process should be replaced, that the replacement has to be anchored on a priced cost of error, and that the estimate feeding it should be a distribution rather than a number. This paper sets out what the resulting machine looks like.
It is a single flow with five stages. Stages one through four run end to end without intervention: no re-keying, no master file assembled by hand, no monthly reconstruction of numbers that already exist. A person enters at stage five, and enters to decide rather than to prepare.
Exhibit 1
The decision flow: four unattended stages, one human interface, and a loop that closes
Two features of Exhibit 1 do most of the work and are worth dwelling on. The first is the bracket: four of five stages are unattended, which is what converts planning from an act of production into an act of supervision. The second is the dashed return path, which is the subject of the next section and is the single most commonly omitted component in implementations of this architecture.
What each stage actually contains
The stages are easy to state and are worth stating precisely, because the failure modes differ at each one.
| Stage | What it produces | Characteristic failure |
|---|---|---|
| 01 Sense | One assembled view of every relevant input, current as of the cycle, entered once | Local master files survive alongside it, so the pipeline becomes a fifth version rather than the only one |
| 02 Predict | An unconstrained distribution per item and period, with controllable levers modelled in | The distribution is produced and then discarded at the interface, leaving a point estimate |
| 03 Price | Every candidate outcome valued against the signed ledger | No ledger exists, so this stage silently degenerates into a service-level rule |
| 04 Decide | Ranked options in currency under real constraints, with the tail exposed | The ranking is not inspectable, so planners cannot see why the top option won and do not trust it |
| 05 Commit | An approved decision, and a recorded reason wherever it was overruled | Overrides are treated as exceptions to be argued down rather than as the input they are |
Note that three of the five characteristic failures are organisational rather than technical. The pipeline is not defeated by engineering difficulty; it is defeated by the parallel spreadsheet nobody was told to stop maintaining. This is the recurring theme of the series and the reason Paper 05 exists.
The override is the interface
In the current process, a planner who disagrees with a number changes it, and the reasoning evaporates. Nothing records that the change was made because a major customer had signalled a delay, or because the promotional calendar had moved, or because the same item had behaved strangely the previous two Februaries. The knowledge stays with the individual and leaves when they do.
In the target process the system asks for three fields: a reason code, a short free-text note, and the new value. All three return to the platform. Next cycle, the recommendation already reflects what the planner knew and the model did not.
Overriding is not a failure of the system. It is the mechanism by which the system acquires what its operators know.
Both failure modes here are common and both are expensive. An organisation that treats overrides as a compliance problem, measuring and suppressing them to make its automation look successful, destroys the only learning channel the architecture has, and will find its models stagnant within a year. An organisation that permits untracked overrides has bought a recommendation engine nobody follows and will quietly revert to the previous process while continuing to pay maintenance.
The design implication is specific and often resisted: overriding must be easy. Three fields, no approval workflow, no justification to a supervisor. Every additional obstacle placed in front of an override is an incentive to work around the system entirely, and a system worked around learns nothing.
Uniform logic, local data, local parameters
Any multi-market or multi-site deployment runs into a predictable conflict, and conflating two different things is how global process programmes die.
The logic should be uniform. One sequence of stages, one ledger structure, one definition of each term, one meaning for the word forecast. This is genuinely worth enforcing, and the reconciliation burden described in Paper 01 is what it buys back.
The data is local, and so are the parameters. Each unit brings its own demand signal, channel structure, lead times and constraints. More subtly, the same model fitted per market produces different coefficients, and it should. A price elasticity estimated centrally and imposed uniformly is not standardisation, it is a modelling error wearing standardisation's clothes, and the regions that resist it are correct to.
Sequencing deserves more attention than transformation plans usually give it. Start where a pilot already works and the team is receptive, even if that unit is small. Put the largest and most tool-resistant unit last, by design, so that it can watch the system work elsewhere before being asked to adopt it.
The most expensive sequencing error in this class of programme
Starting with the biggest unit because it carries the most value. The first deployment is not primarily delivering value; it is manufacturing evidence. Evidence produced in a small, willing unit is cheap and fast. Evidence produced in a large, resistant one is expensive, slow and contested regardless of the result. Value capture follows credible evidence, and it follows quickly.
Adding simulation, and adding it last
Once the data is assembled, the estimate is a distribution and every option is priced, a capability becomes available that was not previously possible: testing a decision under real uncertainty before committing to it, rather than explaining it afterwards.
We call this the Lab. It runs the same models and the same ledger, offline, against futures that have not happened. A mild season and a severe one. A competitor launch mid-quarter. A supplier failure at the worst possible moment. Each plausible future is priced, and the answer that comes back is a distribution rather than a single figure: what a proposed commitment is worth on average, and what it costs in the tail if the world does not cooperate.
This is the component executives find most interesting and the one we most consistently advise deferring. Simulation without a ledger produces scenarios nobody can price, which generates activity and no decisions. The correct order is ledger, then flow, then Lab. Organisations that begin with simulation because it is the intellectually appealing part arrive, eighteen months later, at the ledger, having spent both the budget and the credibility.
What to build first
The architecture above describes a destination. The route to it is narrower than most roadmaps suggest, and deliberately so.
- Pick one decision that recurs, matters, and is currently made by assembly. Bound it to a single unit. Resist the pressure to scope it across the portfolio, which converts a fourteen-week proof into a two-year programme.
- Build the ledger for that decision, and only that decision. Six lines, signed. Paper 02 sets out the exercise in detail.
- Price the last two years of decisions your organisation actually made. Then price what a simple policy would have decided instead. This is the artifact that funds everything after it, and Paper 06 is devoted to producing it credibly.
- Run the policy in parallel before you rely on it. The existing process continues to make the real decisions while the policy makes shadow ones. Compare weekly, in currency, and record every divergence and its reason.
- Automate the pipeline for that one decision, then widen. Automation is worth doing once the decision is priced and proven, and close to worthless before.
Note that steps one through three require no software procurement. The most common objection to this sequence is that it is too slow to matter. In practice it is considerably faster than the alternative, because a priced backtest can be produced in a quarter and a platform selection cannot.