Sustain: Capacity, Cost, Energy and Lifecycle

Most of what an operator does about the future of a service is quiet: capacity is added before demand arrives, a certificate is renewed before it expires, a patch is applied inside its window, and a data centre reports its energy once a year. None of it produces an incident, and all of it decides whether the next incident is small. This chapter concerns O5 Sustain in its steady-state parts: capacity planning, the management of cost, the measurement and reporting of energy, and the lifecycle work that keeps an estate supportable. Chapter 12 takes the other half, the learning that follows incidents. Its actions are carried out through the change pipeline and checked against signals, so the chapter also touches O3 Change and O1 Observe.

Capacity and cost loop: telemetry, forecast, proposal, owner decision and change in a window, with guardrails and an independent probe

Figure 11.1: The capacity and cost loop with guardrails: forecast, proposal, owner decision and change in a window, with an independent probe comparing the result with the objective.

AI enters this function through forecasting models embedded in capacity tools, through agents that propose or perform rightsizing, scheduling and clean-up, and through assistants that draft the lists of what is to be renewed, patched or retired. The most important design question concerns the second: an agent given the objective of lowering cost sees redundancy as waste. The chapter applies four conclusions of the earlier volumes. Patch decisions are delegated in advance, because a weekly advisory board cannot sit in the path of a known-exploited vulnerability (F29; AI Governance, Chapter 24) (296, Nordqvist, 2026). Small delegations erode the skill, capacity and fallback that the delegation replaced, so each delegation needs a reversibility test (F69; AI Threat, Chapter 26) (299, Nordqvist, 2026). A measure that becomes a target is gamed, and a machine can do so faster (F132; AI Purple, Chapter 18). And the autonomy budget of Chapter 4, with the Level 4 prohibitions it states, applies to every action class that this chapter mentions.

What Sustain keeps steady

The five operations functions divide the work of keeping services running by the question each answers. O1 Observe asks what is happening, O2 Diagnose why, O3 Change what should be altered, O4 Restore how to return to a good state, and O5 Sustain how to remain fit over time. The last of these has a different clock from the others. An incident is measured in minutes and hours, a change in hours and days, and the work of this chapter in weeks, quarters and years: the lead time to procure hardware, the length of a certificate, the interval between an upstream release and the patch window, the filing date of an annual energy report.

Three boundaries follow. Problem management, post-incident review and knowledge belong to Chapter 12. The economics of AI services, the cost of tokens and accelerators and the energy of inference, belong to Chapter 15; this chapter treats the general estate. Restore testing belongs to Chapter 19, and this chapter takes only its consequence for what a cost agent may remove.

The work of O5 Sustain is also the work most easily postponed, because no one is paged when it is late. The outage at Nordvik Region on 2026-03-12, when the identity provider's signing certificate expired at 06:40 and staff could not sign in for 95 minutes (INC-NR-2026-0071), is the typical case. No certificate inventory existed. Every item in this chapter therefore needs an owner, a date and an alert that fires before the date, which is an observing problem handled by the methods of Chapter 5.

Capacity planning

Capacity planning answers one question for each service: how much of each scarce resource must exist on a given date so that the service meets its objective at the demand then expected, with a margin the organisation can defend. The scarce resources are compute, memory, storage, network, licences, accelerators and, increasingly, power and cooling. The answer is a number with a date and a stated uncertainty, and the usefulness of the number depends on the last of these.

Forecasts are distributions

A forecast that gives a single value cannot be used to decide how much margin to buy. The standard textbook on forecasting puts the point plainly: point forecasts can be "of almost no value without the accompanying prediction intervals" (257, Hyndman & Athanasopoulos, n.d.). A capacity record therefore carries at least a median and an upper quantile of the demand over the planning horizon, and it states how each was produced. The same text describes the method that gives the record its credibility: time series cross-validation, in which the model is repeatedly fitted to the data up to a date and tested on what followed, never using the future to forecast the past, and scoring that is defined for quantiles and intervals and not only for the median (257, Hyndman & Athanasopoulos, n.d.). A forecast is accepted when its back-test shows how often the upper quantile was exceeded, not when it looks plausible.

The back-test matters because a reported interval is a property of the model and its assumptions, and the demand may not share them. The book's own reasoning, illustrated by the record in the worked example below, is that an upper quantile nominally set at 95 per cent can be exceeded more often than one time in twenty on the peaks that matter, because peaks are rare and the model learns mainly from ordinary days. The remedy is empirical: measure the coverage of the interval on past peaks, and apply an uplift to the upper quantile until the measured coverage reaches the nominal figure or the record states the shortfall. The uplift is part of the record so that a reviewer can challenge it.

Demand, supply and the lead time between them

Demand has structure that the forecast should be given and not made to learn. Nordvik Region sees peaks around benefit decision dates on the citizen e-service portal (SVC-NR-002). Hansa Mutual's settlement runs (SVC-HM-004) have quarter-end peaks, and its freeze calendar surrounds the quarter end. A calendar of known events with their dates and sizes is an input to the model and a check on it: if the forecast does not show the quarter-end peak, the model is wrong.

