Name: The Engineering of the Invoice
Author: Amine RAITI

100%

GRIMOIRE❦

Grimoire Dindon Corpus Synthesis Volumes The Foundation of Iron

← Previous Next →

HUMAN

Doctoral Thesis · July 2026 · Standalone Volume

◆◆◆

The Engineering of the Invoice
The Dissolution of Algorithmic Optimisation Under the Effect of Cloud Accounting

◆

◆ Asymmetry Disclosure — applies to this entire volume

This thesis does not claim that every FinOps practitioner has abandoned engineering. It was modelled by an infrastructure architect, evaluated contradictorily by two artificial intelligences following a thesis-rapporteur protocol, drawing on verifiable public facts — cloud provider technical documentation, FinOps Foundation publications, the public contractual mechanics of pricing instruments. It documents a structural hypothesis, hypothesis by hypothesis, and proposes architectural countermeasures explicitly owned as proposals, not established norms.

◆◆◆

Amine RAITI — Infrastructure Architect & SRE
Former engineering school professor · Teaching since 2006
Public document · CC BY-NC-SA 4.0

HUMAN

Introduction

Problem statement, hypotheses, and method

◆

FinOps has established itself in under a decade as a cloud cost management discipline, institutionalised by a dedicated foundation — the FinOps Foundation, created in 2019 — and its own vocabulary: showback, chargeback, rightsizing, savings plans. This thesis posits that this institutionalisation is not neutral: it documents the progressive replacement of an engineering competence — optimising code, the kernel, input/output — with a budget management competence — tagging and arbitrating invoices — without this substitution ever being presented as such by the industry.

◆ Central research question

To what extent does the FinOps discipline constitute, not an evolution of systems engineering, but a clinical symptom of the loss of architectural control — the invoice becoming the steering instrument in place of the code itself?

◆ The transversal concept unifying the three hypotheses — moral hazard

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.

◆ Three working hypotheses

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.

◆ What this thesis explicitly excludes from its scope

Three possible overlaps with the existing corpus are explicitly excluded: the link between refurbished hardware and semiconductor foundry dependency (already covered in The Cloud Illusion), the FinOps career path as a gendered sociological flight (already covered in The Exile Toward Abstraction), and the residual value of end-of-life hardware (the subject of a separate, strictly material study). This thesis documents a universal architectural failure, not a question of hardware ownership or an individual career path.

HUMAN

I.1

The shift from CapEx to OpEx as an act of accounting disembodiment

Chapter I · The Accounting Mutation — Validating H1

◆

A capital expenditure (CapEx) commits an accounting balance sheet over several years, immobilises an identifiable physical asset, and requires prior planning — how many servers, for what anticipated load, over what amortisation horizon. An operating expenditure (OpEx) sits within a monthly income statement, corresponds to no physical asset on the balance sheet of the company paying it, and requires no capacity planning beyond the willingness to pay the next invoice.

◆ What this accounting shift concretely displaces

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.

◆ The disappearance of the capacity question in favour of the cost question

Under CapEx, the question asked upstream of a purchase is: « what capacity do we need? ». Under cloud OpEx, the question asked continuously becomes: « how much does this already-provisioned capacity cost us this month? ». The shift is not merely financial — it inverts the logical order between technical sizing and budget constraint.

◆ An anchor in economic theory — the agency problem

Agency theory, formalised by Jensen and Meckling (1976), models the conflict of interest arising when an agent making a decision does not themselves bear the cost of that decision, unlike the principal who does. The shift documented here is a direct instance of this: the engineer provisioning an OpEx resource is structurally not the one who answers for its cost before the organisation — a decoupling that the CapEx regime, by entrusting both roles to the same technical function, did not produce.

HUMAN

I.1b

Financial engineering of the balance sheet precedes technical engineering of the cloud

IFRS 16 and the deliberate disappearance of the right-of-use from the balance sheet

◆

The international accounting standard IFRS 16, effective January 2019, required companies to recognise on the balance sheet the vast majority of their lease contracts as a right-of-use asset and a corresponding lease liability — ending the prior practice of keeping certain leases off-balance-sheet. A physical server leased over several years typically falls under this standard.

◆ Why the cloud service contract structurally escapes this standard

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.

◆ What this means for board presentation

