What It Means That the Same Build Runs on a Hyperscaler and a Smartwatch
Constrained hardware normally forces a vendor into a second product: an embedded edition, cut down to fit, maintained separately, shipped on its own schedule. It also forces the hardest routine operation in the industry, which is replacing executable code on a device with no administrator, no maintenance window and a real chance of never coming back. This paper is about a test record in which neither of those was necessary.
Every generation of packaging examined in Paper 1 bought portability by carrying more of the assumed machine along with the program. That trade has a terminus, and the terminus is the edge, where the power and memory envelope is fixed by the physical design and there is no room to carry anything. The industry's answer has been to build a second product: an embedded edition, reduced to fit, maintained on its own branch, released on its own schedule, and diverging from the full version a little more each year. The second cost of the same commitment is the update. A device that runs a compiled binary can only be given new behavior by replacing that binary, and replacing executable code on an unattended device with a fixed power budget and no maintenance window is the operation most likely to end with hardware that does not come back. It is the reason a very large number of deployed devices are never updated at all.
MindAptiv's test record removes the first of those costs rather than mitigating it. The same build that runs on hyperscaler infrastructure and on an embedded AMD part also runs on smartphones, smartwatches, desktops, workstations and game consoles, across 32 Linux distributions, with the same footprint. There is no embedded edition, because none was needed. This paper explains why that follows structurally rather than being a feat of size optimization: a build matrix grows with the number of targets it must anticipate, and a resolver does not, because a resolver's size is determined by what it is able to resolve rather than by what it happens to be resolving for. The paper then takes up the update problem and argues that changing a declaration the resolver evaluates is a materially different operation from overwriting executable firmware, while being explicit about which security claims that does and does not support.
Paper 1 traced four generations of packaging, each one carrying more of the assumed machine along so that the real machine would stop mattering: the libraries, then a whole userland, then a runtime and a portability shim. Every one of those strategies spends space to buy certainty.
On a server that trade is nearly free. On a device designed around a battery, a thermal envelope and a bill of materials fixed years before the software was written, there is nothing to spend. The image cannot be carried because the room to carry it does not exist, and it will not exist later, because the constraint is physical rather than economic.
So the industry does the only remaining thing and builds a second product. There is a full version and there is an embedded version, and the embedded version is not a configuration of the first but a separate artifact with features removed to fit, its own build pipeline, its own test matrix, its own release cadence and its own defect backlog. Anyone who has maintained both knows how that ends: the two versions diverge, the embedded one lags, and a capability that exists in the product a customer read about turns out not to exist on the device the customer bought. The support matrix Paper 1 described as a commercial answer to the distribution problem reappears here as an entire second engineering organization.
The claim this section makes is narrow, checkable and unusual, so it is worth stating without decoration. The same build runs across the whole range. Hyperscaler infrastructure and an embedded AMD part; smartphones, smartwatches, desktops, workstations and game consoles; 32 Linux distributions. Not a family of builds sharing a codebase. The same file, with the same footprint on the constrained device as on the datacenter machine.
What makes that worth a paper is not the count of platforms, which any vendor with enough build engineering can eventually reach. It is that the count was not reached by building. There is no embedded edition to diverge from the full one, because the artifact was never specialized for a target in the first place, and specialization is what creates the second product. The entire failure mode described in Section 01 is not solved here. It never starts.
The range also spans something like four orders of magnitude in power budget between its ends, which is the part that should give a reader pause. A watch and a datacenter node do not merely differ in degree. They differ in what a program is allowed to assume about memory, about thermal headroom, about how long it may hold a component, about whether it is permitted to be slow. An artifact that assumed anything about those would have to be rebuilt at some point along that range, and this one is not.
A reader who has spent time shrinking software for constrained hardware will reasonably suspect a trick, so here is the mechanism.
A conventional artifact contains decisions. It holds the code paths somebody thought each supported target would need, the library versions those paths were linked against, and the fallbacks for the cases anticipated at build time. Its size therefore grows with the number of situations it was built to anticipate, which is why supporting more hardware makes the artifact larger and why the embedded edition exists: the only way to make it smaller is to anticipate less.
A resolver contains no decisions of that kind. It contains the ability to make them. Its size is a function of what it is capable of resolving, which is fixed, rather than of the range of machines it might be asked to resolve for, which is not. Adding another target to a build matrix adds another artifact. Adding another machine to a resolver's range adds nothing, because the resolver was not carrying a per-machine answer to begin with. That is the whole of it, and it is the same property Paper 1 described from the other direction: what is not committed in advance costs nothing to leave open.
The second cost of the fixed commitment at the edge is not size. It is that a compiled binary can only be given new behavior by being replaced, and replacement is the operation the edge handles worst.
Consider what an update asks of a deployed device. Fetch a new image over a link that may be intermittent. Verify it. Write it over the code the device is currently executing, or into a second slot if the hardware was designed with one, which many were not. Restart. Do all of this on something with no administrator present, possibly no reliable power, and no maintenance window, and do it in a way that survives a failure at any step without leaving the hardware unusable. Devices that cannot satisfy those conditions do not get updated, and there are a great many of them. The reason so much deployed equipment runs software with known defects is rarely that nobody wrote a fix. It is that nobody could safely deliver one.
This is Paper 3's compatibility debt in a different currency. There, honoring a shipped commitment meant an operating system could never put anything down. Here, changing a shipped commitment means overwriting the thing the device is made of. Both costs come from the same source: something was decided in advance and turned into an artifact, and the artifact is now the only place that decision exists.
If what the device holds is a resolver and a declaration of intent, then changing what the device does is changing the declaration. The executable is not the thing being modified, because the executable was never the thing that encoded the behavior.
The operational difference is worth being precise about, because it is easy to overstate. Replacing firmware is a write to the code the processor executes, and a failure part-way through can leave the device with no valid program. Revising a declaration that a resolver evaluates is a data change, and the resolver that evaluates it is the same resolver as before and after. The failure modes are not identical, they are not equally severe, and the second class does not include the specific outcome where the device stops being able to boot the code that would have let it try again.
What this does not license is the claim sometimes made for this kind of update, including by us, that it is "inherently secure." It is not inherently anything. A declaration is an input, an input can be malicious, and a system that acts on declarations needs authority and policy checks on the declaration before it is acted upon exactly as much as a firmware pipeline needs signing on the image. That governance layer is a real part of the platform, it is specified at length in The Governed Machine rather than asserted here, and this paper's claim is bounded to the operational point: the update stops being a firmware replacement, which removes one specific and severe failure mode and does not remove the need to govern what is being installed.
The device range is MindAptiv's own test record. No independent body has certified that the same build runs across the stated range, and the summary here does not name the specific devices or the specific 32 distributions. A reader relying on the claim should ask for the record.
Running is not performing. That one artifact executes across the range is a portability result. It says nothing on its own about how fast the work completes at either end, and the acceleration and energy figures cited elsewhere in this series were measured on specific workloads under stated conditions rather than across this range.
Every device in the range runs Linux. This is a Linux artifact, and the range is wide within that constraint rather than across operating systems. The equivalent claim on Apple, Windows or a bare device is the subject of Papers II, III and XI, and none of them can currently make it.
Declaration updates are not inherently secure. Section 05 states the bounded operational claim and explicitly disowns the stronger one. Anything installed still has to be authorized, and the mechanism for that is governance, described elsewhere.
No claim about any device manufacturer or silicon vendor. The embedded AMD part is named because it is part of MindAptiv's own test record. No engagement, evaluation or endorsement by AMD or any other vendor is reported or implied.
This is the paper where the series' central claim stops being an argument and becomes a file. Everything earlier reasoned about what would follow if instructions were decided at execution rather than at build. Here the consequence is sitting on disk: no embedded edition, no build matrix, no second engineering organization, because there was never a per-machine answer to carry.
Paper 10 stays with constrained deployments and changes the constraint from the device to the link between devices, where the same trade appears again and is even less forgiving. Every generation of packaging made software heavier at the same time that the places software needed to reach got harder to reach. What crosses a scarce link should be a statement of intent, not an image.
Constrained hardware forces most vendors into a second product line and a second engineering organization, because an artifact carrying per-machine answers grows with the machines it anticipates and the edge has no room for it. A resolver does not grow, because its size is set by what it can resolve rather than by what it is resolving for. The same build runs on hyperscaler infrastructure, on an embedded part, on phones, watches, desktops, workstations and consoles, across 32 Linux distributions, at the same footprint. And because behavior lives in a declaration rather than in the executable, changing what the device does no longer means overwriting the code it is made of. That is not a smaller binary. It is a different relationship with the machine.
The Common Substrate → Linux Binary: Chameleon