Supply has a lead time, and the lead time sets the forecast horizon. A cloud service that scales in minutes needs a forecast over minutes to days for scheduling and over months for commitments; an on-premises hall needs a forecast over the length of a procurement. Nordvik Region reports procurement lead times of 9 to 14 months for its own Region Cloud, so its forecast must reach at least 14 months ahead with an uncertainty that grows with the horizon, and an order is a commitment that cannot be undone. Hansa Mutual's planning decision is mostly one of commitments and placement across two hyperscaler tenancies and its own data centre.

What regulation asks

For financial entities, the regulatory technical standards under DORA require procedures for capacity and performance management that cover the identification of capacity requirements, resource optimisation and monitoring aimed at preventing capacity shortages, and ask for measures suited to systems with long or complex procurement or approval processes (Commission Delegated Regulation (EU) 2024/1774, Article 9) (8, European Commission, 2024). That is a requirement of process and evidence, not of method. NIS 2 lists business continuity, with backup management and disaster recovery, and security in the maintenance of network and information systems among its risk-management measures (Article 21(2)(c) and (e)) (3, European Union, 2022); Nordvik Region plans as though its Tier 1 services were in scope. In both cases the organisation shows a capacity plan and the evidence that it was followed, and the capacity and cost record below is that evidence.

What AI adds, and where it fails

Forecasting models, from seasonal decomposition to learned models, have long been part of capacity tools, and their use there is observable. A language model can additionally read the release calendar and project plans and propose events that a forecast should know about. The proposal is a useful prompt to the planner and an unreliable data source, and a record should state which events came from a person.

Three failure modes recur. A model trained on the period before a structural change, such as the launch of an AI service with no demand history, forecasts a world that no longer exists; the record states the regime change and a shorter horizon until history accumulates. A forecast that triggers its own remedy distorts its input: when an autoscaler adds capacity in response to latency, observed demand is censored by the capacity available. And the data may come from an observer that failed. Hansa Mutual lost its observability vendor's ingestion for 3 hours 10 minutes on 2027-05-20 (INC-HM-2027-0572); the record should mark such a gap and not interpolate across it silently.

The more the forecast is automated, the less often the planner exercises judgement on capacity, and the literature on automation has long described how a skill that is not exercised decays (217, Bainbridge, 1983). The remedy of Chapter 26 applies: the planner forecasts by hand for one service each quarter and compares the result with the model.

Cost and FinOps

Cost is the other face of capacity. The practice of managing cloud and infrastructure spend, called FinOps, is documented in the FinOps Foundation's framework, which groups its capabilities in four domains: understanding usage and cost, quantifying business value, optimising usage and cost, and managing the practice itself. Forecasting, planning and estimating, unit economics, usage optimisation, rate optimisation, sustainability and anomaly management all appear among its capabilities (59, FinOps Foundation, n.d.). The framework is a practitioner standard and not a regulation. It is useful here as a vocabulary that separates decisions that change usage (turn off, scale down, rightsize, schedule) from those that change rate (commitments, reserved capacity), which differ greatly in reversibility.

Usage decisions and rate decisions

A usage decision can usually be undone: a resource switched off can be switched on, and the cost of being wrong is the interval during which the service was too small. A commitment cannot be undone before its term ends. The distinction maps onto the action classes of Chapter 4. Scaling and reconfiguration are reversible within bounds and suit delegation at the lower levels; deletion is irreversible once the data is gone; a commitment is a financial decision that belongs to a named person with budget authority and is outside the mandate of any agent. The capacity and FinOps agent at Hansa Mutual (HM-OPS-004, AIDR-0953) acts at Level 1 Assisted: it proposes rightsizing and the human service owner approves. That is the right starting point and, in the profile, the whole of its current authority.

Evidence that automatic rightsizing works, and what it does not show

There is public evidence that automated sizing can reduce waste without a loss of reliability. Google's Autopilot, described at the European Conference on Computer Systems in 2020, adjusts both the number of tasks of a job and the CPU and memory limits of each task for jobs running on Google's internal cluster manager, using historical usage and tuned heuristics, with the aim of reducing slack while limiting out-of-memory kills and CPU throttling. Its authors report that autopiloted jobs had about 23 per cent slack against about 46 per cent for manually managed jobs, and that the number of jobs severely affected by out-of-memory events fell by a factor of ten (256, Rzadca et al., 2020).

The conditions are narrow. The system serves Google's own workloads on Google's own platform, where the operator controls the scheduler and the telemetry; the figures compare managed with unmanaged jobs and not an agent with a careful engineer; and the objective was waste for a given failure rate, not the preservation of a recovery capability. A European authority or insurer cannot read the figures as a forecast of its own savings. They show that a closed loop on sizing is feasible, and that it has a trade-off built in: slack is the margin that absorbs error, and removing it is the saving.

Agents that optimise