A cloud migration can be presented to a board of directors not as a technical decision, but as a balance-sheet readability improvement: no new capitalised asset, no new recognised lease liability, an expense appearing only on the monthly income statement. The technical engineering decision documented in I.1 was preceded, and largely made politically possible, by this financial presentation engineering — the cloud shift was first sold as a balance-sheet optimisation, before being experienced as an infrastructure reorganisation.

◆ An official doctrine, not merely an engineer's reading

This loophole is not an isolated interpretation. The IFRS Interpretations Committee (IFRIC) published an agenda decision in March 2019 titled « Customer's Right to Receive Access to the Supplier's Software Hosted on the Cloud », explicitly concluding that a cloud service contract confers the customer neither an intangible asset under IAS 38 nor a lease under IFRS 16 — the supplier alone retaining decision-making power over the underlying infrastructure. This official decision seals, at the level of international accounting doctrine, the shift of infrastructure off the balance sheet.

HUMAN

I.2

Abolishing the gatekeeper

How OpEx bypassed the architect before FinOps was invented to clean up the mess

◆

Under CapEx, acquiring physical capacity presupposes a centralised purchasing process — purchase order, prior budget approval, delivery lead time — in which the infrastructure architect structurally occupies a mandatory gateway position: no capacity can be provisioned without them documenting the need. Under cloud OpEx, a corporate credit card and login credentials suffice to provision equivalent capacity within minutes, from any department in the organisation, with no architectural validation technically required beforehand.

◆ Shadow IT as a direct consequence, not an isolated drift

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.

◆ Why FinOps appeared after, not before

A FinOps discipline structured from 2019 onward — documented in the following section — was not designed upstream as preventive governance: it emerged downstream as an after-the-fact response to a proliferation of spending already committed by departments lacking architectural authority. The FinOps discipline mops up a financial haemorrhage it never itself restores — it manages the bill left behind by provisioning decisions made outside any prior technical control.

◆ What this mechanism adds to the validation of H1

This mechanism complements the two preceding ones without repeating them: I.1 documents the shift in the question asked (capacity versus cost), I.1b documents why this shift was validated at balance-sheet level, and this section documents how it concretely bypassed the architect on the ground — before any structured discipline was even invented to take back control of an expense already committed, the subject of the following section.

HUMAN

I.3

The dissolution of the systems engineer into a billing analyst

The institutionalisation of invoice-reading as an engineering discipline

◆

Facing the spending proliferation documented in the previous section, the FinOps Foundation, a non-profit organisation founded in 2019 and hosted since 2023 by the Linux Foundation, structures the FinOps discipline around three publicly documented phases: Inform (cost visibility), Optimize (resource adjustment), Operate (continuous automation). This structuring borrows the vocabulary and institutional legitimacy of the open-source engineering world — without the competencies actually mobilised in these three phases structurally belonging to systems engineering.

◆ What each phase actually mobilises

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.

◆ A management discipline borrowing engineering's vocabulary

Nothing in this description suggests malice on the part of the FinOps Foundation or FinOps practitioners themselves — the discipline answers a real need for budget visibility over spending that has become diffuse. This chapter documents a structural effect distinct from any intent: a « FinOps Engineer » or « FinOps Analyst » position, by its very name, substitutes in the org chart for a systems engineer position, without the hiring competencies required overlapping with the latter's.

◆ The observability tax — a cost FinOps imposes on itself

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.

◆ What Chapter I establishes, and what it does not yet establish

This first chapter establishes the structural shift in authority and vocabulary — it does not yet claim to demonstrate the effect of this shift on the actual quality of the code produced. This demonstration is the subject of Chapter II, dedicated to validating hypothesis H2.

HUMAN

Chapter II

The Subsidy of Laziness — Validating Hypothesis H2

◆

Chapter I established the shift in authority and vocabulary produced by the CapEx/OpEx accounting mutation. This chapter demonstrates a second effect of a different nature: this accounting shift removed a technical constraint that historically forced the discipline of writing performant code. Hypothesis H2 posits that cloud provisioning elasticity subsidises algorithmic inefficiency rather than correcting it.

HUMAN

II.1

Jevons's paradox, from coal to compute

An improvement in efficiency can increase total consumption, not reduce it

