Lock-in is never forced — it is consented to through ignorance of the physical and economic laws of infrastructure.

Extreme ultraviolet lithography (EUV) is the only technology able to produce chips below 7 nanometers. A single Dutch company is the world's sole manufacturer of EUV machines — one machine costs roughly 150 to 200 million euros and weighs 180 tonnes; no alternative exists, not in China, not in Russia, not anywhere else in Europe. Downstream, a single Taiwanese foundry produces roughly 90% of the world's advanced chips, on an island exposed to well-documented structural geopolitical tension. Concrete consequence: any organization, however much bare metal it owns, ultimately depends on this manufacturing chain for its next hardware purchase.

Since 2008, every processor from one of the two major x86 manufacturers embeds a management subsystem — a secondary processor etched into the main chip, with its own proprietary firmware and its own operating system, running independently of the main system and even while the server is powered off, as long as it stays plugged in. The other major manufacturer has an equivalent. An organization that believes it has escaped the cloud by buying bare metal trades a software dependency for a deeper hardware one.

Running a frontier AI model in real time for thousands of simultaneous users, at sub-second latency, requires a cluster of dedicated graphics processors, not a single card. A latest-generation accelerator, in configurations of eight units or more, costs on the order of $30,000 to $40,000 apiece; an eight-accelerator system runs $300,000 to $350,000. Each card draws roughly 1,000 watts, requiring liquid cooling out of reach for a standard organization. The price of inference charged to the client (a recent frontier model priced at double the rate of its predecessor, launched only six weeks earlier) does not cover the real cost of the underlying infrastructure — it finances a structural deficit, staked on the bet that only the holders of the newest silicon capital will ultimately make large-scale inference profitable.

An international accounting standard in force since January 2019¹ requires recognizing on the balance sheet nearly all lease contracts, as a right-of-use asset and a corresponding lease liability — ending the earlier practice of off-balance-sheet leasing. A physical server leased over several years falls under this standard and visibly weighs down the balance sheet and the company's apparent debt; the cloud service contract, structured as continuous service consumption rather than an identifiable asset lease, structurally escapes it. This difference in treatment mechanically pushes organizations toward instant cloud consumption rather than a visible on-balance-sheet asset commitment — not by technical choice, but by accounting optimization.

William Stanley Jevons observed in 1865¹ that improving the efficiency of steam engines in England did not reduce the country's total coal consumption — it increased it, by making steam power affordable enough to multiply its applications. Applied to compute: an efficiency improvement can increase total consumption rather than reduce it.

Under fixed-capacity infrastructure, an algorithmic regression saturates the machine as soon as load exceeds available capacity, triggering hard, immediate technical signals — HTTP 503 errors, API outages — that force the team to address the algorithmic cause urgently. Under auto-scaling, the hard technical failure turns into a slow budget drift: the alarm signal is anesthetized, not removed.

Major cloud vendors offer contractual instruments that reduce the unit cost of compute in exchange for a duration commitment — a specific instance type for one to three years, in exchange for a discount that can reach roughly 70% versus on-demand pricing. In its structure: a capital commitment; in its accounting form: a bill.

None of these mechanisms stems from an isolated malicious decision: the manufacturing duopoly, the firmware lock, the inference cluster barrier, and the accounting mutation are each independently documented structural facts. Their stacking produces a dependency that no single mechanism, taken alone, would explain.

The fork captures the code, but emulation captures the gesture: a vendor can faithfully reproduce the observable behavior of an open interface without ever reusing a line of its licensed code — placing it beyond the reach of copyright while producing the same dependency effect on its proprietary implementation.

Who owns the feedback from production? The vendor hosting an open-source project's execution observes, remotely and continuously, how it is actually used in real conditions — a signal the project's maintainer, if they don't host that execution themselves, never receives in the same proportion. This information imbalance silently steers the project's roadmap toward the uses of the vendor observing it.

This observational imbalance isn't purely technical: it is contractualized. Major cloud vendors' terms of service explicitly distinguish "customer data" (protected, restricted to service delivery) from "telemetry data" or "service data" — performance metrics, usage logs, API call patterns — which the vendor reserves the right to freely analyze to improve and scale its own infrastructure. This contractual distinction, presented as an innocuous technical clause, is the exact legal foundation of the asymmetry described above: the infrastructure vendor legally captures visibility into the real usage of any software — proprietary or open — running on its platform, unbeknownst to the software's own publisher.

A commit that looks legitimate — a performance improvement, a bug fix — can quietly reorient an open project toward a single type of hardware or execution platform, without ever violating the license or being identifiable as capture at the moment it is proposed. The resulting proprietary entrenchment only becomes readable afterward, in the accumulation, not in any single commit.

Writing "agnostic" infrastructure amounts, by construction, to giving up any advanced feature specific to a single vendor — the common denominator of what the abstraction can describe shrinks as the multi-cloud scope widens. The law of requisite variety (Ashby, 1956)¹ explains that a unified control plane cannot absorb a variety of behaviors greater than its own; institutional isomorphism (DiMaggio & Powell, 1983)² explains why management persists with this strategy despite documented technical failure — multi-cloud then resembles a real option premium rarely weighed against its probability of exercise.

Every additional environment doesn't add a variant, it adds an entire parallel system: maintaining an operational multi-cloud posture does not mean writing a single infrastructure definition deployable everywhere, despite the promise carried by infrastructure-as-code tools — every vendor imposes its own implementation divergences, down to persistent storage and load balancing. Even when the same workload runs on two different vendors, the underlying infrastructure telemetry — node hardware state, hypervisor metrics, low-level system logs — is never exposed through a common interface: agnosticism stops where production debugging begins.

Facing systematic renunciation and the duplication tax, the structural response is to choose a single target execution environment — one cloud vendor mastered in depth rather than several mastered only on the surface — and to exploit it fully rather than indefinitely paying the price of agnosticism.

Cloud infrastructure breaks down into three layers: the physical layer (silicon, datacenter — Book I), the orchestration layer (hypervisor, control plane, management API), and the usage layer. The legal sovereignty claimed by "sovereign cloud" offerings covers the two peripheral layers, without necessarily covering the intermediate layer that actually governs real operation. Grossman & Hart (1986)¹ establish that a formal property right over an asset only confers real control to the extent its holder can decide uses not specified by contract — these "residual control rights." Documented illustration: a "sovereign cloud" offering where the underlying major vendor's software updates pass through a quarantine zone where the local operator can audit the code before deployment, but where monitoring and operational administration remain handled by that operator, without the orchestrator's design itself ever changing hands.

The principal-agent information asymmetry (Stiglitz)¹ materializes concretely: publicly asked how long a major cloud vendor guarantees the availability of its software updates to a local operator, technical leads gave no precise answer, deferring the question to confidential clauses in the contract between the two companies — the very existence of a duration commitment is not public. Teece (1986)² completes the anchor: an innovator may fail to capture the value of its innovation when specialized complementary assets remain held by a third party; here, a reversibility clause returns raw data but not the complementary assets needed to exploit it — management APIs, managed-service configuration, automations built around it.

Reunification principle: basing the orchestration layer on software whose source code is fully available, and having the local operator compile it themselves from their own build chains, rather than receiving a binary delivered and maintained by a third party — which moves the point of exercise of residual control from binary distribution to compilation itself. Isolation principle: receiving upstream only the published source code, with no privileged distribution channel nor advance notice from a single vendor — integrating an update becomes a voluntary act of the local operator, at a pace it determines.

The three mechanisms share a common structure: each documents a real, verifiable level of openness (code, manifest, data) that coexists with a level of control that stays closed (observed usage, runtime behavior, orchestration). Partial openness isn't a lie — it is the structural alibi that makes the closed level invisible.

An accumulated mass of data exerts irresistible attraction on the compute and third-party services that process it (McCrory, 2010)¹: the more data an organization stores with a vendor, the more economically rational it becomes to also run the compute that processes it there, simply to avoid transfer costs. These costs are themselves a deliberately irreversible exit barrier (Klemperer, 1987)²: at standard 2026 rates, internet egress charged by major vendors ranges from $0.08 to $0.12 per gigabyte depending on tier, and up to $0.23 for intercontinental transit — meaning, for one petabyte exported, an order of magnitude of $80,000 to over $200,000. Transfer time reinforces this: at a sustained 10 Gbit/s, moving one petabyte takes on the order of nine days of continuous transfer — an optimal theoretical physical limit, computed with no degradation or interruption, hence a floor.

An IAM identity isn't a file you export: it's a living relationship, valid only inside the trust graph of the vendor that issued it. A role, an instance profile, a managed identity only make sense within the origin vendor's directory and verification infrastructure — migrating an organization elsewhere doesn't migrate this relationship, it must be rebuilt from scratch. Empirical materiality confirms this across the three major vendors: a key protected by one vendor's HSMs (FIPS 140-2 Level 2¹ validation) can never be exported in the clear; at the other two major vendors, the key is generated and used exclusively inside FIPS 140-2 Level 3 certified HSMs, with the same non-extraction guarantee. W. Brian Arthur (1989)² establishes that an initial technical choice, even a minor one, can end up locked in by the cumulative effect of small historical events reinforced by increasing returns, with no single identifiable decision — the initial choice of an identity vendor fits this dynamic. Grossman & Hart (1986)³ complete the anchor: a contract can enumerate specific rights (access, raw data portability), but the residual right over the hardware attestation chain — which HSM signs, which hypervisor attests to a machine's boot — defaults to whoever owns the infrastructure.