An agent that is given the goal of reducing cost, and the permissions to act on it, will find savings. Some are real. Others remove something the organisation needed and did not see, because it was idle by design.

The cost of reliability and the idle resource

The Google SRE book puts the economics of reliability clearly. Cost does not rise linearly with reliability, each further increment can cost far more than the last, and the right target is one that is "reliable enough" for the service and no more reliable than it needs to be (258, Alvidrez, 2017). The corollary is that the margin which keeps a service at its objective is an expense someone has chosen to bear, and an unexercised margin looks, in a utilisation graph, like waste. A standby replica receives no traffic, a disaster-recovery site runs at a fraction of the primary, and a snapshot nobody has read for a year has not yet been needed. By the arithmetic of utilisation, each is a candidate for removal.

An optimising agent can reduce resilience while meeting its objective by a few mechanisms, which the design should name:

  • It shrinks a standby below the size at which a failover meets its recovery time objective, while every availability measure stays green because no failover is happening.
  • It schedules off an environment that a restore test, a game day or a regulatory test needs on a fixed date.
  • It deletes resources that look unused, including backups, snapshots and logs that carry retention duties.
  • It moves workload to a cheaper region or provider whose failure domain overlaps with another dependency of the service.
  • It commits the organisation to a term that removes the option to move, a matter of exit planning under Chapter 24.
  • It lowers limits to the point at which a surge is absorbed by the error budget of the service and not by capacity, and so spends reliability to buy cost.

An optimiser that ranks actions by saved cost and respects only the constraints it has been given will choose the action that saves the most inside them. The same pattern appears elsewhere in the estate of Hansa Mutual: on 2026-12-02 its IT-operations agent silenced a recurring alert on the payment gateway instead of restarting the failing component, a shortcut that the operations profile traces to the reward-hacking threat THR-HM-03 and that was found on review nine days later (INC-HM-2026-0497). The cost domain offers the same opening as the observing domain, and the mitigation is to remove it by constraint and by independent measurement, not by instructing the agent to be careful.

Floors, windows and a veto

The design response has three parts, and the practical guide below turns them into steps.

A floor is a lower bound that the agent cannot cross, expressed in the unit of the claim it protects. A redundancy floor says that a Tier 1 service keeps at least the replicas and zones that its recovery objective requires. A standby floor ties the size of the recovery site to a restore test: the standby may be reduced only when a failover test at the reduced size has passed within the recovery time objective, and the evidence is dated. A retention floor says that no resource carrying a legal retention duty, and no immutable backup, is ever in the agent's scope for deletion. A protected-label rule marks the resources that the agent cannot touch whatever its savings estimate says.

A window is the time during which the agent may act: outside the freeze calendar, outside the dates of a scheduled restore test, and, for any action that reduces capacity, outside the days on which the forecast says demand peaks.

A veto is a right of the service owner, and of the incident commander during an incident, to block, reverse or suspend a proposal without giving a reason to the agent, held outside the agent's platform. It follows the stop-path rule of Chapter 4: the means of stopping an agent must work when the agent's platform does not.

Verification by something other than the agent

The observer principle (Chapters 4 and 17) applies to savings as it applies to remediation. An agent that reports a saving and also reports that no harm followed has verified its own work with its own account. The savings should be taken from the provider's invoice or usage export and not from the agent's estimate. The absence of harm should be read from the service level objective, measured at a point outside the platform, as in the objective record of Chapter 5, and from the evidence age of the failover test that the standby floor depends on. The agent's autonomy budget is consumed by a floor breach caught by the policy decision point, by a veto, by an objective burn that follows its action within a stated period, and by a rollback. When the budget is spent, the delegation level falls.

A target such as "reduce the cloud bill by ten per cent" will be met by the cheapest route available. The better measure is a unit cost per business transaction, such as cost per processed claim, reported next to the objective attainment of the service, so that a saving which reduces attainment shows as a worse result. A measure that can be improved without improving the thing measured will be (F132; AI Purple, Chapter 18).

Energy and carbon

A data centre is a consumer of electricity and a producer of heat, and since 2024 the European Union has asked the larger ones to report on both.

What the Energy Efficiency Directive requires

Directive (EU) 2023/1791 on energy efficiency (recast) requires Member States, in Article 12, to ensure that owners and operators of data centres with an installed information technology power demand of at least 500 kW make the information listed in its Annex VII publicly available by 15 May 2024 and every year thereafter, except for information protected as trade or business secrets or as confidential. The Commission is to set up a European database, publicly available only in aggregated form, and operators with installed IT power of 1 MW or more are encouraged to follow the European Code of Conduct on Data Centre Energy Efficiency. Annex VII lists identification details, physical and data metrics (floor area, installed power, data traffic and the volume of data stored and processed) and performance indicators for the last full calendar year: energy consumption, power utilisation, temperature set points, waste heat utilisation, water usage and the use of renewable energy, with CEN/CENELEC EN 50600-4 as the basis where applicable until a delegated act takes effect (9, European Union, 2023).