◆

William Stanley Jevons observed in 1865, in his book The Coal Question, that improving the efficiency of steam engines in England had not reduced the country's total coal consumption — it had in fact increased it, by making steam use affordable enough to multiply its applications. This paradox, documented since in numerous energy sectors, poses a hypothesis transposable to computing: a drop in the unit cost of a resource can increase its total consumption to the point of cancelling out, or even reversing, the initial efficiency gain.

◆ The transposition to cloud compute

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.

◆ The exact status of this hypothesis at this stage of the demonstration

Jevons's paradox is an economic mechanism documented in the energy sector for over a century. Its transposition to cloud compute constitutes, at this stage of the chapter, a structurally plausible hypothesis by analogy — its empirical validation specific to the computing domain is the subject of the following sections.

◆ A second anchor, specific to software engineering — Wirth's law

Independently of the economic analogy with Jevons, computer scientist Niklaus Wirth observed as early as 1995 that « software gets slower faster than hardware gets faster » — an empirical regularity documented in software engineering as Wirth's law, independent of any economic theory. The convergence of these two distinct disciplinary origins, one economic and century-old, the other computational, reinforces the plausibility of the mechanism documented in this chapter rather than resting on a single isolated analogy.

HUMAN

II.1b

The machine-time versus human-time objection

This chapter's strongest counter-argument, formulated in order to answer it

◆

An objector might argue that this thesis rests on an anachronism: an engineer's development time structurally costs more than the additional cloud bill produced by unoptimised code. Under this reading, auto-scaling would not be an algorithmic abdication but a rational economic trade-off — buying elastic compute to save costlier human refactoring time, for the benefit of time-to-market velocity.

◆ Why this trade-off only holds in the short term

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.

◆ What this section establishes about the scope of the objection

This thesis does not claim the machine-time-versus-human-time trade-off is always irrational — slightly suboptimal code, stable over time, can legitimately remain as is. It establishes that this trade-off ceases to be rational precisely in the case documented by this thesis: technical debt that worsens with scale, with no structural mechanism making it visible before it has exceeded the point where the initial refactoring would have been less costly.

HUMAN

II.2

The disappearance of Capacity Planning as a discipline

When the finite-capacity constraint disappears, the discipline it imposed disappears with it

◆

Capacity Planning — the discipline of sizing infrastructure in advance for anticipated load — historically imposed a hard constraint: a physical server has a finite, known-in-advance compute, memory, and I/O capacity. Exceeding this capacity produced an immediately visible degradation or outage, which structurally incentivised engineering teams to optimise their code to fit within the available envelope rather than requesting a larger one.

◆ What auto-scaling removes from this equation

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.

◆ What this section establishes, and what it does not yet establish

This section establishes the mechanism by which the constraint disappears — it does not yet establish, through quantified data, that this disappearance has actually produced a measurable degradation in the algorithmic efficiency of production code. This empirical demonstration is the subject of the dedicated study in the following section.

HUMAN

II.2b

The anaesthesia of the alarm signal

When a hard technical failure turns into a slow budgetary drift

◆

Under fixed-capacity infrastructure, an algorithmic regression saturates the machine as soon as load exceeds available capacity, triggering hard, immediate technical signals — HTTP 503 error codes, API outages, network monitoring alerts. The system visibly collapses, forcing the engineering team to interrupt ongoing tasks to restore service urgently — and, in doing so, to address the algorithmic cause of the saturation.

◆ What auto-scaling substitutes for this signal

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.

◆ A transformation of the signal, not merely its disappearance

This mechanism does not merely remove the alert signal documented in II.2 — it transforms it. The immediate technical alert that, under fixed-capacity, would have triggered an urgent optimisation effort, becomes a slow budgetary drift, readable only after the fact in a monthly invoice — at the same reading pace as the FinOps discipline documented in Chapter I, structurally incapable — as the following section demonstrates — of linking this drift to its precise algorithmic cause.

◆ What this section establishes

Auto-scaling does not merely remove the capacity constraint that forced optimisation — it actively maintains technical health indicators at expected levels while that constraint disappears, depriving the engineering team of the very signal that historically made the need to act visible.

HUMAN

II.3

Inedited study — algorithmic complexity masked by elasticity