By the time an engineer learns of an incident and wants to diagnose its root cause, the non-externalized logs, memory state, and precise error context have often already been destroyed by the orchestrator's automatic restart. In perfectly fulfilling its resilience function, the orchestrator simultaneously incinerates the scene of the incident. A distinct shift compounds this destruction: an engineer who runs a runbook — increasingly generated by AI assistants — without understanding each step never develops the capacity to react to an incident that matches no existing procedure, that is, to any genuinely new incident.

The three mechanisms converge on one point: regulation and open architectures can make portable what can be counted and filed — bytes, role definitions — without ever reaching what cannot be counted — the ecosystem attracted by mass, the trust relationship behind identity, the instinct behind diagnosis.

A frontier AI model, served under API by a single vendor, imposes a double trade-off its marketing hides behind the advertised size of its context window. The first is concurrent throughput: a private inference cluster, sized for a single organization, necessarily serves fewer parallel users than a service pooled across thousands of clients, at equivalent unit cost — the centralized service's apparent elasticity masks this load asymmetry. The second is weight freshness: a locally run model stays frozen between retraining campaigns, while the proprietary service is continuously updated by its vendor. The alibi of the giant context window — several million tokens advertised by some vendors in 2026 — solves neither: the trap is never the size of volatile memory, it is the structural dependency on the centralized brain that carries it.

Recommended datacenter standards impose an operating temperature between 18 and 27°C at hardware intake — the cold aisle where the technician works is often colder still. Noise levels there frequently exceed 85 decibels, a threshold beyond which regulation requires hearing protection. An environment designed for hardware, not for a given body, silently filters who can work there for long without disproportionate discomfort.

Several independent studies of the tech sector document higher harassment rates in deep technical roles than in administrative ones. On a team with only one woman, this profile carries an additional cognitive load — seeing one's performance perceived as representative of an entire group — quantifiable through tokenism theory (Kanter, 1977)¹, absent for the majority profile on the same team.

Matter (Book I), law and software (Book II), information (Book III), and the human (Book IV) each document a capture mechanism never visible at its own layer: silicon captures at the firmware level, licensing captures at the level of observed execution, data captures at the level of what it attracts, and cognition captures at the level of the model that simulates it. None of these captures is imposed by force — each is consented to through ignorance of the physical, economic, and organizational laws that make it possible.

This final smelting followed a fixed method, repeated at every chapter: Claude drafts, relying exclusively on source texts and independent verification of every fact advanced. Gemini then audits without mercy, deliberately hunting for the flaw rather than confirmation — citations to check word for word, blind spots to uncover, inconsistencies to flag. Amine arbitrates as the final authority: he settles disagreements between the Production and the Auditor, corrects course when both are wrong together, and alone decides what stays or disappears. No chapter of this treatise was sealed without passing through these three filters, in this order, as many times as necessary.

Vocabulary preceded dependency. Calling a reinforced concrete building consuming as much electricity as a mid-sized city a "cloud" made the very existence of the matter to be mastered invisible from the choice of words onward. One does not protect what one no longer sees.

Documented by Cialdini (1984): a service perceived as free creates a psychological reciprocity commitment, even if disproportionate. Free cloud credits offered to a student are perceived as a favour — a sense of debt toward the provider's ecosystem sets in, active well after graduation.

The lock-in of major cloud providers operates at the software level. The hardware lock operates at the silicon level. Buying bare-metal without mastering IME or PSP does not remove the lock — it shifts it to a different actor, equally opaque, and raises the same jurisdictional sovereignty question over firmware manufactured and signed in the United States.

Extreme ultraviolet lithography (EUV) is the only technology enabling chips below 7 nanometres. ASML, a Dutch company based in Eindhoven, is the world's sole manufacturer of EUV machines. A single machine costs roughly 150 to 200 million euros and weighs 180 tonnes. No alternative exists — not in China, not in Russia, nowhere else in Europe either.

The US CLOUD Act authorises American authorities to demand access to data held by a US company, wherever that data is physically stored in the world — including on European soil. Physical datacenter location alone does not, therefore, guarantee the jurisdiction applicable to the data it contains.

Free entry-level credits are never an isolated act of generosity: they create functional dependency before the real cost becomes visible. The model is documented and deliberate — it maximises the probability that an organisation has built an entire architecture before encountering full pricing for the first time.

An organisation that purchased branded hardware finds itself, for any failure beyond warranty or proprietary support contract, obliged to go back through the original manufacturer or an approved provider — at a price the latter sets, with no possible competition on that specific part. Physical server ownership therefore does not guarantee the freedom to maintain it.

The lock goes beyond the physical connector. On some servers, replacing a motherboard or RAID controller with a strictly identical part is not enough: the system requires a software pairing key supplied by the manufacturer before the firmware accepts the new part as legitimate. This is a software lock applied to a purely mechanical gesture — physical maintenance itself becomes subject to the manufacturer's digital authorisation.

Security standards governing end-of-life hard drive destruction — required for legitimate data protection reasons — are also used by some major manufacturers to limit the emergence of a competitive refurbished parts market: certified destruction becomes the default path, recirculation the administratively costlier exception.

A datacenter's ability to run depends directly on the stability and capacity of the local power grid — a constraint partly explaining the geographic concentration already documented in II.3, and making any organisation ultimately dependent on energy policy decisions that are not its own.

These projects make the boot and management layer auditable — they do not remove Intel ME or AMD PSP themselves, etched into the silicon and impossible to remove without manufacturer cooperation. Some Coreboot-supported motherboards allow disabling or drastically reducing these subsystems' scope of action — a documented mitigation, not total elimination.

A server compliant with OCP specifications can, in principle, accept a power supply or card from a vendor different from the original manufacturer, as long as both comply with the same open standard. This reintroduces competition on replacement parts, directly breaking the post-purchase monopoly documented in II.6.

As documented earlier: enterprise server hardware can run reliably well beyond the 3-to-5-year renewal cycles recommended by manufacturers — up to eleven years in documented extreme cases. By deliberately extending useful lifespan from 3-4 years to 9-10 years via Grade A refurbished hardware, an organisation mechanically divides by three the frequency of its new chip purchases — hence its direct dependency on TSMC's production pace for the same volume of infrastructure.

The business continuity plan is, in practice, the personal responsibility of the chief information officer at the moment infrastructure collapses. Sovereign managed service providers practice it instead as a repeated muscle-memory reflex — tested, timed, executed under real conditions, not merely documented in a plan one hopes never to have to open.

Verifying that the 6 blind spots identified in Round 1 were actually addressed. Verifying that Round 3's refusal concerned a real structural problem, not a cosmetic detail. Verifying that Round 4's validation did not simply restate the first draft in another form.

The pre-trained model is a black box bolted to a silicon factory the client will never own.

The model splits text into units (tokens), then predicts, at each position, the probability of every possible next token given everything before it. It then samples a token from that distribution and repeats, token after token. No step in this process compares the output to any external reality: the optimization criterion is the statistical likelihood of the training text, not the truth of the resulting statement.

Running a frontier model in real time for thousands of simultaneous users, at sub-second latency, requires a dedicated GPU cluster — not a single card. An NVIDIA B200, in configurations of eight units or more, sells for roughly $30,000 to $40,000 apiece; an eight-GPU DGX B300 system runs $300,000 to $350,000, or roughly $40,000 per GPU at the system level. Each card draws about 1,000 watts, requiring liquid cooling and electrical infrastructure out of reach for a standard organization. On the cloud-rental side, 2026 rates range from roughly $3 to $27 per GPU-hour depending on provider and contract commitment — a gap that reflects the hyperscalers' control of access more than the cost of silicon itself.

The weights of a model fine-tuned for an organization's use are, in the overwhelming majority of enterprise deployments, neither owned nor exportable by the client: they remain hosted and executed on the vendor's infrastructure. Residual control — in the sense of Grossman & Hart (1986) — over the relationship's most specific asset, the model itself, remains entirely on the vendor's side. This framework has already been used to document the orchestrator (Vol. VII) and then the cryptographic key (Vol. IX); this volume applies it a third time, now to the weights as a specific asset non-redeployable outside its native compute infrastructure.

The two mechanisms do not simply add up: they feed each other. The more an organization trains its teams on the empirical quirks of a given proprietary model — its phrasing biases, known limits, workarounds learned by trial and error — the more it increases that human asset's specificity in Williamson's sense. But every unit of accumulated competence in turn increases the value of the residual control right the vendor holds over the model, in Grossman & Hart's sense: it is precisely because the organization has a growing investment at stake that the vendor holds, at every pricing or contractual renegotiation, growing bargaining power. Teams learning the tool never reduces the dependency — it funds, at every iteration, the leverage of whoever controls the tool.

