The Cost of Waiting Is Not Neutral
Most rollout plans handle execution authority the same way. Everyone agrees it needs sorting out. Everyone agrees it isn't sorted today. So it goes on the roadmap — after the AI pilot, after the platform decision, after things settle down.
The thinking behind that is reasonable enough: define authority properly when we're ready, then apply it to whatever state exists at that point. Catch up later.
It doesn't work like that. And the reason it doesn't work changes what your system looks like by the time you get to it.
The records don't sit still
Take an operation that ingests supplier confirmations automatically. A confirmation arrives, a record is created, and because the system is a system of record, that record becomes real the moment it exists. Nobody said "proceed" — but nothing was waiting for them to. Downstream processes don't check for approval. They check for existence.
Goods-in books against it. The stock ledger updates. Sales allocates against the new stock. A pick is generated. A dispatch note references the pick. An invoice references the dispatch.
By the time anyone notices the original confirmation had a wrong quantity, there are several records downstream of it, each one real, each one acted upon, each one referenced by at least one other. You can correct the original. You cannot correct the fact that the others were created in a state where nobody was permitted, or denied, to create them. The act happened. The record proved it.
Authority applied later can only face forwards
Here's where it goes wrong. When you eventually define areal execution authority, you can apply it to new records from that day. You cannot apply it to the records already in the database — not because of a technical limit, but because "should this record have been allowed?" has no meaningful answer once it exists and has been referenced by others.
You can audit it. You can flag it. You can treat it as suspect. What you cannot do is turn it into a decision nobody made. Authority governs whether something happens. It cannot govern whether something has already happened.
If your new policy says "POs over £10k need explicit permission," and half your live POs were created before the policy existed, the policy cannot reach them. You're left grandfathering the old ones, freezing them for human review (which reintroduces the labour you were removing), or rebuilding state by hand. Nobody rebuilds state by hand.
The set grows while you wait
The common view is that delay is a tax — per day, steady rate. That's wrong in a specific way.
The ungoverned set grows from two sources. The first is new ingestion. The second is internal. Records reference other records. A pick references a stock movement references a GRN references a PO. When a new record is created against records that were themselves created without authority, it inherits the same condition. The new record isn't the problem. What it depends on is.
Stop ingestion entirely tomorrow and the set still grows, because downstream processes continue generating records that reference the existing ones. You can only freeze the set by freezing the operation, and nobody freezes the operation.
The trade-off
You can defer the hard work and buy time. Or you can define authority now and govern a smaller set. You cannot defer and keep your options open.
The assumption worth naming is this: that authority can be bolted on later and applied to the records already in the system. It's the shape of almost every governance roadmap. And it treats those records as if they're still waiting — addressable, inert, available to be brought under whatever rules you eventually write. They aren't. By the time you get there they're referenced, downstream, load-bearing, and outside the reach of anything you define.
The cost of waiting isn't what you pay each day. It's what you can never govern afterwards.