When an O(n²) complexity regression becomes invisible behind a billing line

◆

This study documents a reproducible technical scenario, illustrating the theoretical mechanism of the two preceding sections on a concrete case of algorithmic complexity. A data-processing function whose complexity shifts, following an apparently minor modification, from linear order O(n) to quadratic order O(n²) produces, under fixed and pre-sized infrastructure, only one immediately visible and measurable consequence: processing time lengthens markedly as soon as data volume exceeds an identifiable threshold, until it saturates or exceeds available capacity.

◆ What happens instead under auto-scaled infrastructure

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.

◆ Why this mechanism resists FinOps diagnosis itself

The FinOps tools documented in I.3 are designed to identify under-used or mis-sized resources at a given instant — not to establish a causal correlation between a precise code modification and a gradual consumption increase over several weeks. The discipline that replaced performance engineering, documented in Chapter I, is structurally not equipped to diagnose the symptom this chapter documents.

◆ What this study does not claim

This study does not claim that every cloud bill increase results from an algorithmic regression — legitimate growth in data volume or user traffic is the most frequent cause. It establishes that a real regression, when it occurs, no longer produces the immediate alarm signal it would have produced under fixed-capacity infrastructure — it blends with legitimate growth rather than standing out from it.

HUMAN

Chapter II Closing

H2 validated — transition to H3

◆

◆ The Thesis in One Sentence

Jevons's paradox applied to compute does not predict that cloud will cost more — it predicts that writing bad code will cost less than writing good code, and that once this economic equation is established, it does not correct itself.

◆ What Chapter II establishes, and what it does not yet establish

This chapter establishes the mechanism by which cloud provisioning elasticity removes the constraint that historically forced code optimisation, and illustrates this mechanism on a case of masked algorithmic regression. It does not yet claim to have examined the contractual mechanics of cloud financial instruments themselves — this demonstration, relative to hypothesis H3, is the subject of Chapter III.

HUMAN

Chapter III

The Anticipatory Lock-In — Validating Hypothesis H3

◆

Chapters I and II established the shift in accounting authority and the disappearance of algorithmic optimisation discipline. This chapter examines a third mechanism, contractual in nature: the financial instruments presented by cloud providers as FinOps optimisation tools — Reserved Instances, Savings Plans — recreate, in a new form, the long-term commitment the shift to cloud was meant to abolish, without any physical asset owned in return at term.

HUMAN

III.1

The contractual mechanics of capacity commitments

Reserved Instances and Savings Plans — a term commitment in exchange for a price reduction

◆

Major cloud providers offer contractual instruments allowing a reduction in the unit cost of compute in exchange for a term commitment. Reserved Instances (AWS, and their equivalents at other providers) commit the customer to a precise instance type for a one- or three-year term, with full, partial, or spread-out upfront payment, in exchange for a discount that can reach around 70% versus on-demand pricing. Savings Plans, introduced by AWS in 2019, relax this commitment by tying it not to a precise instance type but to an hourly spend level, offering greater technical flexibility for a comparable price reduction.

◆ What these instruments actually require from the organisation

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 secondary market that exists, but is structurally limited

AWS offers a resale marketplace for unused Reserved Instances, in theory limiting losses in case of overestimation. This market nevertheless remains confined to a single platform controlled by the provider itself, without the price-discovery mechanisms or liquidity of an independent organised financial market.

HUMAN

III.2

The return of CapEx, without the asset that justified it

A capital commitment in structure, an invoice in accounting form

◆

Chapter I established that the shift from CapEx to OpEx removes the need for an immobilised physical asset on the balance sheet. The instruments documented in III.1 nevertheless reintroduce a central structural feature of CapEx — the multi-year financial commitment decided in advance based on a need projection — without reintroducing the counterpart that, under CapEx, justified the risk: ownership of a physical asset capable of being resold, reallocated, or fiscally depreciated according to rules known in advance.

◆ The term-by-term structural comparison

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.

◆ An anchor in transaction cost economics

Oliver Williamson, in The Economic Institutions of Capitalism (1985), establishes that the more a transactional asset becomes specific to a given contractual relationship, the more the committing party becomes captive to that relationship. A generic compute commitment transformed, by the instruments documented in III.1, into a dedicated, non-transferable contractual commitment, is a direct instance of this asset specificity — the cloud provider extracting rent not through the technical superiority of its service, but through the rigidity of the contract it had signed.

