No business of any size replaces its record to get this. Autonomy arrives the way every earlier change of this size arrived: alongside the systems already in place, one domain at a time, in the order set by what a mistake costs.
The history of this field is a history of parallel running. When the material calculation was first put on a machine, the planning department that had been doing it by hand did not close; it checked the output for a year, and in most plants it kept its card files for longer than that. When integrated suites arrived, the departmental systems they were meant to subsume stayed up, sometimes for a decade, because a functioning process is worth more than a tidy diagram. When operation of the software moved off the premises, it moved module by module, and the companies that tried to move everything at once are the ones that produced the cautionary literature.
That is not an argument about caution. It is what the record shows about how a system that a business depends on is actually changed. A company cannot stop planning while it re-plans how it plans, so the new arrangement has to earn its place next to the old one and take work from it gradually. Every era on the history page arrived this way, from material requirements planning onward, and none of them arrived by a date on which the previous thing was switched off.
What is different here is what is being transferred. The earlier transitions moved a calculation, a database or an operating cost from one place to another, and a company could judge the result by whether the numbers still came out. This one moves authority, and authority is transferred by a person who can refuse, one grant at a time, in the face of a consequence they will personally answer for. That makes the pace of this transition a governance pace, not an engineering one. It is slower than the software is ready for, and no part of that delay is technical debt.
A programme that treats the transition as a replacement therefore takes two risks at once: the migration risk of moving the record, and the novel risk of letting software decide. It will be judged on the first, which is the one everybody already knows how to argue about, and the second will never be reached. The sequence that works is the unglamorous one. Leave the record where it is, put the loop beside it, and let the question of what to retire come up years later, when the answer is obvious because nobody is using the old planning module any more.
Running alongside means something specific. The ledger and the subledgers stay authoritative for what they are authoritative for. The autonomous part reads their state, decides, and writes the consequence back through the same interfaces a keyed transaction uses, so that its entries land in the same population, meet the same validation and are sampled by the same auditor. What it adds is a second record that did not exist before, holding what was observed and decided and under which grant, joined to the ledger entry by reference. That division is set out on the objections page. Taking it as settled leaves the practical question: what the incumbent record has to be able to do.
The list is short and it is unforgiving, because every item on it is a property the existing system either has or has to be given. None of it is exotic. All of it is the difference between a loop that closes and a demonstration that closes.
Where the incumbent cannot supply one of these, the boundary moves instead of disappearing. The decision layer then has to hold its own copy of the state it needs, and a copy has to be reconciled, which means the programme has acquired a reconciliation it did not have before and a class of difference nobody owns. That is a legitimate engineering answer and an expensive one, so it belongs in the estimate at its real weight, never in an integration line. The honest phrasing for a business case is that the gap in the old system is being paid for in the new one.
There is a second requirement, and it is not technical. The people who operate the incumbent have to be willing for something other than a person to write to it. That permission is usually held by a controller or a head of operations who has spent years keeping keyed entries clean, whose instinct against an unattended write path is well earned, and who is right to ask what happens when it is wrong. The answer to that question is the grant, the reversal procedure and the after the fact check, and it is more persuasive when those exist before the conversation begins.
Programmes are usually sequenced by department, because that is how budgets and steering committees are shaped. It is the wrong axis. A finance function contains both the safest work in the company and some of the most dangerous, and so does a supply chain function: clearing a matched receipt and committing to a twelve month contract sit in the same org chart and have nothing else in common. Sequencing by department means the order is set by who sponsored the programme, and the first serious incident is then a matter of chance, not of design.
The axis that works is what a wrong action costs and how quickly anybody would know. It gives four bands, and they tend to be entered in order. The point of the order is not that the later bands are forbidden. It is that each one should be entered with the evidence the previous band produced, because a grant is easier to widen when the argument for widening it is a measured record rather than a projection.
| Band | What a mistake costs | How fast it shows | Typical work |
|---|---|---|---|
| 01Internal and reversible | Nothing has left the building. A wrong result is corrected by a later entry and the correction costs the time it took. | Same day, by a check the system already runs | Matching, clearing, reconciliation of accounts against statements, accruals inside tolerance, classification and coding. |
| 02Committing, inside a ceiling | Something is promised to somebody outside, at a value a person has capped in advance and against terms already agreed. | Days, by acknowledgement or delivery against the commitment | Replenishment on the approved supplier list, transfers between sites, routine shift cover, payment inside agreed terms. |
| 03Trading one resource for another | Two classes are exchanged to hold an objective, so the loss shows up as a worse position rather than a wrong entry, and it may not look like an error at all. | Weeks, and only against the objective the trade was made to serve | Expedited freight against stock cover, overtime against a delivery date, cash against carrying cost. |
| 04Binding beyond the horizon | The business is committed past the point where reversal is available, and the counterparty holds a right the company cannot take back. | Months, sometimes at the next period a lawyer reads the file | Contracts, hiring, long tenor instruments, anything that creates an obligation a later decision cannot unwind. |
Two things follow from reading the order this way. The first is that a business will hold different levels in different places at the same time, permanently, and that is a correct end state, not an incomplete rollout. The maturity model is graded per resource class for exactly this reason, and a company describing itself by a single number has averaged away the only information in the assessment.
The second is that the fourth band may be where the road ends. Nothing in the argument requires that a system ever commit a business past the point of reversal, and allocate across resources describes a system trading inside an envelope a person set, not one signing whatever it judges to be worth signing. A company that runs the first three bands well and keeps the fourth with people has not stalled. It has drawn the line where it intends to answer for what happens, which is the only place the line was ever going to be drawn.
Enterprise software is often described as three layers: the system of record that holds what is true, the system of intelligence that works out what it means, and the system of action that does something about it. For thirty years these have been separate products with separate buyers, and the joins between them have been a large industry in their own right. The argument worth taking seriously is that autonomy collapses the three into one, and it is not a marketing argument. It follows from what the loop requires.
The case for collapse is this. A system that decides needs the state at the moment it decides, and every copy of state is a copy that can be stale. A system that acts needs the action and the record of the action to be the same event, or reconciliation between them becomes a standing cost. A system that is to be reviewed later needs the evidence, the policy version and the outcome retained together, and three systems retain three partial views on three schedules. Each join between the layers is also a place the loop can break without anybody noticing, because a queue between two systems looks healthy right up to the moment its contents stop mattering. Put those together and the separation starts to look like an artefact of an era in which the record could not decide anything, never a property anybody designed for.
The counter-argument is at least as strong, and it is not conservatism. The authority of a record comes from being controlled, reconciled and signed, and one of the oldest ways to control it is that the thing acting is not the thing keeping the score. Segregation of duties has already been weakened by letting one system raise an obligation and settle it; merging the record into that same system removes the last independent surface an after-the-fact check can be run against. Retention schedules differ too: a ledger is kept for statutory periods set by somebody outside the company, while a decision layer will be rewritten several times inside one of those periods, and merging them subjects the slow thing to the release cadence of the fast one. There is a commercial argument on the same side, which is that a single system holding record, intelligence and action is a single system a company cannot leave.
How that resolves is not known, and it is carried as an open question. What can be said is narrower. The collapse, if it happens, is an outcome rather than a route: the eventual consequence of a decision layer proving itself over years, not a thing a company buys in order to begin. Nothing here argues that the existing systems stop being necessary, and the position held is duller than either extreme. The record keeps doing what it does, it keeps being the thing the numbers are proved against, and what moves is where the deciding happens.
A transition is a sequence of grants, and each grant is somebody agreeing to answer for a total.
The objections