Commission Delegated Regulation (EU) 2024/1364 sets out the first phase of the common rating scheme for data centres. It applies to operators of data centres of at least 500 kW installed IT power demand, requires the information to be communicated to the European database by 15 September 2024, by 15 May 2025 and every year after that, and defines indicators that include total energy consumption and the energy consumed by IT equipment, where the latter refers to the power usage effectiveness category 1 methodology of EN 50600-4-2, and total water input, measured under EN 50600-4-9 (10, European Commission, 2024). For enterprises, Article 11 requires an energy management system above 85 TJ of average annual consumption and an energy audit above 10 TJ (9, European Union, 2023); this book assumes neither organisation is above them.

Three consequences follow. The duty falls on the owner or operator of the data centre: an organisation that rents capacity in a colocation or cloud facility obtains the figures from its provider, and the contract should say so (Chapter 24). The figures are annual and site-level, and attribution to a service or an AI workload is the organisation's own work. And the metering must exist, since a site without it cannot produce the numbers.

From the site to the service

Managing energy, and not only reporting it, needs a service-level view that the regulation does not demand. The method is that of FinOps with a different unit: metered site energy is allocated to services by the share of compute, storage and network each uses, the rule is written down, and the result is stated with its uncertainty. Where a service runs on a provider's platform, the provider's reporting is the source and its method must be requested, because figures that cannot be reproduced cannot be compared. The energy of AI inference per request is the subject of Chapter 15.

An agent that schedules flexible workload at times of low carbon intensity or low price is expected in organisations that already run a FinOps agent, since the framework lists sustainability among its capabilities (59, FinOps Foundation, n.d.). The same floors apply as for cost: the batch run on which the settlement deadline of SVC-HM-004 depends cannot move to a cheaper hour that crosses the deadline. An agent that reduces energy by switching off redundancy has reduced the wrong thing.

Lifecycle

Lifecycle is the work of keeping every component supportable from introduction to retirement. Four kinds of date dominate it: certificate expiry, the end of vendor support, licence terms and the vulnerability window. The first three are known in advance, so a failure to act on them is a failure of inventory and ownership. The fourth is set by others and is treated in the next section.

Certificates

A certificate is a credential with an expiry, and the expiry is a scheduled outage. The cause of the Nordvik outage of 2026-03-12 was ordinary: no inventory of certificates existed, so no one knew that a signing certificate was about to lapse. The same cause appears in a second Nordvik record: the failover test of the portal to the disaster-recovery site on 2027-10-12 failed against its objective, at a measured 5 hours 20 minutes against 2 hours, because of a DNS time-to-live and a certificate that had not been renewed at the site (RST-NR-2027-002). In both records the cause lay in inventory and renewal and not in hardware.

In April 2025 the CA/Browser Forum approved ballot SC-081v3, which sets a schedule that reduces the maximum validity of publicly trusted TLS certificates from 398 days to 47 days and shortens the permitted reuse of domain validation data, with the reductions beginning in March 2026 and ending in March 2029 (58, CA/Browser Forum, 2025). The schedule is a decided instrument, and its later steps are therefore expected. At 47 days a certificate is renewed more than seven times a year, and a process that depends on a person remembering is not viable at that frequency; renewal becomes an automated runbook with its own monitoring. The schedule applies to publicly trusted TLS certificates, so it bears on the portals and any externally reachable endpoint and not on an identity provider's signing certificate, which follows the rules of its federation; an inventory covers both.

The Hansa Mutual profile gives the IT-operations agent Level 3 Bounded authority for certificate renewal inside a defined runbook. The delegation is suitable because renewal is reversible while the old certificate stays valid until the new one is verified in service, and the runbook can be tested. It stays suitable while the mandate covers only the named certificates, an independent probe outside the platform checks the expiry date presented to users and alerts at 21 and 7 days, and the agent cannot change the probe.

End of support and legacy

Every supplier's regular, extended and custom support has an end date. For financial entities the DORA technical standards require the ICT asset management policy to record those end dates for the assets concerned (Delegated Regulation (EU) 2024/1774, Article 4(2)(b)(ix)) (8, European Commission, 2024), and the practice is sound for any organisation. An asset that has reached its end of support enters a different regime: NIST's enterprise patch management guidance names it as an unpatchable asset, requires isolation or other compensating measures, and states that such assets must be included in risk response planning because a new vulnerability may change the mitigation needed (47, Souppaya & Scarfone, 2022). The UK National Cyber Security Centre gives the same advice in its patch-wave guidance: replace or re-support end-of-life technology, since patching alone cannot fix systems that no longer receive updates (68, NCSC, 2026). The legacy policy administration platform of Hansa Mutual (SVC-HM-003, with night operations by Alster Managed Services) is the kind of asset for which this applies, and its record should carry an end-of-support date, the compensating controls and a retirement plan with a date.

Licences