◆ What this section establishes, and what it does not yet establish

This section establishes a structural asymmetry between the risk taken and the counterpart obtained, by direct comparison with the CapEx regime it partially recreates. It does not yet establish who, within the organisation, concretely bears responsibility for this commitment decision — this question is the subject of the inedited study in the following section.

HUMAN

III.3

Inedited study — the engineer as a blind instance trader

A futures-market decision, made without the tools of a market

◆

Subscribing to a Reserved Instance or Savings Plan over a one-to-three-year horizon amounts, structurally, to taking a position on a futures market: committing today to a future consumption level in exchange for a reduced price, betting that actual consumption will meet or exceed the commitment made. This study documents that this decision, in the vast majority of organisations, is made by engineering profiles with no training or tooling in financial risk management, even though its structure is that of a derivative instrument.

◆ What this reluctant trader lacks, compared to a professional trader

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 responsibility shift this produces

A decision of a financial nature — a multi-year capital commitment, with a hard-loss risk in case of under-consumption — is thus structurally made by a technical function whose performance evaluation generally bears neither on the accuracy of this forecast, nor on the financial risk taken, but on the availability of the service delivered.

◆ What this study does not claim

This study does not claim that the engineers concerned are incompetent at evaluating their future technical load — that is precisely their legitimate competence. It documents that this technical competence is mobilised to make a decision of a financial nature, without the accompaniment, training, or risk-management tooling proper to this type of decision following the responsibility transfer.

HUMAN

III.4

The punishment of optimisation

When a successful engineering feat produces a hard financial loss

◆

An engineer who has refactored a critical component, shifting its algorithmic complexity from quadratic to linear order — the very gesture whose progressive disappearance this thesis has established in Chapters I and II — can significantly reduce the organisation's real compute need. Under a Savings Plan or Reserved Instance subscribed on the basis of the former consumption level, documented in III.1, this reduction in real need produces no saving whatsoever: the contractual hourly spend commitment, made one to three years earlier, keeps applying regardless of actual consumption.

◆ The complete reversal of the incentive to optimise

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.

◆ The anticipatory lock-in as a freeze on technical debt

Faced with this reversal, the rational decision from the standpoint of the financial commitment already subscribed is to defer any refactoring or architectural migration until contract term — precisely to avoid producing an already-paid-for under-consumption. The financial instrument documented in III.1, designed to optimise a spend, thus produces the opposite effect of the one sought in Chapters I and II: it freezes the existing architecture, technical debt included, for the duration of the commitment made.

◆ What this section closes in the overall argument

Chapters I and II established the progressive disappearance of the optimisation gesture through authority displacement and disappearance of the technical constraint. This section establishes a third, more direct mechanism: beyond no longer incentivising optimisation, the financial instrument documented in this chapter actively penalises it once the commitment is made, closing the loop between finance and architecture that this thesis set out to demonstrate.

HUMAN

III.5

The Serverless objection — a refutation or a culmination?

The serverless paradigm does not contradict this thesis, it radicalises each of its mechanisms

◆

A hostile rapporteur might object that this thesis targets an outdated paradigm — provisioned instances and containers — while the cloud's cutting edge lies in Serverless (on-demand functions, fully managed databases), where the Capacity Planning documented in Chapter II is rendered obsolete by design, and where no multi-year commitment of the Reserved Instance type applies to a function billed per execution. This objection deserves direct examination rather than being ignored.

◆ Why Serverless radicalises H1 rather than invalidating it

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.

◆ Why Serverless radicalises H2 rather than invalidating it

Serverless does not merely remove the capacity constraint documented in Chapter II — it removes access even to the level at which algorithmic optimisation traditionally operated, kernel and I/O included. The engineer no longer manages architecture: they adjust execution-time parameters dictated by a platform over which they have no system visibility.

◆ What this section establishes for the rest of the thesis

Serverless refutes none of the three demonstrated hypotheses — it represents their terminal point, where the shift in authority and the disappearance of technical constraint reach their most complete form. The architectural reconquest of Chapter IV addresses primarily paradigms where a degree of technical latitude still remains — an explicit boundary of its scope, not an unidentified blind spot.