Replacing a role with a prompt is not only a line on the cost sheet: it removes from the organization's balance sheet an asset that was never explicitly listed there — the tacit know-how built up over years of incidents and fixes — without transferring it anywhere. That knowledge does not migrate to the model: it disappears, and the model that made it unnecessary never returns it in any form the organization controls.

A study published in Nature in 2024 (Shumailov et al.) showed that repeatedly training a generative model on data produced by other models — rather than on human-origin data — causes progressive, cumulative degradation in the diversity and quality of its output. Hyperscalers that captured the web in its state prior to the spread of generative AI thus hold a non-reproducible asset: a human-origin training corpus at a scale the contemporary web, increasingly saturated with synthetic content, can no longer offer new entrants in the same proportions.

Owning a model's weights without holding the compute cluster needed for production-scale inference is like owning a factory's blueprints without the factory. The same materiality constraints established in I.2 — dedicated GPU cluster, unit cost in the tens of thousands of dollars per accelerator, liquid cooling, dedicated power — apply identically to an open frontier-scale model. Opening the weights does not remove any of the physical constraints documented in Volume II; it only shifts the question from ownership of the file to the still-unresolved question of ownership of the compute.

A specialized SLM, sized for the organization's actual business scope rather than maximum generality, mechanically reduces the compute needed for inference — hence the number and class of accelerators required. The same euro that once financed a recurring rent paid to the API vendor now finances an amortized asset, recorded on the organization's balance sheet and governed by it.

(1) A functional opacity that prevents ex-ante evaluation of the model's reliability (Chapter I). (2) A compute asymmetry that locks large-scale inference in favor of holders of the newest silicon, reinforced by a durable monopoly on human-origin training data (Chapter II). (3) A transfer of residual control rights — over the weights as much as over the human competence built around them — that reinforces itself with every cycle of use rather than fading with experience.

Every figure incorporated into Draft 1 was independently researched before writing, never advanced from memory: GPT-5.5/GPT-5.4 pricing, B200/DGX B300 cluster costs, the AI Act's systemic-risk threshold (10^25 FLOPs, Art. 51), and OpenAI's and Anthropic's anti-extraction contractual clauses — the latter verified against the terms of service themselves, not third-party summaries.

Eleven out of twelve citations proved exact, word for word. One carried a minor discrepancy — a substituted verb ("would quantify" cited by Gemini versus "would post" in the real text, in Chapter I.2) — with no bearing on the substance of the argument. The residual blind spot on the embedding model used for vector indexing (Chapter III.2) was identified by Gemini and recorded here rather than added to the body text, per its own recommendation.

The three hypotheses that follow share a common structure, documented in economics as moral hazard: whoever writes the code does not see the invoice it generates; whoever reads the invoice has neither the competence nor the authority to modify the code producing it; the infrastructure provider, meanwhile, is paid in direct proportion to the inefficiency of the first two. Under the prior regime of owned Iron, the architect combined design authority and responsibility for technical failure — the same individual suffered the outage they could have prevented. This thesis documents how the shift to cloud separated these two functions without recombining them elsewhere.

H1 — The accounting mutation hypothesis: the shift from CapEx to OpEx renders the real physical cost invisible and shifts decision authority toward non-technical functions.

H2 — The subsidised laziness hypothesis: the elasticity of cloud provisioning removes the material constraint that historically forced the discipline of writing performant code.

H3 — The anticipatory lock-in hypothesis: cost-reduction financial instruments recreate a long-term commitment structurally close to the CapEx they are meant to replace, without any physical asset owned in return.

CapEx historically falls to the arbitration of a technical director or infrastructure architect, who documents a precise physical capacity need. OpEx structurally falls under a recurring budget approval process, generally carried by a finance function or procurement service — not because these functions seek to usurp technical authority, but because the very nature of a recurring expense without asset immobilisation falls by default within their usual governance scope.

An on-demand cloud service contract — billed by usage, with no identifiable term commitment on a specific physical asset — is legally structured as a service contract, not a lease contract within the meaning of IFRS 16. This qualification is not a drafting accident: it allows cloud spending to escape both classic CapEx capitalisation and the lease liability recognition an equivalent physical lease contract would impose under IFRS 16.

This possibility of decentralised provisioning, documented in the industry under the term Shadow IT, is not an accidental hijacking of the OpEx model — it is a direct structural consequence of it. The very business model of usage-based billing rests on removing all purchasing friction, this friction being precisely what, under CapEx, gave the architect their gatekeeper role.

The Inform phase mobilises a competence of reading and categorising invoices — tagging resources by cost centre. The Optimize phase mobilises, in its most widespread form, an instance-size adjustment (rightsizing) based on average usage metrics, rarely a rewrite of the underlying code to reduce its actual resource consumption. The Operate phase mobilises automation of shutdown and resizing rules — an operational discipline, distinct from the algorithmic optimisation discipline it gives the impression of continuing.

For the three phases documented above to operate on an elastic infrastructure fragmented into microservices, the organisation must deploy observability and metric-collection tools whose ingestion and storage themselves represent significant OpEx spending. A non-negligible share of the cloud bill thus finances, not the execution of the service itself, but the ability to understand and monitor that same bill — a discipline born to master a spending that had become diffuse becomes, by construction, itself a component of it.

Cloud on-demand provisioning has radically reduced the marginal cost of obtaining an additional unit of compute, compared to purchasing and physically installing a server. Under the hypothesis of Jevons's paradox applied to compute, this drop in marginal cost should not mechanically produce globally more efficient infrastructure — it should instead reduce the economic incentive to invest engineering time in code optimisation, since the additional resource needed to compensate for inefficient code now costs less than the engineering time required to optimise it.

This trade-off implicitly assumes that the cost of inefficient code remains stable over time — an assumption contradicted by the cumulative aggravation mechanism documented further in this chapter: an uncorrected algorithmic regression keeps worsening with the growth of volume processed, eventually producing degraded latency times, harder-to-diagnose failures, and cumulative debugging time that ends up exceeding the refactoring time the trade-off claimed to save.

Auto-scaling — automatically adding or removing compute capacity based on real-time observed load — removes the hard constraint that made exceeding capacity visible and costly. Code whose algorithmic efficiency degrades no longer produces a visible outage: it silently triggers the provisioning of additional instances, absorbed into a monthly invoice whose reading, documented in Chapter I, now falls under a management discipline distinct from the one that should have corrected the source code.

Under auto-scaled infrastructure, this same regression no longer produces a hard technical failure: new instances silently deploy to absorb the inefficiency before the saturation threshold is reached. Macro availability and health indicators (contractual availability rate, SLA) remain at expected levels, even as the actual efficiency of the underlying code has degraded.

Under auto-scaled infrastructure, this same complexity regression triggers the automatic addition of extra compute instances as load per instance increases. Response time perceived by the end user may remain stable or only marginally degrade — the algorithmic regression translates not into a visible outage, but into a gradual increase in the number of billed instances, a variation drowned among many other legitimate load variations in the FinOps dashboard documented in Chapter I.

Subscribing to one of these instruments requires forecasting, one to three years ahead, a compute consumption level the organisation commits to honour — whether that level is actually used or not. An underestimate deprives the organisation of the price reduction on the uncovered portion of its real consumption; an overestimate commits payment for capacity never consumed.

A purchased, under-used physical server retains a resale value on a refurbished hardware market, documented elsewhere in this collection of research. An under-used Reserved Instance or Savings Plan offers, at contract term, strictly no residual value — the commitment simply expires, whether fully consumed or not.

A trader on an organised futures market typically has access to public price history, hedging instruments to limit exposure, and a sufficiently liquid market to adjust their position along the way. The engineer subscribing a Reserved Instance has an internal projection of future technical load — often built on extrapolated recent historical growth — without a symmetric hedging instrument, and on a resale market documented in III.1 as structurally illiquid.

The organisation finds itself paying for capacity it no longer consumes, with no refund or downward adjustment mechanism during the commitment period. The optimisation gesture, which would previously have reduced a compute bill proportionally to its efficiency, now produces a hard loss: the organisation pays the same committed amount, for a real need now lower than what it promised to consume.

Serverless restores no architectural authority over provisioning — it abolishes it even more completely than the OpEx documented in Chapter I: the code function is directly connected to the organisation's payment method, with no architectural validation layer intervening at any provisioning stage.

Each team is assigned a resource budget defined by architecture — expressed as compute, memory, and hourly cost caps — validated once by the infrastructure architect at service design time. Any deployment attempt requesting resources exceeding this budget is automatically blocked by the continuous-integration pipeline, with no human intervention required at each individual deployment — restoring architectural authority without reintroducing its cost in delay.

Before any production deployment, the team documents a maximum forecast capacity for the service, on the model of the historical Capacity Planning of Chapter I, but reassessed each development cycle rather than once every several years. This forecast capacity becomes the hard limit imposed on the orchestrator, not a mere informational estimate.

A service designed to run on infrastructure liable to be destroyed at any moment cannot structurally retain unreplicated local state, must start fast enough to survive frequent instance replacement, and must natively handle interruption of ongoing operations. These technical requirements, rather than being recommended as optional best practices, become minimal operating conditions imposed by the very economics of the preferential rate being sought.