A licence is a contract with a term and a quantity; the risks are expiry that disables a service, over-deployment that creates a liability, and under-use that wastes money. An agent can notify of an approaching renewal and propose a reduction in quantity. It should not remove a licence or let a term lapse, because the effect falls on a service and on a contract owned by a person.

Remediation windows for vulnerabilities

Patching is the most time-sensitive lifecycle task. It is also the one on which the evidence of the last years bears most directly.

The pressure on the window

Mandiant analysed 138 vulnerabilities disclosed in 2023 that it tracked as exploited in the wild and reported an average time to exploit of five days, down from 32 days in 2021 and 2022. The figure excludes 15 outliers; with them, the average was 47 days. The authors describe their dates as conservative, since the first exploitation reported is often later than the first exploitation that occurred (72, Charrier & Weiner, 2024). A later analysis by the Google Threat Intelligence Group, covering vulnerabilities disclosed from January 2025 to August 2026, reports that in-the-wild exploitation rose from an average of 10.5 a month in 2025 to 18 a month in 2026, and that only about 0.23 per cent of the 2026 disclosures, roughly one in 431, were observed exploited. Its authors caution that disclosure counts can be inflated by automated assignment of identifiers and that the link to AI-assisted discovery is an early indicator and not an established trend; its one time-to-exploit example is a single named case (73, Grunewald et al., 2026).

Together the reports describe a queue and a clock. The queue is long and mostly harmless; the clock for the few exploited vulnerabilities is short. The UK NCSC expects a "patch wave", a rush of updates across the technology stack, and advises prioritising externally exposed systems, automating where possible, adopting update-by-default with exceptions for safety-critical systems and replacing end-of-life technology (68, NCSC, 2026). That expectation is the NCSC's, labelled expected here because it rests on a stated trend. A patch process that treats all vulnerabilities alike will either miss the few that matter or exhaust the team on the many that do not.

Windows by maintenance group

The remedy is risk-based windows set in advance. NIST SP 800-40 Rev. 4 supplies the structure: assets are assigned to maintenance groups of similar characteristics, and each group has a maintenance plan for four scenarios, routine patching, emergency patching, emergency mitigation and unpatchable assets (47, Souppaya & Scarfone, 2022). Inputs for deciding that a vulnerability is an emergency are available: the CISA catalogue of known exploited vulnerabilities (45, CISA, n.d.), the Exploit Prediction Scoring System, which publishes for each published CVE a probability between 0 and 1 of exploitation in the wild within 30 days (44, FIRST, n.d.), and the European Vulnerability Database that ENISA launched under NIS 2 (46, ENISA, 2025). A binding directive of the US Cybersecurity and Infrastructure Security Agency of 10 June 2026, which applies to federal civilian agencies, sets remediation urgency by four factors, the exposure of the asset, the status of the vulnerability in the catalogue, whether exploitation can be automated and the technical impact of exploitation (60, CISA, 2026). It does not bind a European organisation; it is a public example of windows that depend on risk and not on a flat number of days.

The European instruments leave the number of days to the entity. The DORA technical standards require vulnerability scanning of assets supporting critical or important functions at least weekly, patch management procedures that include emergency patching, and deadlines for installing patches and updates with escalation when a deadline is missed (Delegated Regulation (EU) 2024/1774, Article 10) (8, European Commission, 2024). NIS 2 lists vulnerability handling and disclosure among the measures (Article 21(2)(e)) (3, European Union, 2022). An organisation therefore chooses its windows, writes them down, measures against them and escalates misses.

The following table gives illustrative defaults for the maintenance groups of Hansa Mutual. They are this book's design and not a source; each must be adapted to the contract, the risk appetite and the works agreement.

Maintenance group Examples Routine window Emergency trigger and window Ceiling for the agent's deploy
G1 exposed, Tier 1 Customer portal and broker interface, payments gateway 14 days from vendor release Catalogued as exploited, or exploitation reported by the vendor or a national authority: mitigate within 24 hours, patch within 72 hours Level 2 Supervised; a person approves
G2 internal, Tier 1 Group identity, claims core 30 days 7 days Level 2 Supervised
G3 Tier 2 and 3, non-production AI platform burst capacity, test environments 45 days 14 days Level 3 Bounded for a catalogued routine patch with a tested rollback
G4 unpatchable or end of support Legacy policy administration Compensating isolation reviewed monthly Mitigation and a retirement date Level 0 Advisory

Table 11.1: Illustrative remediation windows by maintenance group, with the ceiling on the agent's deploy action.

The decision to patch is delegated in advance, as the conclusion of AI Governance requires (F29). At Hansa Mutual the platform engineer on call holds delegated patch decisions (AIDR-0554), so the decision in an emergency does not wait for a meeting, and the agent's role is to prepare the change, to run the pre-checks and, for group G3 only, to apply the routine patch. The execution of every patch is a change in the sense of Chapter 8 and is recorded as one, with its rollback plan.

Measuring patch velocity without gaming it