HUMAN

Chapter III Closing

H3 validated — transition to the Reconquest

◆

◆ The Thesis in One Sentence

Cloud promised to replace CapEx's rigid commitment with OpEx's freedom. The instruments that optimise this freedom recreate the commitment it claimed to have abolished — without ever recreating the asset that, under the old regime, guaranteed its counterpart.

◆ What Chapter III establishes, and what it does not yet establish

This chapter establishes the contractual mechanics of anticipatory lock-in and its shift of responsibility toward profiles not equipped to bear it. It has not yet formulated an architectural countermeasure to these three cumulated mechanisms — this reconquest is the subject of Chapter IV, the final chapter of this thesis.

HUMAN

Chapter IV

The Reconquest — The Return of Hard Limits

◆

The three preceding chapters demonstrated, hypothesis by hypothesis, how the accounting mutation (H1), the disappearance of the capacity constraint (H2), and the anticipatory lock-in of financial instruments (H3) progressively dissolved the engineering optimisation gesture. This closing chapter proposes a reconquest architecture directly responding to each of these three hypotheses — not through a financial governance recommendation, but through verifiable technical countermeasures.

HUMAN

IV.1

Restoring the gatekeeper — response to H1

Reintroducing architectural validation before any provisioning, without reintroducing CapEx's slowness

◆

Chapter I established that OpEx abolished the architect's gatekeeper role by removing the purchasing friction that, under CapEx, made their involvement mandatory. The reconquest does not consist of reintroducing that friction — a return to the multi-year purchasing cycle would be a step backward, not a solution — but of reintroducing an automated architectural validation, executed at cloud-provisioning speed rather than purchase-order speed.

◆ The mechanism — a declared and verified resource budget prior to deployment

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.

◆ What this mechanism does not restore on its own

This mechanism restores an architectural control point over provisioning — it does not on its own restore the code optimisation discipline documented as having disappeared in Chapter II, which is the subject of the following section.

HUMAN

IV.2

The return of hard limits — response to H2

Reintroducing finite-capacity constraint without reintroducing the physical server

◆

Chapter II established that auto-scaling removed the hard constraint that historically forced code optimisation, and that this same mechanism anaesthetises the alert signal that should have triggered an urgent correction. The reconquest consists of artificially reintroducing this hard constraint, at the orchestration level itself, rather than waiting for it to reappear at billing level.

◆ Capacity Planning reintroduced upstream of deployment

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.

◆ The link to the following section

This reintroduced Capacity Planning remains a documentary declaration as long as no technical mechanism makes it binding at the operating system level itself. This technical implementation is the subject of the protocol detailed in IV.3.

HUMAN

IV.2b

Transient infrastructure as a resilience guardrail

When the threat of provider-initiated destruction restores architectural discipline

◆

A second hard constraint, complementary to the one documented in IV.2, consists of imposing preemptible compute by default — instances the provider can interrupt at any time with short notice, in exchange for a reduced price — for any non-critical workload. This principle applies to infrastructure the same logic that chaos engineering, popularised by Netflix's internal tools, applies to software resilience: deliberately introducing a source of failure to force its architectural consideration.

◆ What this constraint mechanically imposes

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.

◆ What this constraint does not replace

Preemptible compute does not substitute for the quota protocol detailed in IV.3 — it operates at a different level, that of software design rather than resource allocation. The two constraints combine: one forces architectural resilience, the other forces compliance with a declared compute budget.

HUMAN

IV.3

Technical protocol — cgroup quotas and Kubernetes namespace in a CI/CD pipeline

A non-bypassable constraint, imposed by the kernel, not by a documented best practice

◆

This protocol formalises the technical implementation of the hard limit announced in IV.2, so that it is verifiable and non-bypassable — answering the methodological requirement set at this thesis's framing stage: an architectural reconquest must produce proof of implementation, not merely a recommendation.

◆ Step 1 — Budget declaration in the deployment manifest

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.

◆ Step 2 — Upstream verification in the CI/CD pipeline

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.

◆ Step 3 — Kernel-level enforcement via cgroups