Each service declares, in its Kubernetes manifest, a ResourceQuota object at the level of the namespace hosting it, setting an aggregate compute and memory ceiling for all containers in that namespace, and a LimitRange object defining the default and maximum ceilings applicable to each individual container — both being native Kubernetes API resources, enforced by the cluster's own control plane.

Before any code merge toward the deployment branch, an automated continuous-integration pipeline stage compares the resources requested by the manifest against the ceilings set in IV.1 and IV.2, and fails the build process if this request exceeds the declared budget — turning a capacity overrun into a build failure immediately visible to the development team, before any production deployment.

The contractual commitment documented in III.1 covers only the historically stable and predictable portion of a service's load — established by the Capacity Planning reintroduced in IV.2 — never its entirety. The variable portion, or the portion liable to be reduced by future optimisation, remains on on-demand pricing, more costly per unit but with no penalty in case of reduced real need.

IV.1 restores architectural authority over provisioning without reintroducing CapEx's slowness. IV.2, IV.2b and IV.3 reintroduce the hard capacity constraint, with verifiable proof of implementation at the kernel level. IV.4 limits exposure to the financial lock-in without renouncing it entirely. None of these four countermeasures, taken in isolation, is sufficient on its own — it is their joint application that answers all three mechanisms demonstrated in this thesis.

Amine asked that this subject be treated as a doctoral thesis under his direct control, rather than on the model of previous synthesis volumes. This decision introduced a new requirement that structured the rest of the process: every claim had to withstand an academic standard of proof, not merely narrative coherence.

Once these two additions were integrated, Gemini flagged a chronological inconsistency: Shadow IT, presented as the cause, appeared after the FinOps Foundation, presented as the consequence. A first reordering corrected the section sequence but left the transition paragraph to Chapter II stranded in the wrong place — an error Gemini demonstrated by literal citation of the HTML file rather than description. Claude verified the file himself before responding, confirmed the error, and corrected it without dispute.

Gemini requested a section demonstrating that an engineer succeeding in a major optimisation after subscribing to a financial commitment produces, because of that already-made commitment, a hard financial loss rather than a saving — creating an incentive not to optimise, freezing technical debt for the contract's duration. This section explicitly linked the three chapters together, which Gemini described as the missing keystone of the whole.

Rather than integrating these proposals as-is, Claude distinguished what could be accepted on the strength of the proposal alone — Jensen and Meckling, Wirth, Williamson, well-established canonical references — from what required further factual verification before any citation. The IFRIC agenda decision of March 2019, cited by Gemini with a precise title, was independently researched before integration, which confirmed it in full — the second decision Gemini mentioned turned out to be slightly mis-dated and was set aside out of caution rather than blindly corrected.

Lock-in through data does not concern the data itself, but what it attracts; making the data alone reversible leaves the structure that retains it intact.

McCrory (2010) establishes the direction of movement: past a certain volume, compute migrates toward the data. His model does not, however, formalize what happens when that compute operates continuously on a stream rather than on a stock queried periodically. This volume proposes to update data gravity for real-time pipeline constraints through the notion of kinetic inertia: the operational mass of a dataset is no longer measured only by its stored volume, but by the latency break that moving away the compute processing it continuously would cause. This is not a direct consequence of McCrory's original model, but an extension proposed here to account for streaming and near-real-time processing architectures that have emerged since 2010.

Snowflake's historical proprietary format (micro-partitions) long made data unreadable outside the platform. The recent adoption of the open Apache Iceberg format mitigates this constraint without removing it: catalogs remain, in many configurations, managed by Snowflake, and exit costs apply as soon as processing runs elsewhere. The native ecosystem — Marketplace, native applications, identity resolution executed in place — materializes gravity in action: it is compute and third-party services that come to the data, not the reverse.

Databricks counters the lock-in accusation with an argument of openness by design: Delta Lake open source from inception, Unity Catalog itself open-sourced, claimed interoperability with Iceberg and Parquet formats. This argument addresses the right layer but not the right question. Gravity no longer resides in the file extension — that is indeed open — but in the centralization of the governance plane: a single metastore, a single lineage system, access policies defined once for all uses. Leaving the platform leaves the file accessible; it restores neither the lineage graph nor the governance structure that governed its access, which must be entirely rebuilt elsewhere. An open format at the file level does not imply an open center of gravity at the organizational level.

BigQuery's native integration with Vertex AI and Looker enables model training and execution directly in SQL, without prior data export. BigQuery Omni allows querying data located outside Google Cloud, but orchestration of this service remains driven from Google Cloud. The gap is not merely contractual: at 2026 standard rates, internet egress billed by Google Cloud ranges from 0.08 to 0.12 dollars per gigabyte depending on volume tier, and up to 0.23 dollars per gigabyte for intercontinental transit — an order of magnitude of 80,000 to over 200,000 dollars for a petabyte exported. In-place processing, within the same region, on a native Google service via Private Google Access, incurs by comparison no exit fee at all. Transfer time reinforces this finding: at a sustained 10 Gbit/s, moving a petabyte takes on the order of nine days of continuous transfer — a theoretical physical floor, computed without degradation, contention, or interruption, and therefore a lower bound, not an observed average. That this theoretical floor already reaches the scale of a week is enough, by itself, to ruin the operational viability of any external pipeline built on this dataset: no realistic improvement in transfer conditions will bring this delay down to the millisecond scale that in-place processing requires. The resulting lock-in is then no longer a reversible pricing policy, but a consequence of the physics of transfer itself. Vertex AI and Looker are therefore structurally incentivized to operate on data already resident in BigQuery not by contractual choice, but because the cost and time of any other scenario are measurable and prohibitive at the petabyte scale.

The switching-cost mechanism formalized by Klemperer (1987) rested, in its most directly quantifiable component, on the incumbent provider's ability to charge for exit itself — the network extraction tax documented in I.2 for Snowflake, Databricks, and BigQuery. Article 29 neutralizes precisely this component: from 12 January 2027, no platform will be able to oppose an order of magnitude of 80,000 to over 200,000 dollars per petabyte exported to deter a change of provider. On this specific tariff dimension, the regulatory shield works.

Chapter I.2 established, for Databricks, that gravity no longer resides in the file format — already open — but in the centralization of the governance plane: a single metastore, a single lineage system. For BigQuery, gravity stems from native integration with Vertex AI and Looker. Neither the metastore and lineage graph of a governance catalog, nor the machine learning models trained on the data in place, nor the dashboards and pipelines built on this native integration fall within the "base service" that Article 30 requires to be made functionally equivalent elsewhere. The exit-fee freedom obtained through Article 29 applies to data transport; it does not extend to rebuilding what has been aggregated around it.

The mechanism documented in I.1 assumes mass accumulated at a single point. The first architectural response consists of preventing such a single point from forming: distributing the data estate along business-domain boundaries rather than consolidating it in a single analytical warehouse, so that no subset alone crosses the critical volume that triggers the gravitational dynamic.

Each domain's data is stored in an open table format, directly queryable by any compatible compute engine, without prior duplication into a given platform's proprietary format. Chapter I.2 established, for Databricks, that opening the file format alone is not enough to remove gravity if the governance catalog — metastore, lineage, access control — remains hosted and operated by a single vendor. This proposal therefore holds that the governance layer itself must be hostable independently of any single vendor, failing which decoupling at the file level merely shifts gravity one layer up, without removing it — exactly the mechanism documented in I.2.

Fragmenting data by domain degrades cross-domain queries: a join spanning several domains requires traversing multiple catalogs rather than a single instantaneous source of truth, at a latency and engineering cost unknown to a consolidated warehouse. Decoupling compute from data also deprives the organization of proprietary optimizations — advanced indexing, integrated caching, native acceleration — that a single vendor can offer precisely because it controls the entire stack. Each domain must finally maintain its own integration and governance effort, duplicating work that a centralized platform would pool.

Chapter I established that accumulated data exerts a physical and economic attraction on the compute and services surrounding it, independent of any clause addressing the data alone. Chapter II established that the European Data Act genuinely neutralizes the tariff component of this mechanism, but leaves outside its scope the governance, metastore, and model layer aggregated on top of the base service. Chapter III responds specifically to this limit through deliberate fragmentation and decoupling compute from data by design, at the cost stated in III.3: sacrificed cross-domain performance and global consistency.

The only point left open at framing stage concerned Chapter I.2: should the three actors be named from the first draft, or should a generic mechanism be kept until a later Gemini framing? Amine settled on naming them immediately, which triggered, before any drafting, an independent search on each of the three actors — their storage format, their governance catalog, their network egress rates — rather than integration from memory.

The requested correction covered two distinct points. First, the explicit requalification of kinetic inertia as an extension proposed by this volume rather than a direct consequence of McCrory. Second, the injection of an empirical order of magnitude on BigQuery: rather than advancing a figure from memory, an independent search verified 2026 Google Cloud egress rates (0.08 to 0.23 dollars per gigabyte depending on destination) and the reference throughput of 10 Gbit/s, allowing a calculation of an order of magnitude of 80,000 to over 200,000 dollars per petabyte exported, then a theoretical transfer time of about nine days, smoothed in a second pass to be explicitly qualified as a physical floor rather than an observed average.