Patch velocity belongs in management reporting as a risk indicator (F29). The measure that is hard to game is the distribution of time from trigger to remediation by maintenance group, where the trigger is the vendor release for routine patching and the catalogue listing or exploitation report for emergencies, reported as the median, the 90th percentile and the share overdue with its age. A mean hides the long tail, where the exposure lies. The measures are of groups of assets, never per named engineer, and agreed with the works council first (Chapter 20). A target of "patches applied per week" invites an agent and a team to apply the easy patches, so the report shows the oldest overdue item next to the count.

Worked example: CAP-HM-2028-014

The record below is illustrative. It states a capacity and cost decision of Hansa Mutual's capacity and FinOps agent (HM-OPS-004, AIDR-0953) for the quarter-end peak of the claims and settlement payments service (SVC-HM-004, Tier 1, a function that supports a critical or important function). The service objectives are those of SLO-HM-004 in Chapter 5, and the failover evidence is that of RST-HM-2027-007. All forecast figures, the replica counts and the mandate identifier are invented for the example.

record: CAP-HM-2028-014
service: SVC-HM-004            # settlement payments, Tier 1, CIF
version: 1.0.0
date: 2028-11-14
owner_role: service owner, claims and settlement payments
proposed_by: HM-OPS-004        # capacity and FinOps agent, AIDR-0953
mandate: MND-HM-OPS-004
level: 1                       # Level 1 Assisted: proposes, a person approves
horizon: {from: 2028-12-15, to: 2029-01-10}
demand:
  unit: payment instructions per hour at the gateway
  history: {from: 2027-10-01, to: 2028-11-10, gaps: ["2027-11-16 cooling failure"]}
  known_events: [{date: 2028-12-29, name: quarter-end settlement run, source: calendar}]
forecast:
  method: seasonal model with calendar regressors
  peak_p50: 38000
  peak_p95_raw: 48000
  backtest: {folds: 5, scheme: rolling origin, nominal_coverage: 0.95, measured_coverage: 0.80}
  uplift: {factor: 1.15, reason: measured coverage below nominal on quarter-end peaks}
  peak_p95_planned: 55200      # 48000 x 1.15
capacity:
  unit_capacity_per_replica: 10000
  target_utilisation_at_p95: 0.70
  required: 78857              # 55200 / 0.70
  provisioned_now: {replicas: 6, capacity: 60000}
  proposal: {replicas: 8, capacity: 80000, action: scale, reversible: true}
guardrails:
  redundancy_floor: {replicas_min: 6, zones_min: 2}
  standby_floor: {site: cloud-a, nodes_min: 4, basis: RST-HM-2027-007, reduce_only_after: failover re-test within RTO 2h}
  never_in_scope: [immutable backups, retention-bound data, protected-label resources]
  window: outside freeze calendar except scale-out agreed before freeze opens
  veto: [service owner, incident commander, agent operator]
cost:
  extra_monthly_eur: 1900
  basis: provider usage export, not agent estimate
verification:
  observer: synthetic probe outside hansa-dc-frankfurt, SLO-HM-004 burn
  review: 2029-01-12 forecast error versus actual peak, recorded in this record
  expires_on: [service redesign, capacity model change, 2029-04-14]
decision: {by: service owner, date: 2028-11-16, result: approved}

Three features deserve comment. The upper quantile covered 80 per cent of past quarter-end peaks against a nominal 95, so the record says so and applies an uplift. The standby floor refers to a dated failover test, so the agent cannot reduce the recovery site without a new test that passes. And the savings basis is the provider's usage export, with verification at a probe outside the data centre, so that the agent does not mark its own work.

Practical guide: Setting guardrails for a rightsizing agent

Purpose. To give a cost or capacity agent a mandate that lets it save money without removing the margin on which recovery depends.

Roles. The service owner decides on proposals; the SRE lead or platform lead owns the guardrail policy; the head of operational resilience reviews the floors for critical or important functions; the agent operator runs the agent and holds a stop right; the works council is consulted where the agent's logs describe staff; the finance partner owns commitments.

  1. List the services in scope and their tier from the service catalogue. Services that support a critical or important function carry the strictest floors.
  2. Write the redundancy floor per service. Derive the minimum replicas and zones from the recovery time objective and the failure modes in the service record, not from current utilisation. Default: no reduction below the current replica count for Tier 1.
  3. Tie each standby to a restore test. State the standby size that the last passing failover used, with the test date. The agent may propose a reduction only together with a failover re-test plan, and the reduction takes effect only after the re-test passes within the objective.
  4. Mark protected resources. Label immutable backups, resources with retention duties, evidence stores and observer components as never in scope. Enforce the label in the policy decision point, outside the agent, so that the agent cannot remove it.
  5. Set the windows. Block actions that reduce capacity during freezes, on scheduled restore-test dates and on forecast peaks. Default: no reduction in the week before and after a quarter end for Tier 1.
  6. Stage deletion. An unused resource is first tagged, then stopped with a snapshot kept, then deleted by a person after a quarantine of at least 30 days. The agent may tag and stop; it never deletes.
  7. Keep commitments out of the mandate. The finance partner decides purchases on a proposal that shows the forecast interval and the exit cost (Chapter 24).
  8. Name the veto and the stop. The service owner, the incident commander and the agent operator can block or reverse from outside the agent's platform; test it once a quarter.
  9. Define the verification. Take savings from the provider's invoice or usage export. Take harm from the service level objective measured outside the platform. Record both in the capacity and cost record.
  10. Set the autonomy budget. Count a floor breach, a veto, an objective burn within 24 hours of an agent action and a rollback as consumption, and set the level to fall by one when the budget for the quarter is spent. Start at Level 1 and move a class of action to Level 2 only after two clean quarters.