Once deployed, each container has its resource limits enforced by the Linux kernel's control groups (cgroups), a mechanism Kubernetes itself relies on for resource isolation between containers. A process exceeding its declared memory limit is terminated by the kernel (OOM Killer, documented elsewhere in this collection of research), deliberately reproducing the hard alert signal documented as having disappeared in Chapter II — not as an accident this time, but as a deliberately reintroduced constraint.

◆ What this protocol guarantees, and what it does not guarantee

This protocol guarantees that an architectural budget overrun produces a hard, immediate technical signal — build failure or process termination — rather than a silent budgetary drift. It does not on its own guarantee that the development team will choose to optimise its code rather than renegotiate its budget upward — the latter option remaining a legitimate organisational decision, which this protocol merely makes visible and deliberate rather than silent and default.

HUMAN

IV.4

Decoupling financial commitment from technical decision — response to H3

Preventing a successful optimisation from producing a hard financial loss

◆

Chapter III established that multi-year commitment instruments financially penalise any optimisation reducing consumption below the subscribed level. The reconquest consists of structurally limiting the scope of this commitment rather than renouncing it entirely, preserving the sought price reduction without freezing the architecture for the full contract duration.

◆ Capping the commitment to the stable portion of load

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.

◆ The trade-off assumed by this countermeasure

This countermeasure does not eliminate the asymmetry documented in III.2 and III.4 — it reduces its scope, at the cost of a lower overall tariff discount than one obtained by committing the entire load. This is an explicit trade-off between immediate tariff savings and future technical reversibility, not an elimination of the trade-off itself.

HUMAN

General Conclusion of the Thesis

H1, H2 and H3 validated, a verifiable reconquest architecture

◆

◆ Synthesis of the reconquest architecture

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.

◆ Returning to the moral hazard announced in the introduction

The introduction posed moral hazard as the transversal thread of the three hypotheses: whoever writes the code does not see the invoice, whoever reads the invoice cannot modify the code, the infrastructure provider benefits from this separation. This chapter's four countermeasures each recombine, in their own way, what cloud had separated: IV.1 brings design authority closer to the provisioning decision, IV.3 brings the technical consequence of an overrun closer to its author, IV.4 brings the financial cost closer to the technical decision that determines it.

◆ The Thesis in One Sentence

Cloud did not eliminate the need for hard technical constraints. It merely made them optional — and an optional constraint, in an organisation under calendar pressure, is never applied.

◆ Open Call — Human Pull Request

This thesis is an open-source system awaiting real-world corrections. We explicitly invite any engineer or organisation having implemented all or part of this protocol to document their experience, and to correct or enrich this reconquest architecture.

◆◆◆

You do not restore engineering discipline by asking for it. You restore it by making its absence, once again, immediately costly.

◆◆◆

Amine RAITI · 2026

HUMAN

Methodological Appendix

Narrative summary of the process — from first framing to doctoral status

◆

This appendix does not reproduce the full verbatim of the exchanges that produced this thesis — their volume would have exceeded that of the thesis itself. It summarises the process, chapter by chapter, retaining the moments that concretely changed the text: the Gemini proposals that filled a real blind spot, the errors that had to be corrected, the independent factual verifications carried out before integrating a claim, and the final request for maximum reinforcement once the framework was validated.

◆ Why this format rather than the full verbatim

Previous volumes in this collection reproduced the full exchanges verbatim. This thesis required a noticeably higher number of audit rounds — the verbatim trace alone would have constituted a document longer than the thesis itself. This summary favours the readability of the process over the exhaustiveness of the quotation.

HUMAN

The Initial Framing

From subject choice to doctoral format

◆

Amine had initially submitted five candidate subjects for this fifth volume. Claude recommended the FinOps subject on a non-overlap criterion with already-published volumes, itself flagging that this subject had been set aside once before over overlap risk with The Cloud Illusion and The Gendered Amputation. Gemini validated the delimitation Amine proposed — treating the FinOps discipline as a symptom of loss of architectural control rather than a question of hardware ownership or career trajectory — and built the architecture itself around three hypotheses (H1 accounting mutation, H2 subsidy of laziness, H3 anticipatory lock-in) plus a reconquest chapter.

◆ The decision that changed the volume's format

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.

HUMAN

Chapter I — four rounds, two errors of different nature

The accounting mutation, from first draft to final assembly

◆