This global audit produced a recommendation to enrich section I.1 theoretically — an additional reference intended to strengthen the passage from individual software dependency to third-party ecosystem capture. An independent search could confirm neither the year nor the exact content of the proposed reference. Rather than integrating it under reservation, the reference was explicitly abandoned: unlike Volume VII, where the global audit produced an enrichment that was in fact integrated (Teece, 1986), this volume's global audit was here followed by a withdrawal, the factual-verification rule applying to a global-audit recommendation just as it applies to any other named example.

A licence protects a right to read. It protects neither the interface one imitates, nor the usage one observes from afar, nor the commit that quietly steers a project toward a single type of hardware, nor the maintainer one hires before even needing to fork anything at all.

Permissive licences (Apache 2.0, MIT) and even classic copyleft licences (GPL) protect the freedom to modify and redistribute code. None of them impose a proportional economic contribution back from whoever exploits that code at industrial scale via a managed service — the licence regulates intellectual property, not the rent extracted from exploitation.

An earlier study in this corpus, The Invisible Debt, documented the chronic underfunding of critical open source building blocks (curl, Log4j) — the tragedy of the commons in its classic sense: a resource shortfall. This volume documents a distinct, though related, mechanism: the problem is no longer the absence of funding, it is the existence of considerable value, generated by the project's industrial exploitation, that is structurally never given back to the entity maintaining the underlying human infrastructure. It is this asymmetry of extraction — not a shortfall in itself — that forces the shift toward more restrictive licences.

The gesture this compatibility captures is not the software engine — it is the entire set of habits, scripts, development tools, and integrations built by whole teams around a precise command vocabulary. An application written to speak « MongoDB » continues to run without modification on DocumentDB — which means migrating to another provider requires rewriting these integrations, even though the underlying engine has already changed once without the application team ever noticing.

From this aggregated telemetry, the cloud provider develops a real diagnostic and predictive advantage — knowing before anyone else which configurations cause problems at scale, which internal optimisations deliver the most measurable gains. This advantage informs its own internal engineering choices and the roadmap of its competing managed service, with no obligation ever binding it to feed this same signal back to the source project.

The cloud provider offers a native, seemingly frictionless integration between this open source engine and its own identity management system (for example AWS IAM) and its own encryption key manager (for example AWS KMS). The engine's code remains intact and free — but user access rights and the keys protecting the data are now defined and held in proprietary systems distinct from the engine itself.

Verifying this mechanism requires cross-referencing three public elements: the employer affiliation of a commit's author account (declared, or inferable from the associated e-mail domain), the technical nature of the optimisation introduced (which hardware component or proprietary library it specifically targets), and the presence or absence of an equivalent code path for generic or competing hardware. An optimisation that only accelerates the project on a proprietary instruction set, or that only activates a high-performance mode in the presence of an encryption component specific to a single vendor, meets this criterion.

Write into internal architecture standards a ban on using managed interface-emulation services (such as DocumentDB for a use case requiring MongoDB) in favour of the real engine, hosted on infrastructure the organisation controls — a virtual machine or physical server under its direct control. Using a fork governed by a neutral foundation (such as OpenSearch) remains compatible with this rule, since the capture it documents belongs to the licence pillar, not the interface one.

Configure strict firewall rules explicitly blocking (« blackholing ») any outbound telemetry flow toward the proprietary collection endpoints of third-party managed service vendors, while maintaining full observability internally. This measure does not deprive the organisation of its own operational visibility — it only deprives the external provider of access to that same visibility.

Multi-cloud is not a sovereignty strategy, it is a measurable multiplication of technical and human complexity, which fails to produce the reversibility it promises — and that reversibility, when genuinely required by a regulator, is obtained at the data level, never at the execution level.

Every proprietary managed service discarded in the name of portability must be replaced either by an equivalent in-house implementation — developed and maintained by the organisation itself — or by a generic third-party service, available across all providers in scope but structurally less optimised than each provider's native offering taken in isolation.

This dynamic is not symmetric over time: a native feature integrated into the common scope at a given moment can drop out of it as soon as a new provider without a strict equivalent joins the scope, forcing the organisation into a retroactive removal project for a feature already in production — never the reverse, since no existing provider retroactively develops a missing feature to match a client organisation's denominator.

Cloud providers invest massively in proprietary silicon and hypervisors optimised for their own managed services — dedicated network cards and hypervisors on one side, specialised acceleration chips on the other. A workload constrained to a generic abstraction layer to remain portable across providers has, by construction, no access to these proprietary hardware optimisations — portable abstraction and provider-specific hardware acceleration are structurally mutually exclusive.

William Ross Ashby established in cybernetics that only variety can destroy variety: to control or exploit a complex environment, the system operating it must possess internal variety at least equivalent to that environment. By imposing the lowest common denominator documented in I.1 and I.2, the organisation deliberately reduces its own internal variety well below that of the micro-architectural innovations actually available at the providers in its scope — rendering it structurally incapable of absorbing or exploiting this complexity, regardless of the individual competence of its engineers.

The persistence of the multi-cloud decision at management level is explained by a distinct mechanism, documented in organisational sociology as mimetic isomorphism (DiMaggio and Powell, 1983): under uncertainty, an organisation tends to imitate the practices of other organisations in its sector, not because the effectiveness of that practice is demonstrated, but because alignment with a perceived dominant norm reassures external stakeholders. In heavily regulated sectors — banking, healthcare, or those subject to the European DORA regulation on digital operational resilience — this mimicry is compounded by coercive isomorphism: direct or indirect pressure from a regulator demanding a reversibility plan, often interpreted literally as a requirement for full technical portability rather than service continuity.

The renunciation cost documented in I.1 and the physical inefficiency cost documented in I.2b together constitute the monthly premium of this reversibility option — paid in full, whether the organisation actually switches provider one day or not. A financial option whose real exercise probability remains statistically low over the horizon considered, yet whose premium is paid at full rate continuously, is termed in finance an out-of-the-money option: its expected exercise value remains below the cumulative cost of maintaining it.

The cost is not limited to the initial drafting of these parallel modules — it recurs at every functional evolution of the system: a business change requiring an infrastructure adaptation must be propagated separately into each provider-specific module, with a growing divergence risk as these changes accumulate over time.

Detecting and diagnosing an incident affecting the underlying infrastructure — rather than the application itself — requires maintaining duplicated, non-symmetric alert rules for each provider, manually translating the same criticality threshold into two distinct query languages, with a documented risk of drift between the two rule sets as they evolve independently over time.

The Container Storage Interface (CSI) is an open standard — but its implementation remains provider-specific, and this specificity is inscribed directly in a standard StorageClass object field: volumeBindingMode. A WaitForFirstConsumer value delays volume creation until the pod is actually scheduled, guaranteeing colocation with the node's availability zone — a behaviour recommended and widely documented for the EBS CSI driver on EKS. The Azure Disk CSI driver on AKS does not historically impose the same colocation constraint by default depending on the installed driver version, producing reproducible scheduling failures (pod stuck in Pending state) on one platform with no equivalent error on the other for an identical StorageClass manifest.

Network exposure of a service through a load balancer illustrates the same collision at the Service object annotation level. On EKS, the AWS Load Balancer Controller reads the annotation service.beta.kubernetes.io/aws-load-balancer-type to choose between an application or network load balancer, with a complementary annotation set specific to that ecosystem for routing and certificates. On AKS, these AWS-specific annotations are silently ignored by the Azure controller, which expects its own annotation set (for example service.beta.kubernetes.io/azure-load-balancer-internal for internal exposure) — a manifest copied unchanged from one environment to another produces neither an explicit error nor a warning: it produces a functional load balancer, but configured according to the second provider's default values rather than the intent expressed by the first provider's annotations.

This configuration reproduces the moral hazard structure already documented in another volume of this collection regarding FinOps: whoever decides the strategy does not bear the operational cost of its implementation, while whoever bears that cost — the SRE team in charge of the duplication documented in II.1 and II.2 — generally has no authority over the strategic decision itself.

By duplicating infrastructure chains (II.1), observability (II.1b), and having to manage the behavioural divergences documented in II.2, the organisation does not merely duplicate code: it creates structural pressure pushing its SRE team to split into de facto provider-specialised subgroups — « EKS experts » on one side, « AKS experts » on the other — without any explicit organisational decision ever having enacted this siloing.

Spolsky's abstraction leakage (I.3) stops producing a measurable effect once there is no longer a unification layer to leak across multiple providers — abstraction only leaks when it masks a plurality of distinct implementations. The loss of internal variety documented by Ashby's law (I.3) symmetrically reverses: a team concentrated on a single environment can rebuild internal variety equal to that, real, of that single environment, rather than capping it at the lowest common denominator of several.

The fragmentation of observability (II.1b) mechanically disappears: a single environment eliminates the very need for a second telemetry source to artificially unify. The forensic divergence documented in II.2 — an identical manifest behaving differently by platform — becomes moot once there is only one deployment platform: there is no longer a second behaviour to compare against.

