Allocation Becomes Computational

When the market can compute the allocation, price stops being the last human decision.

Memo #122: When the Market Decides What Gets Made projected the market-scale claim: once Executable Economy loops run across every participant in a market, allocation itself — not just execution — can become something the market computes rather than something it merely reports. This memo stays inside that same projection and asks a narrower, mechanism-level question #122 raised but didn't resolve: what does a market actually have to do, architecturally, to compute an allocation rather than merely react to a price?

Today, markets aggregate information into prices, and businesses use those prices to decide what to buy, make, move, hold, or sell. Even when those decisions are heavily automated, the allocation function usually remains distributed across participants: each business decides how much capacity to commit, which orders to accept, which resources to reserve, and where to direct them. #122 projected a market in which that allocation function can itself be computed. This memo asks what has to be true for that projection to hold, and what changes once it does.

The distinction is not faster execution. It is that the system determining who gets what, when, and under which constraints becomes an executable computational function rather than a decision distributed across human planning processes.

The next layer after allocation

Memo #120: From Agentic Commerce to Agentic Markets argued that a supply-side resource can become addressable: an agent can query it and commit against it, not merely read a price someone else set. Memo #121: Executable Economy projected what follows once a signal can trigger an action directly, so long as the action clears the Physical Intervention Threshold — the planning cycle removed, the exception gate not. Memo #122 moved one level higher again: once every participant in a market runs a loop like that, the market's own allocation — not just one firm's execution — becomes something computed rather than negotiated.

This memo goes one level deeper into #122's claim, not one level higher than it. If resources are addressable, and actions can execute against live signals, and the market's allocation itself can be computed, the open question is what the system computing that allocation actually has to represent and resolve.

The conventional structure is:

Signal → Price → Human allocation decision → Resource commitment

The Executable Economy moves the middle step behind a threshold — an agent applies the rule in the Execution Layer, and an action that doesn't clear the Physical Intervention Threshold escalates to the Judgment Layer, the Steward:

Signal → Execution Layer, gated by threshold → Resource commitment

Market Computation adds a further layer, which is where this memo starts:

Market state → Allocation rule → Resource commitment

The difference is subtle but fundamental. The first two describe how a participant acts. The third describes how the system decides between competing claims on the same scarce resource — #122's claim. This memo asks what has to be built for that claim to be more than a name.

The distinction underneath all three is not human versus machine. It is a rule set at design time versus a decision made case by case. Everything below is that distinction worked through in detail.

Price is not allocation

A price tells a market something about value, scarcity, demand, or willingness to pay. It does not, by itself, determine allocation.

Two buyers can face the same price while competing for the same production slot, the same logistics capacity, the same inventory, the same energy capacity, or the same scarce service window. The price is information. Allocation is the decision about what happens to the scarce resource.

That distinction matters because much of what is described as computational commerce still leaves allocation outside the computation. A system can dynamically change price. It can expose inventory in real time. It can accept orders automatically. It can optimize a route. It can schedule production. None of that necessarily means the market is computing allocation — all of it can run while the underlying allocation function stays fragmented across participants, contracts, planners, and exception processes.

An allocation becomes computational when the system can evaluate competing claims against the available resource and determine the next valid commitment according to a rule set at design time, not negotiated case by case.

This is not an exchange matching engine either

Financial exchanges already compute allocation over standardized, fungible claims — a share, a contract, a unit of currency. That is real evidence some forms of allocation can be computational, but it does not establish the harder case #122's projection concerns: allocating physical and operational resources — manufacturing capacity, logistics capacity, inventory, energy, service capacity, production time — whose state, constraints, and consequences exist outside the matching system itself. That is where Memo #120's addressability requirement becomes important: if the resource cannot be represented reliably, the allocation function cannot compute against it, no matter how good the matching logic is.

The scarce resource changes the problem

Consider a simple case. A production line has 100 available hours next week. Ten buyers want capacity.

An ordinary system can expose the capacity, collect orders, adjust the price, and allow each buyer to negotiate. An Executable Economy can respond to changing demand and capacity signals without waiting for the next planning meeting. A computational allocation system goes further: it can evaluate the available capacity against competing claims and compute an allocation according to defined constraints.

Available capacity → eligible demand → allocation rule → commitment

The allocation rule might incorporate price. It might incorporate delivery constraints, priority, contractual rights, minimum order sizes, or other conditions specified in advance. The important point is not which rule wins. The important point is that the rule itself becomes executable. The market is no longer merely producing a price that participants interpret. It is producing an allocation.

From market information to market state

This changes what it means for a resource to be addressable. In #120, addressability means the resource can be queried and committed against. At the next layer, the system must also be able to represent enough state to compute competing claims against that resource. That requires more than inventory visibility — it requires a machine-readable representation of what resource exists, what portion is available, who can claim it, under what conditions, what commitments already exist, what constraints apply, and what happens when claims conflict.