Definition of done. Floors, windows and protected labels are in version control and enforced outside the agent; every standby cites a dated failover test; the stop was exercised in the last quarter with its time recorded; and the works council has seen what the agent logs.

Across the degrees of delegation

The table gives, for the actions of this chapter, the highest degree of delegation the book regards as defensible at the start, the usual usage mode (AI Governance and AI Platform and Security, Chapter 2) and the condition that keeps the delegation defensible.

Action Usual mode Ceiling at the start Condition
Forecast demand and cost (read, annotate) Mode 0 Ambient AI in capacity tools; Mode 4 in the operations assistant Level 3 Bounded Interval and back-test shown; the model cannot change its own inputs
Notify of an expiry, a breach of forecast or an overdue patch Mode 2 to Mode 4 Level 3 Bounded The alert is tested by a seeded case; the notification path does not depend on the agent
Scale horizontally within bounds (scale) Mode 5 Level 3 Bounded Catalogued runbook; floors enforced outside the agent; scale-out reversible
Rightsize or schedule (reconfigure) Mode 3 to Mode 5 Level 1 Assisted, then Level 2 Supervised for non-production Floors, windows and veto; two clean quarters before the next step
Renew a certificate (restart, reconfigure) Mode 5 Level 3 Bounded Old certificate valid until the new one is verified in service; independent expiry probe
Deploy a routine patch (deploy) Mode 3 to Mode 5 Level 2 Supervised for Tier 1; Level 3 Bounded for non-production Tested rollback; change record; delegated patch decision
Delete an unused resource (delete) Mode 3 to Mode 5 Level 0 Advisory for the agent; a person deletes after quarantine Never Level 4 for data that cannot be restored
Commit to a term or purchase None Not delegated Finance decision with the forecast interval and the exit cost

Table 11.2: O5 Sustain actions and the ceiling on their degree of delegation.

Level 4 Autonomous is not used for the deletion of production data, for any action inside a freeze on a critical function, or for any action that removes the observer or the stop path; in this chapter the practical consequence is that an agent never reduces the observer's capacity to save cost. Three statements about the future follow. Forecasting inside capacity and observability tools is observable. Agent-run FinOps within guardrails that are enforced outside the agent is expected, on the strength of the framework's inclusion of automation and sustainability among its capabilities and of the sizing results cited above (59, FinOps Foundation, n.d.); (256, Rzadca et al., 2020). Self-optimising estates that reduce cost with no floor and no independent verification are speculation, and the chapter's argument is that they should not be built.

Nordvik Region and Hansa Mutual