Chapter I's first draft was rejected by Gemini for insufficient academic depth — the text described the accounting authority shift without anchoring it in an interdisciplinary evidentiary apparatus. Gemini required two precise additions: the IFRS 16 accounting standard to prove the cloud shift had first been validated as a balance-sheet optimisation, and the Shadow IT mechanism to establish that FinOps was not preventive governance but an after-the-fact response to spending proliferation already committed.

◆ The discovery of an assembly error, not a content error

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.

◆ What this chapter established as discipline going forward

From this incident onward, Claude systematically verified his own internal references before each submission to Gemini, and explicitly flagged this in subsequent prompts — a practice that allowed later chapters to require fewer rounds.

HUMAN

Chapter II — the alarm anaesthesia, found in one round

The discipline of prior verification pays off

◆

Written as a single file rather than several pieces requiring reassembly — a direct lesson from Chapter I — this chapter was rejected only once. Gemini identified that the disappearance of Capacity Planning, already demonstrated, was not enough: what was missing was the mechanism by which auto-scaling does not merely remove the capacity constraint, but actively transforms the technical alert signal into a silent budgetary drift, artificially maintaining availability indicators at expected levels.

◆ A verification Claude made before submission, later validated by Gemini

While inserting this new section, Claude spotted a forward reference to a section not yet written at the point of reading — the same type of error as in Chapter I — and corrected it before submitting the draft to Gemini, explicitly flagging it in the audit prompt rather than letting Gemini discover it alone.

HUMAN

Chapter III — punishing optimisation as the keystone

The point where the financial demonstration finally meets the code

◆

The first draft established the contractual mechanics of Reserved Instances and Savings Plans, their structural comparison with CapEx, and an inedited study qualifying the engineer signing these instruments as a futures-market trader without a professional trader's tools. Gemini judged this content solid but incomplete regarding the thesis's central argument: nothing yet connected this financial mechanism to the dissolution of the engineering gesture, the founding argument of the entire volume.

◆ The addition that closed the loop of the demonstration

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.

HUMAN

Chapter IV — the reconquest validated in one round

Four countermeasures, one per demonstrated mechanism

◆

The thesis's final chapter, built to answer the three hypotheses term for term: restoring automated architectural authority without reintroducing CapEx's slowness, reintroducing Capacity Planning as a hard constraint, and above all a verifiable technical protocol — declaring Kubernetes quotas, blocking verification in the continuous-integration pipeline, actual enforcement by the Linux kernel's cgroups — answering the requirement Gemini set at the initial framing stage: a systems-engineering thesis had to produce proof of implementation, not merely a recommendation. Validated with no correction on the first draft.

◆ The only chapter to require no second round

The combination of single-file drafting and systematic reference-checking before submission, established over the three preceding chapters, allowed this final chapter to be validated directly.

HUMAN

The two rounds of maximum reinforcement

When conformity audit gives way to a request for expertise

◆

Once doctoral status was secured on all four chapters, Claude solicited Gemini for an exercise distinct from the usual audit: mobilising all available knowledge to reinforce the thesis beyond mere conformity, with no imposed scope limit. Gemini proposed several academic anchors (Jensen and Meckling's agency theory, Wirth's law, Williamson's transaction cost theory), a hostile-rapporteur objection to integrate and refute (the Time-to-Market argument, then the Serverless one), and two original economic mechanisms (moral hazard as a transversal thread, the observability tax).

◆ Independent verification before integration

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.

◆ The figure that was not retained

The observability tax proposal included a quantified order of magnitude (20 to 30% of the total bill) that Claude could not independently verify. The qualitative mechanism was kept and integrated; the figure was removed rather than cited without certainty.

HUMAN

What This Process Reveals

A reproducible method, not just a result

◆

Twenty-seven pages of thesis required close to fifteen rounds of exchange between Amine, Claude and Gemini, counting the initial framing, four chapters, and two reinforcement rounds. The number of rounds was not constant: four for the first chapter, only one for the last — the decline reflecting less a decreasing demand from Gemini than a growing verification discipline on the production side, particularly on points that had already caused an error once.

◆ The Thesis in One Sentence

The quality of a thesis produced by this process does not lie in the absence of errors made, but in the systematic verification that catches them before publication — on both sides.

← Previous Next →