This is why allocation is harder than execution. Execution can follow a decision. Allocation has to produce the decision. Execution asks: what action should this system take? Allocation asks: which participant should receive this scarce resource? The first question is what the Execution Layer already answers, one action at a time, gated by the Physical Intervention Threshold. The second is the question #122 named and this memo goes deeper into. The second problem contains the first, but adds competition.

The market becomes a decision boundary

Once allocation is computational, the market itself becomes part of the decision architecture. This does not mean the market becomes autonomous in every sense. Human judgment can still define the allocation rule itself, eligibility, priorities, the Physical Intervention Threshold, acceptable risk, and contractual boundaries — and still decide what happens when the rule encounters a conflict it cannot resolve.

What changes is where the recurring allocation decision is made. The rule can be set once, in the Execution Layer, the same way Arco already separates recurring decisions from the Judgment Layer's exception handling elsewhere in an autonomous business. The allocation can then be computed repeatedly against changing market state — design time versus case by case, again, now at the level of the whole market.

The loop gets another layer

Memo #121 closes an operational loop: demand, price, allocation, production, logistics, market, demand. But #121 deliberately treated allocation as one input among several the loop weighs on each pass, gated by the Physical Intervention Threshold — not as something computed in its own right. Memo #122 asked what happens once allocation itself becomes computational, market-wide. This memo asks what such a loop actually has to represent for that to be more than a name.

The loop becomes:

Market state → Allocation rule → Commitment → Execution → New market state

Now the market does not merely transmit information between participants. It recomputes a new distribution of scarce resources as conditions change, rather than running as a permanently active process. A new order can change the allocation, a cancelled commitment can release capacity, a production constraint can remove available supply, a logistics disruption can change eligibility, and a price change can alter competing claims — each one a new market state the rule has to compute against, not a report that waits for the next cycle.

The output of the allocation function becomes the next state of the market. That is a different architecture from a market in which participants periodically negotiate and then execute the resulting commitments.

This is not dynamic pricing

A business can have dynamic pricing, real-time inventory, automated purchasing, even autonomous execution under an Executable Economy, without computational allocation — none of those requires the system to resolve competing claims on a scarce resource according to a rule it applies consistently across every claim.

The test: did the system just do that, without a human deciding the recurring case? If not, allocation has not yet become computational.

What has to be true first

Three conditions have to converge.

First, the resource must be addressable. The system must be able to represent the resource as something that can be queried and committed against, not merely described in a feed.

Second, execution must be executable in the sense #121 projects. The resulting allocation must be capable of triggering action through the Execution Layer, gated by the Physical Intervention Threshold, without waiting for the next human planning cycle.

Third, the allocation rule must itself be specified in advance, in the Execution Layer, not left to a planner's judgment case by case. Someone — the Steward, under the Stewardship Model — has to define how competing claims are resolved. That rule is not necessarily a price auction; it could incorporate price, priority, contractual rights, timing, utilization, geography, or other constraints. But if the rule exists only in a planner's judgment, allocation has not become computational.

The sequence matters: Addressability → Executability → Market Computation. Skipping the first two does not produce the third.

The new risk is not speed

Memo #121 argued that speed without calibration creates a faster way to be wrong. Computational allocation introduces a related but distinct failure mode. A wrong execution affects one commitment, with its own Rollback Cost. A wrong allocation rule can propagate that Rollback Cost across every commitment the rule governs — the same scaling Memo #122 named at market level. That changes what the Physical Intervention Threshold has to be calibrated against. The relevant question is no longer only "how costly is this action to reverse?" It becomes "how much of the market can this rule move before a human can intervene?"

A computational allocation system therefore needs boundaries around the allocation function itself, not just around individual actions. Some allocations are routine and reversible; others consume scarce capacity, create contractual commitments, or cascade into effects well beyond the claim being resolved. The more consequential the allocation, the more the Steward has to define in advance: what the rule may allocate on its own, what escalates to the Judgment Layer, what can be rolled back and at what cost, what happens when the rule meets a state it wasn't built for, and how quickly allocation can be suspended if it needs to be. The Physical Intervention Threshold does not disappear when allocation becomes computational. It governs a rule instead of a single action, which is a different calibration problem, not a smaller one.

The Operator's Verdict

#120 made the resource visible to agents. #121 made the response to it actionable without a planning cycle. #122 projected that a market could compute who receives it. This memo has argued what that third step actually requires: a resource represented as more than a feed, a rule specified before the fact, and a Physical Intervention Threshold calibrated to the rule's own Rollback Cost, not just to each action's.

This is a hypothesis about what a computed allocation system would have to be built from, not a build plan Arco or any operator is executing. If it holds, an operator moving toward it would not start by automating negotiation or adding another pricing algorithm — the implication would be to first identify the scarce resources whose allocation currently consumes human judgment, make those resources machine-addressable, specify the recurring allocation rules in advance rather than case by case, and measure the exceptions. The test would not be whether the system can calculate an answer. It would be whether it can commit that answer to the resource without a human making the same allocation decision again.

Technology makes allocation computable. The rule determines what the market does with scarcity.