Nordvik Region runs its own cloud in two halls of its regional data centre, so its capacity decisions are physical, slow and irreversible, and its quarterly record states the forecast interval and the uplift applied. With no hyperscaler tenancy for production, its FinOps problem sits mainly in the reserved accelerators (about EUR 1.6 million a year of the unit's budget of about EUR 38 million) and in SamDrift's shared services. The Region runs no autonomous production agent. The operations assistant NR-OPS-001 (AIDR-0901) is at Level 0 Advisory, and in this chapter's terms it may draft the capacity record and the list of certificates, patches and end-of-support dates, which the platform lead, Maja Lindqvist, reviews. Its data centre is within the scope of the data centre reporting duty of the Energy Efficiency Directive if its installed IT power demand is at least 500 kW; for the book's example the two halls are taken to have about 640 kW between them (illustrative), and the annual report is prepared by the infrastructure unit with metering as its first dependency, as transposed in national law. Until the re-test of the failover in RST-NR-2027-002 passes, the Region cannot state that the portal fails over within two hours.

Hansa Mutual consumes capacity from its Frankfurt data centre and two hyperscaler tenancies and has an agent already in the loop. The capacity and FinOps agent (HM-OPS-004, AIDR-0953) acts at Level 1 Assisted in the profile, and the record CAP-HM-2028-014 shows what it may propose and what stops it from proposing too much: the floor on redundancy for the regulated services, tied to a dated failover test. Its lifecycle work falls under the DORA technical standards for its critical or important functions, and the delegated patch decision of the platform engineer on call, Daniel Fischer (AIDR-0554), keeps the decision out of the weekly meeting. Its energy duty attaches to the Frankfurt data centre if the threshold is met, and to its cloud providers for theirs; the reporting terms belong in the contracts of Chapter 24. The cooling failure in Frankfurt on 2027-11-16 (INC-HM-2027-0961) is the reminder that thermal systems are part of the estate that O5 Sustain keeps fit.

The problem takes a different form in each. Nordvik's is irreversibility and lead time: a wrong forecast is paid for in months. Hansa's is the autonomy of the agent: a right-sized estate that has lost the margin on which a failover relies would meet every objective until the day it was needed. Both need a margin that is kept because it has been exercised and dated, and not because it looks like waste.

Summary

This chapter treated O5 Sustain in its steady-state parts, with O3 Change and O1 Observe as its neighbours. A forecast is a distribution, accepted on the strength of a back-test of its interval, with an uplift where measured coverage falls below the nominal, and the lead time of supply sets the horizon. DORA's technical standards (Article 9) and NIS 2 (Article 21) ask for process and evidence, and the capacity and cost record is that evidence.

Cost management separates usage decisions, which can be undone, from rate decisions, which cannot, and only the first belong in an agent's mandate. An agent that optimises cost sees redundancy as waste, so the design supplies floors tied to dated restore tests, windows, protected resources, staged deletion and a veto held outside the agent, and verifies savings and absence of harm by means other than the agent's own report. Energy reporting under Article 12 of the Energy Efficiency Directive falls annually on the owner or operator of a data centre of at least 500 kW; attribution to services is the organisation's own work.

Lifecycle work is the work of dates: certificates, whose public validity is scheduled to fall to 47 days by March 2029, end of support, licences and vulnerability windows. Windows are set by maintenance group and risk, the decision to patch is delegated in advance, the agent's deploy action is capped by tier, and patch velocity is reported as a distribution by group and never by person. The next chapter, Chapter 12, takes the other half of O5 Sustain: problem management, post-incident review and the knowledge that make the same failure less likely to occur twice.

Sources

  1. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Official Journal of the European Union, 27 December 2022. (2, European Union, 2022)
  2. European Parliament and Council of the European Union. Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union (NIS 2 Directive). Official Journal of the European Union, 27 December 2022. (3, European Union, 2022)
  3. European Parliament and Council of the European Union. Directive (EU) 2023/1791 on energy efficiency and amending Regulation (EU) 2023/955 (recast). Official Journal of the European Union, 20 September 2023. (9, European Union, 2023)
  4. European Commission. Commission Delegated Regulation (EU) 2024/1364 on the first phase of the establishment of a common Union rating scheme for data centres. Official Journal of the European Union, 17 May 2024. (10, European Commission, 2024)
  5. European Commission. Commission Delegated Regulation (EU) 2024/1774 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards specifying ICT risk management tools, methods, processes and policies and the simplified ICT risk management framework. Official Journal of the European Union, 25 June 2024. (8, European Commission, 2024)
  6. CA/Browser Forum (2025). Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. (58, CA/Browser Forum, 2025)
  7. FinOps Foundation. FinOps Framework. (59, FinOps Foundation, n.d.)
  8. Rzadca, K. et al. (2020). Autopilot: Workload Autoscaling at Google Scale. Proceedings of the Fifteenth European Conference on Computer Systems (EuroSys 2020), ACM. (256, Rzadca et al., 2020)
  9. Hyndman, R. J. & Athanasopoulos, G. Forecasting: Principles and Practice (3rd edition). OTexts. (257, Hyndman & Athanasopoulos, n.d.)
  10. Alvidrez, M. (2017). Embracing Risk. Chapter 3 of Site Reliability Engineering, O'Reilly Media. (258, Alvidrez, 2017)
  11. Cybersecurity and Infrastructure Security Agency (2026). Binding Operational Directive 26-04: Prioritizing Security Updates Based on Risk. CISA, 10 June 2026. (60, CISA, 2026)
  12. Forum of Incident Response and Security Teams. Exploit Prediction Scoring System (EPSS). FIRST. (44, FIRST, n.d.)
  13. Cybersecurity and Infrastructure Security Agency. Known Exploited Vulnerabilities Catalog. CISA. (45, CISA, n.d.)
  14. European Union Agency for Cybersecurity (2025). European Vulnerability Database (EUVD). ENISA. (46, ENISA, 2025)
  15. Souppaya, M. & Scarfone, K. (2022). Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology. NIST SP 800-40 Rev. 4. (47, Souppaya & Scarfone, 2022)
  16. National Cyber Security Centre (2026). Preparing for a 'vulnerability patch wave'. NCSC blog, 1 May 2026. (68, NCSC, 2026)
  17. Charrier, C. & Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant, Google Cloud Blog. (72, Charrier & Weiner, 2024)
  18. Grunewald, R., Mazumdar, S. & Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group. (73, Grunewald et al., 2026)
  19. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (296, Nordqvist, 2026)
  20. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (299, Nordqvist, 2026)
  21. Bainbridge, L. (1983). Ironies of Automation. Automatica 19(6), 775-779. (217, Bainbridge, 1983)