Suppose a fictional workshop produces customised physical goods.
Demand is available. Before a request can become work, someone with the relevant judgement must turn it into a design and specification packet. Software then prepares production instructions and coordinates an upstream process with ample capacity. The resulting work in progress waits for one scarce finalising capability. Completed goods still require release by someone who holds that authority.
The workshop can keep its software busy. It can prepare packets earlier, start more work and fill the queue in front of finalisation. On a local dashboard, utilisation rises. But the workshop releases no more goods. More cash is tied up in unfinished work, lead times lengthen and the finalising capability is no less scarce. The local change succeeds by its own measure while the company becomes worse off.
Busy is not the objective
A business does not benefit because one resource does more. It benefits when the consequences for the business improve. The current bottleneck matters because it limits which better outcomes the business can reach from where it stands.
That does not make throughput a master score. For each proposed allocation, the workshop needs a complete receipt: which qualified demand can be served, which cash is consumed or preserved, how much work remains unfinished, what happens to lead time, quality and reliability, which obligations are met, and which irreversible actions or authorities are used. Software executes transformations within that account; it does not define the account’s boundary.
The account can be complete only in a bounded sense. A complete business receipt records everything the declared types and rules require. It is not omniscient about consequences the business has not represented, evidence it cannot observe or facts outside its trust boundary. Formal precision cannot repair an omitted premise.
The bottleneck tells the workshop where a change might expand its choices. It does not decide what the workshop ought to value among those choices.
A resource has an identity and an opportunity cost
Calling all of these things “capacity” hides the distinctions that make an allocation real. Cash is consumed when it is spent. Qualified attention is available only from someone able to make the relevant judgement, and time used here cannot also be used elsewhere. Work in progress is not spare capacity at all; it is work already funded but not yet turned into a releasable result. Software capacity can be reusable and abundant. The finalising capability is an exact combination of suitable equipment, setup, skill and available time. Release authority is permission to expose the business to a consequence, not another name for technical competence.
These resources are identity-bound. The identity may be opaque; what matters is that the account distinguishes this capability, from this source, in this state, with these permissions and replenishment rules. An hour of general availability cannot satisfy a requirement for an hour of qualified judgement. Spare computation cannot finalise a physical item. The ability to prepare an item does not grant permission to release it.
Money does not make the resources instantly interchangeable. It may fund a new capability, but acquisition is itself a process. A second finalising capability must be available from a real source. It may require lead time, setup and qualified attention before it can be used. The cash spent on it cannot fund something else. If an allocation omits those transformations, it has not found capacity; it has invented it.
Only reachable allocations belong in the comparison
We call this end-to-end business mechanism Constructive Resource Transformation. “Constructive” carries most of the meaning. The system does not imagine arbitrary combinations of resources, score them and choose the most attractive fiction. It builds possible successor states from the measured present, one permitted transformation at a time.
Buying more upstream software capacity is possible, but it leaves the same finalising constraint and creates more WIP. Capping the release of packets into production is also possible. It lowers upstream utilisation, yet preserves cash and shortens the queue without reducing what the finalising capability can complete. The second option is no worse for released output and better for the resources the first option wastes. The extra software capacity should fall out of the comparison.
Other choices are less easily ordered. The workshop might acquire a temporary second finalising capability for a bounded trial. That could serve more demand, but it consumes cash and qualified attention and introduces setup and reliability uncertainty. Or the workshop could restrict the range of customisation so that the existing finalising capability handles work more quickly. That preserves more cash, but refuses some demand and changes what customers can receive. A hard cash floor, a quality obligation or a missing authority may rule an option out entirely. Among the remaining options, a gain on one consequence may require a sacrifice on another.
The ordinary rule is simple: discard an allocation only when another reachable allocation is at least as good on every relevant company consequence and better on at least one. Keep the rest visible. That remainder is a Pareto frontier. It is not a ranking disguised by a technical name. It is the honest shortlist left when the system refuses to invent an exchange rate between cash, delay, quality and risk. Choosing among those trade-offs remains an explicit business decision.
A perfect local result can still be irrelevant
The same whole-company comparison supplies a severe test for local improvement. Suppose the proposed change is a better software effect for producing the design packet. In this fictional workshop, the current packets already satisfy the acceptance contract. Their quality causes no rejection, consumes no extra finalising time and opens no route that is currently closed.
Now grant the proposed effect counterfactual perfection on that property. Every packet is flawless. Then reconstruct the workshop's reachable outcomes. The same finalising capability remains scarce. The same number of goods can be released. No WIP limit, obligation or authority boundary changes. The local quality measure has improved as far as it possibly can, but the reachable whole-company frontier has not moved.
That does not mean quality is unimportant. If packet quality were causing rework, violating a hard obligation or consuming finalising time, improving it could change the frontier. Nor does present irrelevance imply permanent irrelevance: the property may matter after another constraint moves. The test is narrower and more useful. Does this local change alter what the company can now reach? If even perfection does not, there is no present global value to manufacture with a score.
A forecast cannot become the measured present
Suppose the workshop chooses the trial of a second finalising capability. Before acting, it can simulate possible futures. Estimates of acquisition cost, setup time, output quality and reliability can show that the trial is feasible under some assumptions. They cannot show that those assumptions have become true.
The distinction has to survive contact with the workflow. A simulated world is labelled with its assumptions and the version of the measured present from which it was derived. A measured receipt is produced only after an authorised effect occurs and records what happened to the identified resources. Renaming a forecast, copying its values or selecting its most convenient branch cannot turn it into an observation.
Simulation can still support action. The people responsible for the business can preauthorise a bounded trial: a cash limit, a permitted setup window, quality and reliability floors, explicit stop conditions, and no transfer of release authority. The system may reserve resources or schedule work within that grant. The conditional rule is fixed before the result is known, so the trial cannot quietly change its success condition afterwards. But the grant authorises this trial, not every decision that might follow it.
Then the bottleneck moves
Inside the thought experiment, suppose the workshop now observes the trial. The goods land inside the forecast quality range. The extra finalising capability drains the waiting WIP. But measured setup and hand-off time consume more qualified attention than the forecast allowed for. The workshop can now finalise work faster than it can turn new demand into production-ready design and specification packets.
The target property behaved as expected, yet the economics changed. Cash has been spent, WIP has fallen, actual elapsed time is known and the available pattern of qualified attention is different. Finalisation is no longer the current constraint. Qualification is.
This is the ongoing-improvement shape made familiar by Eliyahu M. Goldratt and Jeff Cox's 1984 management novel, The Goal: A Process of Ongoing Improvement: improving the system changes the place at which it is constrained. A typed resource account makes the consequence precise. Once empirical evidence has constructed a successor present, the old allocation problem is over.
The next action cannot be selected from the old forecast as though the trial merely revealed which precomputed branch came true. The workshop must start from what is now measured: its remaining cash, current WIP, observed setup time, demonstrated reliability, available qualified attention, live obligations and unchanged authority boundaries. From that state it constructs the reachable allocations again and compares their complete receipts again. A change to measured time, cost or reliability may make a different intervention valuable even when quality stayed comfortably inside its predicted range.
The compiler does not get the deciding vote
There is useful automation in this loop. By a business compiler, we mean a system that applies the business's typed distinctions when it constructs and checks possible changes. It can reject an allocation that spends unavailable cash, uses the same person's attention twice, assumes an unobtainable capability, exceeds a WIP limit or crosses an authority boundary. It can construct feasible alternatives, expose their opportunity costs, remove those that are worse on every recorded consequence and preserve exact receipts for what was forecast and what was measured.
It cannot create the resources that the business lacks. It cannot prove an external offer, a physical observation or a human judgement merely by representing it. It cannot choose between honest trade-offs without an explicit decision relation. It cannot turn competence into release authority or make an irreversible production decision because a simulation looked favourable.
The human boundary is therefore more exact than “keep a person in the loop”. People set hard obligations, decide which trade-offs they accept, grant bounded spending and action authority, and approve irreversible release. The formal system's job is to prevent those decisions from being disguised as capacity arithmetic.
At the start of the fictional workshop's loop, abundant upstream software looked like an opportunity and scarce finalisation was the constraint. After the bounded allocation and its measured receipt, qualified attention became the constraint instead. The durable method is not to optimise the old picture harder. It is to ask whether each resource is actually obtainable, which exact scarce resources and opportunity costs fund it, which whole-company consequence changes, whether the evidence is forecast or observation, and who has authority to act—then rebuild the question when the present changes.
The bottleneck moving is not a failure of the allocation. It is the reason the allocation loop must continue.