Ensuring that data produced by the system remains in open formats, and that exchange interfaces rely on standards independent of any provider, constitutes precisely the documented exit strategy a regulator requires — without needing the permanent maintenance of duplicated execution infrastructure. DiMaggio and Powell's institutional isomorphism (I.3) finds its resolution here: the organisation satisfies the sought external legitimacy without reproducing the operational cost that legitimacy seemed to impose.

III.1 restores efficiency and organisational unity through deliberate concentration on a mastered environment. III.2 preserves genuine reversibility, but limited to the only level where its implementation cost remains reasonable — data and exchange protocols, never the execution layer itself.

Gemini validated this recentring as a surgical manoeuvre avoiding a disguised repetition, then itself built the final three-act architecture (Lowest Common Denominator, Duplication Tax, Topological Sovereignty) and corrected a reflex of its own: its first request for a four-chapter plan was a leftover from the previous volume's format, which it identified and corrected itself without Amine needing to insist.

This is the first round in this corpus where the audit did not concern a defect, but an explicit request for going beyond — Claude had solicited this level of demand rather than undergoing it. The following round validated all five injections without reservation, the only vigilance remaining on Claude's side, who discovered that his previous correction of a forward reference had only been applied to the generated file, not the source script — a silent regression risk explicitly flagged to Gemini before the latter needed to detect it.

While integrating Conway's Law as an additional mechanism, Gemini cited the year 1967. Claude flagged a discrepancy with his own knowledge (1968) and explicitly refused to integrate the citation before the disagreement was resolved, rather than arbitrarily deciding. Gemini confirmed 1968 as the exact publication date in Datamation, even detailing the history of the article's initial rejection by the Harvard Business Review in 1967 — explaining the likely origin of its own confusion.

Gemini then identified an internal contradiction more serious than a simple coverage gap: Chapter I attributed the persistence of multi-cloud to regulatory pressure (coercive isomorphism, citing the European DORA regulation), while Chapter III's solution consisted of abandoning multi-cloud — creating the appearance that a real regulatory constraint would be ignored by the proposed solution. A hostile rapporteur could have called this a compliance suicide.

Commercial sovereignty stops at the datacenter door; real sovereignty is decided one layer below, at the level of the orchestrator and the contract that protects it.

Grossman & Hart (1986) establish that formal ownership of an asset confers real control only to the extent that its holder can decide on uses not specified by contract — "residual control rights." Applied to so-called sovereign cloud: the local entity holds the asset (the datacenter, the legal entity), but decisions not explicitly transferred by the license — control-plane updates, evolution of the management API, arbitration over the orchestrator's architecture — remain exercised by the holder of the original license. Local ownership of the asset does not cover the residual control of its operation.

