Choosing an Instance Is a Prediction, and the Gap Is Billed by the Hour
The cloud's founding promise was that nobody would have to guess what machine they needed ever again. What arrived instead was a catalog. You still guess, from a list of shapes somebody defined in advance, before the workload runs, on a machine you will never see, and you pay for the difference between the guess and the need for as long as the instance exists.
Every substrate so far has been a machine somebody owns. This one is a machine nobody in the conversation owns, which changes the argument in a specific way: the fixed commitment is no longer only an engineering decision, it is a purchasing decision, and the cost of getting it wrong appears on an invoice rather than in a profiler. Selecting an instance type is a prediction about hardware, made in advance, by someone who will never see the machine, chosen from a catalog of shapes defined by a party with no knowledge of the workload. The gap between the shape reserved and the work actually done is not absorbed quietly. It is metered.
This paper argues that an instance catalog is the same mechanism Paper 1 named as a ceiling (selection among prebuilt options rather than generation against what is present) relocated from software distribution to hardware procurement, and that the compiled artifact and the provisioned instance are therefore the same commitment made twice against the same unknown. It then reports what has actually been run: Essence was validated on AWS in work with Rowan University's Digital Engineering Hub, producing the acceleration and energy results this series cites, and the same package was replicated on Oracle Cloud Infrastructure and Google Cloud Platform. The replication is the part worth attention, because it is not a portability convenience but the direct consequence of the argument: an artifact that resolves against whatever machine it lands on does not experience three clouds as three targets. The paper also states where this stops, and defers the contractual half of the cloud argument to The Governed Machine, which has already covered it.
The original argument for renting rather than owning computers was not primarily about capital. It was about the impossibility of prediction. An organization buying hardware had to forecast demand years ahead, buy for a peak that might never arrive, and live with the result until the depreciation schedule allowed otherwise. Every one of those forecasts was wrong, and the industry knew it.
Elasticity was the answer, and as a proposition it is excellent: stop guessing, take what you need when you need it, stop paying when you stop needing it. If that were what the cloud delivered, this paper would not exist, because the cloud would already be an implementation of everything this series argues for.
What it delivers instead is a version of the promise that kept the prediction and moved it. You do not forecast for three years, which is a genuine improvement. You forecast for the workload, in advance, by choosing from a catalog of machine shapes that somebody else defined without knowing anything about your work, and the machine you receive is never inspected by the person who chose it.
Paper 1 drew a line between generating instructions after inspecting the machine and selecting among options built in advance, and called the second a ceiling: the best available outcome is bounded by whichever variants somebody thought to build. Paper 4 found the same distinction inside Android, where the runtime generates and the delivery format selects.
An instance catalog is selection, in exactly that sense, applied to hardware. The shapes are numerous and carefully designed, and the ceiling is unaffected by how many there are. A workload gets the closest available fit to a guess made before it ran. It does not get a machine assembled for it, and the residual (the memory you reserved and did not use, the cores idle while one saturates, the accelerator attached to a shape you took for its network characteristics) is not waste in the sense of a bug. It is the arithmetic consequence of choosing from a list.
The difference from every other substrate in this series is that here the residual has a price attached and the price runs continuously. Elsewhere the fixed commitment costs capability, which is invisible because nobody sees the faster version that was not generated. In the cloud it costs money, every hour, itemized, and organizations still under-adjust, because adjusting requires the same prediction that produced the problem.
Put the two decisions side by side and the structure becomes hard to unsee.
The artifact was compiled against an assumed machine, before that machine was known, and it cannot be renegotiated at execution because the assumption is inside the binary. The instance was selected against an assumed workload, before that workload ran, and it cannot be renegotiated at execution because the shape is what was provisioned. Two commitments, made in advance, against the same unknown, by different departments who do not think of themselves as solving the same problem. One is made by engineering and paid in forfeited capability; the other is made by whoever owns the cloud bill and paid in currency.
They also compound. A binary that cannot use an accelerator makes the instance carrying that accelerator a waste; an instance chosen without knowing what the binary can use guarantees a mismatch in one direction or the other. Organizations respond by standardizing on conservative shapes that everything runs acceptably on, which is Paper 5's conformance floor reinvented as a procurement policy, with the same result: nothing runs badly and nothing runs as well as the hardware allows.
The evidence available on this substrate is more direct than on most, so it is worth separating what was validated from what was replicated.
Validated: the acceleration and energy results this series cites (between 20× and 114× faster, and up to 99.7% less energy) were produced in work on AWS with Rowan University's Digital Engineering Hub, on specific workloads under specific conditions. AWS is reachable through the nClouds partner path. Those figures are the series' primary quantitative claim, and every paper that cites them states their scope.
Replicated: the same Essence package was run on Oracle Cloud Infrastructure and on Google Cloud Platform. Not a port, not a cloud-specific edition, not a build per provider. The same package.
The second of those is easy to read as a portability footnote and is actually the argument. Three hyperscalers differ in hypervisor, in instance taxonomy, in host hardware generations, in network fabric and in the accelerators they offer, and a vendor shipping a compiled artifact experiences those differences as three integration efforts and a support matrix. An artifact that decides its instructions after inspecting the machine experiences them as three machines, which is what it was built to handle. Paper 9 makes the extreme version of this point with the same build running from hyperscaler infrastructure down to a smartwatch; the cloud case is the same property observed where the commercial stakes are highest.
Of the two headline results, acceleration is the one that gets attention and energy is the one that matters most on this particular substrate, for a reason specific to how the cloud is built and sold.
In a rented datacenter, energy is not an environmental line item sitting beside the compute cost. It is substantially upstream of the compute cost: power and the cooling to remove it drive the facility economics that instance prices are derived from, and the constraint that increasingly determines whether new capacity can be built at all is the ability to get power to the site. A reduction in the energy required to complete a unit of work is therefore not only a sustainability claim, which is how it is usually framed, including by this company. It is a claim about the cost basis of the thing being rented and about how much work a power-limited facility can do.
The figure needs its conditions attached every time, and this paper attaches them: up to 99.7% energy reduction, on specific workloads, under specific conditions, in the validation work described in Section 04. It is not a fleet average, it is not a general property of running on this platform, and a reader evaluating it should ask what the workload was.
No partnership or endorsement. AWS, OCI, GCP, nClouds and Rowan University's Digital Engineering Hub are named because work was done on or with them. None of them has endorsed this platform, evaluated this paper, or made any representation about it.
The figures are workload-scoped. The 20× to 114× acceleration and up-to-99.7% energy reduction were measured on specific workloads under specific conditions. They are not a fleet average, not a guarantee, and not transferable to arbitrary work by assertion.
Replication is not benchmarking. Running the same package on OCI and GCP demonstrates that the artifact operates across providers. It is not a claim that identical performance figures were obtained on all three, and no cross-provider comparison is reported here.
No claim about any provider's instance catalog being poorly designed. Section 02 argues that selection from a catalog carries a structural ceiling regardless of how good the catalog is. Instance families are thoughtfully constructed and the argument is about the mechanism, not the execution.
Not a cost model. This paper describes where cloud waste comes from structurally. It offers no savings estimate, no percentage, and no model, and any figure of that kind would need to be derived from a specific organization's actual utilization.
The third movement opened here, on the machine nobody in the room owns, where the fixed commitment is priced hourly and visible on a statement. Paper 9 moves to the opposite end of the same movement: the device with a fixed power envelope, no administrator and no room to carry anything, where the same architecture produces its cleanest result: one artifact spanning from the hyperscaler infrastructure described in this paper to a smartwatch, at the same footprint.
Paper 10 then takes the link between them, where bandwidth is the substrate and the packaging generations made software heavier at precisely the moment distribution got harder.
Choosing an instance type is a prediction about hardware, made before the workload runs, from a catalog defined by someone who knows nothing about the work, about a machine the chooser will never see. It is the same mechanism as a build matrix, relocated from software distribution to hardware procurement, and it carries the same ceiling: the closest available fit to a guess, never a machine assembled for the job. The artifact and the instance are one commitment made twice against the same unknown, by two departments that do not know they are solving the same problem. Validated on AWS with Rowan University's Digital Engineering Hub; the same package replicated on OCI and GCP. Three clouds are not three targets when nothing was compiled for one of them.
The Common Substrate → Request Platform Access