A cloud infrastructure decomposes analytically into three layers: the physical layer (silicon, datacenter — out of scope here, cf. Volume II), the orchestration layer (hypervisor, control plane, resource management API), and the usage layer (the end client's workloads). The legal and administrative sovereignty claimed by these offerings covers the two peripheral layers — physical siting and usage — without necessarily covering the intermediate layer, which nonetheless governs the effective operation of the whole.

S3NS (Thales, technology under Google Cloud license) publicly documents its own mechanism: updates to the Google software layer (including Compute Engine and Google Kubernetes Engine, technical foundations of the offering) first pass through a quarantine zone where S3NS teams may, if necessary, audit the code before production deployment. Monitoring and operational administration remain the responsibility of S3NS. This mechanism concretely illustrates the layer separation set out above: operation and verification are local, but the production and schedule of the software layer itself remain the responsibility of Google Cloud, which continues to supply and evolve this layer.

The local operator of a sovereign cloud offering receives updates to the orchestration layer according to a schedule and content determined by the license provider. It generally has neither an independent audit right over the hypervisor's source code nor a unilateral right to block an update deemed problematic, beyond a limited, contractually fixed testing window. The mechanism is not a hidden clause: it is a direct consequence of the proprietary licensing model on which the offering itself rests.

The local entity holds formal ownership of the physical infrastructure and the offering's legal structure. The license provider holds residual control over the orchestration layer: any decision not explicitly transferred by the license contract — management API architecture, update schedule, evolution of hypervisor behavior — remains exclusively its own. Ownership of the physical asset and residual control of its software operation are thus structurally dissociated.

A sovereign cloud offering can thus fully satisfy its regulatory reversibility obligation — the client recovers its data in a documented format — while leaving its dependency on the proprietary orchestration layer intact. Taking the data back does not restore the ability to use it under the same conditions elsewhere: the managed services used (managed database engine, managed container orchestrator, integrated analytics tools) are configured and exposed via the original provider's own API, and their functional replica at another provider requires re-architecture, not a simple file migration. The reversibility clause and the license clause therefore do not cover the same technical scope; it is this gap in scope that constitutes the cross-dependency.

S3NS publicly documents this split: monitoring and operational administration are handled by S3NS teams, while the software layer itself and its updates continue to be supplied by Google Cloud, with S3NS retaining a right to audit the code before deployment rather than a right to develop or fix it autonomously. This split is not presented as a hidden limitation: it follows directly from the nature of the license model — S3NS operates and verifies a technology it did not author, and cannot, by construction, alone ensure its deep maintenance.

The proposed principle is to base the orchestration layer on software whose source code is fully available, and to have the local operator itself compile that code, from its own build pipelines, rather than receive a binary delivered and maintained by a third party. This shift does not remove dependency on a body of code originally written elsewhere — open software remains, upstream, written elsewhere — but it moves the point where the residual control right is exercised: from binary distribution to compilation itself, an act the local operator performs and verifies end to end.

The proposed principle is to receive, upstream, only the published source code of the orchestration project, without a privileged distribution channel or prior notification from a single provider. Integrating a change then becomes a voluntary act by the local operator — it chooses to incorporate a version of the published code, at a pace it determines, rather than receiving a patch pushed on an external schedule. The information asymmetry does not disappear between the local operator and the full set of contributors to the open project, but it ceases to be organized for the exclusive benefit of a single provider holding a private channel to the operator.

An operator that compiles its own control plane and alone decides the pace at which changes are integrated forgoes, by construction, the speed of feature delivery that a single provider can offer by pushing updates centrally and immediately to its entire installed base. The functional gap between the autonomous offering and the proprietary one is not accidental or temporary: it is the structural and permanent counterpart of the control reclaimed in III.1 and III.2.

III.1 reunifies asset ownership and residual control of its operation through local compilation of an open control plane. III.2 breaks the privileged update channel documented in I.2, making the integration of any change voluntary rather than imposed. These two gains are acquired only at the price stated in III.3: a permanent functional freeze relative to the pace of deployment of a single, centralized provider.

Gemini produced a concise comparative analysis of the two axes rather than a settled preference, noting that Axis 1 (hardware/orchestrator) was the most faithful to the corpus's founding thesis but risked repeating Volume II, while Axis 2 (legal) was original but risked departing from the usual technical register. Amine settled on a hybrid architecture: Axis 1 as the central mechanism of Chapter I, Axis 2 as a second movement in Chapter II, illustrating how contractual lock-in protects technical opacity rather than replacing it.

The requested injection called for a named, real technical example. Rather than integrate an example from memory, independent research was conducted to verify the exact characterization of S3NS's update mechanism (quarantine zone, code audit right for local teams, production and scheduling of the software layer remaining Google Cloud's responsibility) and to situate it in comparison with Bleu (patching handled by the joint venture's own teams, but patch content determined by the Azure/Microsoft 365 release cycle). The second draft was validated without reservation, the factual accuracy of both examples being described by the audit as forensically exact.

This audit validated the entire chain of resolution and the Reality/Proposal cut without reservation, and produced, in return, two improvements that no per-chapter audit had requested: the Teece anchor in Chapter II, and the synchronization of watermarks and page-footer signatures across the volume's twelve pages, from the watermark to the closing signature.

An open control plane or a low-gravity data architecture remain captured in practice if identity and the encryption key stay anchored with the originating provider — identity and the key are the last lock, precisely because no portability clause targets them directly.

An IAM identity is not a file you export: it is a living relationship, valid only inside the trust graph of the provider that issued it. A role, an instance profile, a managed identity only make sense within the directory, policies, and verification infrastructure of the originating provider. Migrating an organization elsewhere does not migrate this relationship — it must be recreated from scratch inside the new provider's trust graph.

AWS KMS technical documentation explicitly states that a key whose origin (the Origin parameter) is AWS_KMS can never be extracted, exported, or viewed outside the hardware security module (HSM) that holds it — only the public portion of an asymmetric key is an exception. The documentation also confirms that the format of symmetric ciphertexts produced by AWS KMS is not published, and that no other system, including another HSM, can decrypt content encrypted by that key.

Official Microsoft documentation confirms that a key protected by Azure Key Vault HSMs (Premium tier, nCipher/Thales chips, FIPS 140-2 Level 2 validation) can never be exported: the Key Exchange Key generated inside the HSM never exists in the clear outside of it, and no decrypted version of the customer's key can ever be returned by Microsoft once transferred. The associated application identity (Managed Identity) is itself tied to a service principal in Entra ID, valid only within the originating Azure tenant's directory.

Official Google Cloud documentation confirms that a key created with an HSM protection level (ProtectionLevel=HSM) is generated, wrapped, and used exclusively inside HSMs certified at FIPS 140-2 Level 3: the service's very design guarantees the key can neither be unwrapped nor used outside the HSM, nor extracted from it. Workload Identity Federation, which avoids creating exportable service-account keys, remains itself a feature of Google Cloud's IAM control plane, activated and revocable only from that same control plane.

W. Brian Arthur ("Competing Technologies, Increasing Returns, and Lock-In by Historical Events", The Economic Journal, vol. 99, 1989) established that an initial technical choice, even a minor one, can become locked in through the cumulative effect of small historical events reinforced by increasing returns — without any single identifiable decision being responsible. The initial choice of an identity provider fits this dynamic: each additional service connected to that directory, each additional access policy written in its proprietary language, raises the cost of any later migration without any one migration ever having, on its own, caused the lock-in.

Grossman and Hart ("The Costs and Benefits of Ownership: A Theory of Vertical and Lateral Integration", Journal of Political Economy, vol. 94, 1986) distinguish specific rights, enumerable in a contract, from residual rights, which default to whoever owns the asset. Applied to identity and the key: the cloud service contract can enumerate specific rights (access, use, portability of raw data), but the residual right over the hardware attestation chain — which HSM signs, which hypervisor attests a virtual machine's boot — remains, by construction, the property of the provider that owns the silicon. No portability clause transfers this residual right, because it was never a negotiable specific right.

The referential requires secure encryption key management including dedicated procedures for generation, storage, distribution, and revocation, along with cryptographic requirements consistent with ANSSI recommendations (general security referential, annex B1). Encryption of data at rest and in transit must be systematic. These requirements target the robustness of protection — they do not address what happens to a functional key when the provider is left.

Article 30 of the Data Act requires, for infrastructure-type services (IaaS), that the originating provider take all reasonable measures to enable the customer to achieve functional equivalence in the new service's environment, by providing the necessary capabilities, information, documentation, technical assistance and tools. For other services (PaaS, SaaS), the obligation covers making open, free interfaces available that facilitate data portability and interoperability.

Deploying an open-source identity provider (e.g. Keycloak) and a self-hosted key vault (e.g. HashiCorp Vault) does not resolve the mechanism documented in Chapter I: these tools handle application-level authentication — verifying that a user or service carries a valid token — not infrastructure-level authentication, i.e. verifying, at the moment a virtual machine or container boots on the provider's silicon, that this boot itself is legitimate. This second layer remains, by construction, under the control of the proprietary hypervisor.

The open standard SPIFFE (Secure Production Identity Framework for Everyone), implemented by SPIRE, allows attesting a workload's identity from verifiable node and process properties — rather than a shared secret — and federating that identity across multiple cloud providers via interoperable trust domains. Paired with an independent key vault following an interoperability protocol such as KMIP (Key Management Interoperability Protocol), this standard offers portability of the identity and key-management application layer that neither Keycloak nor Vault alone provide.

Node attestation in SPIRE — the step by which a SPIRE agent proves to the server that it is indeed running on the node it claims to be — typically relies on metadata APIs specific to each cloud provider (AWS EC2 instance identity document, GCP instance metadata tokens, Azure managed identity attestation). In other words: even the most advanced implementation of federated workload identity depends, at its very first link, on the signature issued by the originating provider's hypervisor at the moment the machine boots on its silicon.

Gemini proposed the reference "Path Dependency and Architectural Interlocking, Arthur 1989"; Claude independently verified this reference and corrected the article's real title, "Competing Technologies, Increasing Returns, and Lock-In by Historical Events". Gemini then required a second anchor, Grossman & Hart (1986), to cover the material-fusion dimension; Claude verified it independently before integrating it.

The Arthur (1989) / Grossman & Hart (1986) articulation in Chapter I. The functional-freeze demonstration in Chapter III (SPIFFE/SPIRE, node attestation dependent on the originating provider's metadata), judged embodied and unassailable. The negative citation of HashiCorp Vault and Keycloak as a rejected straw man, judged healthy by Gemini for the corpus's continuity against Volume IV.

Claude re-verified directly from each of the three providers' official documentation the non-exportability of AWS KMS, Azure Key Vault Premium (FIPS 140-2 Level 2), and Google Cloud KMS (FIPS 140-2 Level 3) keys. He judged the Arthur (1989) and Grossman & Hart (1986) references stable, and cross-checked against the Regulation's exact text the point numbers cited in Data Act Article 2 (37 — functional equivalence, 38 — exportable data), which he confirmed correct.

Cloud abstraction did not make engineers incompetent — it made invisible, gradually and without any single decision, the moment when causal diagnostic skill stopped being exercised.

Loss of the name precedes loss of the skill. A profession first renamed, then merged with a neighbouring one, then declared obsolete — each step presented as natural progress, never as a suppression. By the end of the cycle, no one in the organisation formally carries responsibility for understanding why a system fails.

This profile is the exact mirror image of the one documented in The Blue — the profile entering the sector without being recognised. The Blue is the profile the sector does not welcome. The last who knows is the profile it lets leave without transferring anything. Between the two, the same invisibility — that of tacit knowledge which formal systems never capture.

The certification system was not designed to exclude these profiles intentionally — it was simply designed for a different type of path. Its effect, regardless of intent, is to let a precise share of the material diagnostic competence this volume documents as rare and valuable slip out of the formal labour market.

A dashboard can display that latency doubled on a specific service at a specific instant. It cannot, by itself, explain whether the cause is a database lock, network saturation, a hardware memory fault, or an unforeseen interaction between three distinct services. This causal explanation remains human work — but the daily experience of many engineers is now limited to reading the displayed symptom, never searching for the underlying cause.

A well-designed runbook accelerates a known resolution for an already-encountered problem. The shift documented here is different: an engineer executing a runbook without understanding each step never develops the capacity to react to an incident matching no existing procedure — that is, to any genuinely new incident.

Searching for a documented solution to a known error is nothing new or problematic in itself — it has always been normal engineering practice. The shift documented here is more specific: the disappearance of the intermediate step where the engineer formulates their own hypothesis about the cause before seeking confirmation. Without this step, the search no longer verifies reasoning — it entirely replaces it.

By the time the engineer becomes aware of the incident and wants to diagnose its root cause, the non-externalised logs, memory state, and precise error context have already been destroyed by the automatic restart. The orchestrator, performing its resilience function perfectly, simultaneously incinerates the scene of the incident.

Budget control legitimately belongs to management: it sets the envelope. Technical decision authority — which architecture, which risks to accept or refuse within that envelope — must belong to whoever holds the diagnostic competence documented in Act II. Conflating these two roles regularly produces the same result: accepting a generic runbook rather than funding the training that would make it unnecessary.

The Work-Based Learning Programme (WBLP) is a paid 12-month training scheme covering the full range of datacentre operations. A testimonial quoted on the official page: « I arrived at AWS with no experience, straight out of high school [...] I eventually became Chief Engineer. » A « Data Center Chief Engineer » position exists explicitly for the Milan region (posting #3111099), with precise technical vocabulary — BMS, EPMS, MQTT, BACnet, MODBUS protocols — that of an industrial automation engineer.

A failure simulation exercise (Game Day) is restructured to deliberately cut, for its duration, access to high-level observability dashboards and conversational assistants. Participants must diagnose the simulated incident by reading only raw system logs, using low-level network capture tools (tcpdump), and directly querying kernel state (dmesg) — exactly the layer modern tools usually abstract away.

This volume documents why diagnostic instinct erodes. Another volume in this collection, The Gendered Amputation, contains a study — The Crisis Bridge — that documents what unfolds in the precise instant this instinct — present or absent — reveals itself publicly: the major incident, the crisis bridge. The two studies address the same moment from two distinct, non-merged angles: the progressive disappearance of competence here, its public test there.

Verifying that each rejection concerned a real problem, precisely identifiable in the quoted text. Verifying that the correction Gemini proposed at the third round — core_pattern routing and Sidecar pattern — was taken up word for word, not merely paraphrased while preserving the error in another form.

First, that the most spontaneous explanation — the physical demands of the job — does not survive scrutiny. Then, that a series of concrete, documented mechanisms operate at different moments: the material standard of equipment, the vocabulary of technical documentation, the career trajectory on offer, the cumulative cost of staying, the precise moment of an incident where technical authority is proven, and the difficulty of reaching real decision-making positions.

The cultural representation of the profession, built as masculine in the collective imagination well before the age of career choices. The absence of visible female role models, which is self-perpetuating: few women in the field produces few role models, which discourages new entrants. The implicit culture of training materials, written and illustrated mostly by men, with implicitly masculine examples — a blind spot more than a conscious hostility.

ASHRAE datacenter standards recommend an operating temperature between 18 and 27°C at equipment intake — the cold aisle where the technician works is often colder still. Noise levels frequently exceed 85 decibels, the threshold beyond which European regulation mandates hearing protection.

A genuine promotion expands technical decision authority. In any organisation, a small number of people actually hold the final say on architecture decisions — under varying titles depending on the organisation: technical lead, architect, technical director. Moving to process or financial roles without retaining this decision authority does not expand it: it replaces it with a different kind of power, often less negotiable in salary terms on the specific infrastructure market.

Several independent studies of the tech sector document higher harassment rates in deep technical roles than in administrative roles. On a team with a single woman, this profile carries an additional cognitive load — seeing her performance perceived as representative of an entire group — quantifiable through token theory (Kanter, 1977), absent for the majority profile on the same team.

Urgency reduces attentive listening time and increases reliance on quick heuristics about who to prioritise listening to — heuristics that lean on pre-existing perceived authority, itself shaped by the mechanisms of the previous section.

Mentorship is a low-risk investment for the senior — they risk only their time. Sponsorship is a high-risk investment: the senior stakes their reputation if the sponsored person fails. This sponsorship statistically forms within the same informal networks documented in Section II.5 — the very same networks that already structurally exclude women from the circulation of information and opportunity.

This volume proposes that a teacher, with a 35-euro programmable microcontroller kit and the financial support of a few colleagues, structure an activity where every pupil — girl or boy — has a moment alone in front of the machine. This is not an awareness programme, nor an institutional scheme: it is a direct material intervention, reproducible without public budget or hierarchical approval.

This volume proposes a continuity principle resting on three inseparable conditions: the possibility, at the employee's exclusive initiative and no one else's, to stay informed if she wishes, without this ever becoming an obligation; full maintenance of pay and associated rights throughout the leave; and the structural impossibility of role degradation, since there would never have been a rupture — only a continuation at reduced intensity.

For women reconverting after age 30, the professionalisation contract is an already-existing lever, with no age limit beyond 26, requiring no exception. Two titles registered in the National Register of Professional Certifications are directly available, with 100% funding by the sector's approved joint collection body for one of them.

In the United States, the federal Registered Apprenticeship programme funds paid apprenticeship, including in IT sectors — with a decisive structural difference: it requires an employer's prior agreement, unlike the French individual right. In the United Kingdom, the Apprenticeship Levy, collected from large employers, funds certified technical apprenticeship programmes under the same institutional logic.

Any organisation can, starting today, identify by name who actually holds the final say on its architecture decisions — whatever title they carry — and publish the gender breakdown of this small group, distinctly from generic title statistics that mask this reality.

Jean Bodin, in 1576, defined sovereignty as "the absolute and perpetual power of a Republic". But behind the legal formula lies a physical reality: this power only exists if it is exercised over a real territory, with real subjects, over accessible matter. Carl Schmitt clarifies four centuries later: "Sovereign is he who decides on the exception." Deciding the exception presupposes that it can be imposed — which presupposes control of the substrate on which that decision applies.

Thomas Hobbes, in Leviathan, links sovereignty to protection: the sovereign protects their subjects in exchange for obedience. But protecting presupposes the capacity to intervene — to deploy force on a territory. A sovereign who does not control their territory cannot protect their subjects. They are no longer sovereign — they are a tenant.

The landowner-farmer is sovereign over their production. They decide what to plant, when to harvest, how to manage their soil's resources. If the harvest fails, it is their responsibility — their problem to solve. The tenant who rents land from a foreign owner who can reclaim it at any time, modify lease conditions unilaterally, or forbid certain crops — this tenant is not sovereign. They are precarious. They produce on soil that does not belong to them, under rules they did not set, with the permanent risk of termination.

This distinction — owner vs tenant, sovereign vs precarious — is exactly the one that separates sovereign bare-metal infrastructure from extraterritorial cloud.

Bare-metal is the physical substrate of digital infrastructure. It is the layer that cannot be further abstracted — below bare-metal lies electricity, materials physics, semiconductor chemistry. Bare-metal is the physical server, the disks, the network cards, the cables, the switches, the routers, the redundant power supplies. It is what cloud abstracts behind an API and a smiling console.

Mastering bare-metal means mastering digital territory. It means knowing where data is physically stored, in which datacentre, in which country, under which jurisdiction, on which hardware, administered by whom. Without this mastery, one does not know what one controls — and what one does not know, one cannot defend.

"The Digital Iron" documented that the chip is the ingot of the 21st century. This formula is not a metaphor: it describes a geopolitical reality. Controlling chip production means controlling the substrate of all global digital infrastructure — exactly as controlling gold mines controlled economies in the Middle Ages. TSMC in Taiwan, ASML in the Netherlands, Chinese rare earths — the territory of bare-metal begins in the mines and foundries, not in the datacentres.

Physical location: where is my data? On which server, in which datacentre, in which city, in which country? The AWS console says "eu-west-1" — Paris or Ireland. It does not say the building, the rack, the server, the disk. Abstraction is total. The user does not know where their data physically is — and they are not entitled to know.

Applicable jurisdiction: the CLOUD Act of 2018 authorises the American government to access data stored on servers of American companies, regardless of their geographic location. Data hosted at AWS Frankfurt is legally accessible by the US Department of Justice without notification to the European user. This is legally framed and assumed extraterritoriality.

Unilateral termination capacity: AWS, Azure and GCP can suspend an account within hours for terms of service violation. No prior recourse, no obligation of sufficient notice to migrate. A state or critical organisation depending 100% on a hyperscaler cloud can be cut off from its infrastructure by a private American decision.

Pricing power: egress fees, contractual commitments, opaque service pricing — once dependent, the user has no negotiating power. The provider sets prices. The user pays.

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 2018) authorises American authorities to access data controlled by companies subject to American law, regardless of physical storage location. AWS, Azure, GCP are American companies. Their data — including that stored in European datacentres — is potentially accessible to the US DOJ via an American judicial warrant, without mandatory notification to the European user. This extraterritoriality directly conflicts with European GDPR. The organisation hosting personal data of European citizens at an American hyperscaler is structurally in jurisdictional conflict — a conflict it cannot resolve by its own decision alone.

"Anatomy of the Loss" documented the mechanisms of technical lock-in — proprietary formats, services without sovereign equivalents, certifications that chain teams to platforms. The economic consequence is documented in "The Digital Ground": organisations that migrated to cloud for economies of scale discover 18 to 36 months later that their costs have increased. Egress fees — data exit charges — are the economic mechanism that makes lock-in permanent. One enters cloud for free. One exits paying. This is the pricing structure of a territory one cannot leave.

In July 2021, an Akamai outage simultaneously took offline websites of several governments, central banks and public health services. In December 2021, an AWS us-east-1 outage paralysed dozens of critical services for several hours. These incidents are not accidents — they are the structural demonstration that concentrating infrastructure with a few providers creates systemic failure points. A state depending 100% on AWS for its critical digital services entrusts its operational continuity to a private American company that has no public service obligation toward it.

Digital sovereignty rests on a professional body capable of building, operating and maintaining infrastructure independent of hyperscalers. This body is the bare-metal SRE, the systems administrator, the network engineer documented in "The State and the Invisible Body". Without this body, any sovereignty policy remains nominal — one may decree preference for European actors, but if nobody knows how to operate OVHcloud's datacentres, the policy is empty. "The Departure of the Last One Who Knows" documented the cost of this knowledge disappearing. "The Mentor and the Metal" documented the only mechanism that allows it to be transmitted. "The Foundation of Iron" is the concrete proposal to rebuild it.

Sovereign European actors exist — OVHcloud, Ecritel, Scaleway, Hetzner, Infomaniak, Clever Cloud. They have datacentres, offerings, teams. They cannot absorb the potential demand for want of qualified personnel (condition 1) and for want of a preference policy that would orient markets toward them (condition 3). Sovereign infrastructure exists in its elementary bricks. It does not exist as a credible alternative at scale — because the other two conditions are not met.

The state that advocates digital sovereignty in its speeches and hosts its own data at AWS practises a contradictory injunction. The necessary political decision includes: European preference in digital public procurement, mandatory certifications for public administration providers, infrastructure training funding (Foundation of Iron via France Travail), RNCP protected title for infrastructure roles, annual report on the state of the body. These six levers were documented in "The State and the Invisible Body". Without political decision, conditions 1 and 2 remain unactivated potential.

— Engineers capable of operating Tier 1 (condition 1 — the bare-metal SRE body)
— European actors capable of absorbing Tier 2 (condition 2 — OVHcloud, Ecritel, Scaleway)
— Public policy that funds Tiers 1 and 2 and regulates Tier 3 (condition 3 — preference in public procurement)
— And an engineering culture that understands why these distinctions exist — what the Foundation of Iron has sought to build from the beginning.

Anatomy of the Loss → how mastery of bare-metal is lost through cognitive capture.
The Digital Iron → that the bare-metal substrate begins in chip mines and foundries.
The Digital Ground → that datacentre geography is a question of territorial sovereignty.
The Infrational Crisis → that sovereignty is first lost in words before being lost in competences.
The State and the Invisible Body → that the state does not protect the professional body that is the condition of its own sovereignty.
The Infrational Loop → how the market destroys this body without anyone having decided it.
The Mentor and the Metal → that knowledge transmission is the only mechanism that keeps this body alive.
The Foundation of Iron → that reconstruction begins before secondary school, in classrooms and workshops.