Capacity, Cost and Energy Tools

This chapter serves the activity of keeping a service big enough, affordable and measurable in its use of energy: forecasting demand, sizing capacity, attributing cost to the people who cause it, limiting consumption by policy and stating what a service's energy use was. The tools come from four of the earlier volumes. Architecture as Code (1, Nordqvist, 2025) supplies the infrastructure-as-code cost controls and the first sustainability listing; AI Governance (2, Nordqvist, 2026) supplies the allocation map, the consumption envelope and the forecast; AI Platform and Security (3, Nordqvist, 2026) supplies the capacity plans, the routing policy and the carbon calculation; AI Operations (10, Nordqvist, 2026) supplies the capacity record, the cost-and-latency budget and the rules that govern an agent that sizes capacity. The kinds are all four: artefacts (plans, maps, records, budgets), own listings of code that the volumes show, third-party tools and standards (the FinOps Framework, the Software Carbon Intensity specification, OpenCost, KEDA, vLLM and others) and a short list of methods.

The chapter's questions are the brief's: which records steer the cost of AI services, and how is energy accounted for? The answer the volumes give to the first is that a decision is taken before money is committed and is held in a file that the gateway or the pipeline reads, so that a budget is enforced by the system and not discovered on an invoice. The answer to the second is that an energy claim is a measurement with a boundary, a period and a count, and that where no metered figure exists the honest record says so and names who will supply one.

Two boundaries. Procurement and exit terms for the hosting and model providers belong to Chapter 9, and the observability data on which cost and capacity signals depend to Chapter 15. Chapter 16 holds the change and restore tools with which a capacity change is gated. The repository publishing scripts are not treated here and are listed in Appendix B.

Cost steering loop

Figure 17.1: The cost steering loop: allocation, forecast, envelope, gateway, metering, showback and decision, with the capacity record and the energy record fed from the same metering.

Cost management and FinOps

FinOps is the vocabulary that all four volumes use for the management of cloud and infrastructure spend. The FinOps Foundation's framework groups its capabilities in four domains: understanding usage and cost, quantifying business value, optimising usage and cost, and managing the practice itself (99, FinOps Foundation, n.d.). It is a practitioner standard and not a regulation. AI Operations uses it to separate usage decisions, which change how much is consumed and can usually be undone, from rate decisions (commitments and reserved capacity), which cannot be undone before the term ends. That separation maps onto the action classes of the operations volume: scaling and reconfiguration can be delegated at the lower levels, while a commitment is a financial decision held by a named person with budget authority and is outside the mandate of any agent.

The tools in this family are the files that turn the framework into controls: a map that attributes every identity to a cost centre, an envelope that limits a team's consumption, a cost-aware infrastructure listing and the cost-estimation step of the pipeline.

Allocation map and showback


Kind	Artefact
Origin	AI Governance, Chapter 16A
Purpose	Maps consumption to teams, applications and cost centres for showback and chargeback.
Use when	A shared AI platform is funded centrally and charged to entities or teams; before the first request.
Inputs	API keys, agent identities and reserved capacity, each registered against a use case and a cost centre.
Outputs	A map read by both the gateway and the showback report; a refusal at the gateway of any unmapped identity.
Identifier family	`finops/allocation/*.yaml`
Full template	AI Governance, Chapter 16A (excerpt `finops/allocation/ai-platform.yaml`)

The originating example is Hansa Mutual's group platform. Each identity maps to one use case, team, entity and cost centre; a fixed share for the control plane is split across seven entities by an allocation key; and an unallocated pool has an owner and a ceiling of 5 per cent of quarterly platform spend, with a breach going to the AI Governance Board. The agent that serves several markets from one service centre is charged to the market of each claim. The design point is that the gateway and the report read the same file, so that a number in the report can be traced to the identity that caused it.

Team consumption envelope


Kind	Artefact
Origin	AI Governance, Chapter 16A
Purpose	A consumption envelope for agentic work tools, per team.
Use when	For Mode 3 usage, where consumption follows the task and not the person.
Inputs	The team, its cost centre, seat count, a monthly envelope, soft and hard thresholds, per-task ceilings.
Outputs	Gateway behaviour at the hard cap (premium models disabled for the rest of the period, self-hosted models still available), per-task token ceilings and a loop rule.
Identifier family	`finops/envelopes/*` (example `finops/envelopes/mode3/platform-engineering.yaml`)
Full template	AI Governance, Chapter 16A

The example envelope is EUR 5,600 a month for 14 seats, with a soft alert at 80 per cent and a hard cap at 100 per cent, a per-task ceiling of 400,000 tokens, at most two retries per step, and a rule that an identical tool call with identical arguments three times stops the task. The originating chapter explains why the team is the right grain: a per-person spend record would also be monitoring data about employees, which in Hansa's German, Dutch and Swedish entities brings works councils and unions into a question that a team envelope answers without them.

Cost-aware Terraform infrastructure configuration (15_CODE_1)


Kind	Artefact (code listing)
Origin	Architecture as Code (Chapter 15) and Appendix A
Purpose	Terraform with cost allocation tags, budgets and Spot instances.
Use when	Declaring cost controls with the infrastructure, so that they are reviewed and versioned with it.
Inputs	Input variables declared inline so that the listing validates on its own.
Outputs	Tagged resources, budget alerts at 80 and 100 per cent, and an Auto Scaling group with a mixed instances policy.
Identifier family	`15_CODE_*`
Full template	Architecture as Code, Appendix A (`15_CODE_1`)

The originating chapter summarises the listing as four components: cost allocation tags (cost centre, project, environment, owner), budget alerts, Spot instance configuration and Auto Scaling groups balancing on-demand and Spot capacity. The listing is AWS-specific. The file is a code listing in the appendix; no corresponding file exists in the repository (see the findings).

Kubernetes cost optimisation manifests (15_CODE_2)


Kind	Artefact (code listing)
Origin	Architecture as Code (Chapter 15) and Appendix A
Purpose	Resource quotas, limit ranges, vertical and horizontal autoscaler manifests.
Use when	Limiting what a namespace can claim and scaling it within bounds.
Outputs	Hard limits per namespace; a Vertical Pod Autoscaler that controls memory requests while the Horizontal Pod Autoscaler scales replicas on CPU, so that the two never act on the same metric.
Identifier family	`15_CODE_*`
Full template	Architecture as Code, Appendix A (`15_CODE_2`)

The point the originating text makes explicit is the one AI Operations later generalises as a fight between reconcilers: two controllers that own the same field alternate. KEDA, listed in the third-party table, is named in AI Operations, Chapter 17, for the same reason (175, KEDA Authors, n.d.).

AWS cost monitoring and optimisation automation (15_CODE_3)


Kind	Artefact (code listing)
Origin	Architecture as Code (Chapter 15) and Appendix A
Purpose	A Python cost optimiser that analyses cost, generates rightsizing suggestions and identifies unused resources across EU regions.
Use when	Producing suggestions for people to review, not for unsupervised action.
Inputs	Cost Explorer, EC2, ELBv2 and CloudWatch data.
Outputs	Optimisation suggestions. The Spot estimate is an explicitly labelled heuristic and not a provider recommendation.
Identifier family	`15_CODE_*`
Full template	Architecture as Code, Appendix A (`15_CODE_3`)

Methods and third-party tools for cost

Entry	Kind	Origin	One-line purpose
FinOps and commitment-based pricing	Method	Architecture as Code (Chapter 15)	Cost governance, rightsizing, reserved instances and savings plans.
FinOps for AI and chargeback	Method	AI Platform and Security, Chapter 22	Allocates AI cost to consumers.
FinOps Framework	Third-party framework	Architecture as Code (Chapters 15, 24, 25, 26B); AI Operations, Chapters 4, 11, 15, 16, 32 and Appendix A	Cloud financial management framework (99, FinOps Foundation, n.d.). The series cites it as a vocabulary, not as a standard it conforms to.
FinOps framework and FinOps for AI	Third-party framework	AI Governance, Chapter 16A	The Foundation's practice for AI consumption and its working-group paper on FinOps for AI (19, FinOps Foundation, 2026).
Infracost	Third-party tool	Architecture as Code (Chapter 5)	Cost estimation of Terraform changes in CI, so that a cost threshold can trigger an approval gate. The project documents it as commenting on pull requests with the cost change and any policy violations (194, Infracost (n.d.), n.d.).
OpenCost / Kubecost	Third-party tool	Architecture as Code (Chapter 15)	Kubernetes cost monitoring and allocation. OpenCost is a CNCF project, the cost allocation engine originally built by Kubecost and used in all versions of its commercial product (176, OpenCost, 2022).
Pipeline stage table (validation, scanning, cost estimation, compliance tests)	Artefact	Architecture as Code (Chapter 5)	A table assigning tools to pipeline stages for infrastructure as code; belongs to Chapter 5 of this book.
FINOS project blueprint (CALM-based repository blueprint)	Artefact	Architecture as Code (Appendix C)	A proposed blueprint of pipelines, evidence export, policy modules and FinOps templates; a proposal with no template code, left to Chapter 4.

Capacity records

A capacity record says how much of something is provisioned, why that amount, and what may never be cut. Three of the artefacts are capacity plans in the narrow sense and describe accelerators; one, from the operations volume, is a record of a decision about a forecast. The two kinds should not be confused: a plan declares supply, a record explains a proposal to change it.

AI Operations, Chapter 11, adds a rule that governs every artefact in this family. A forecast is a distribution and not a value, because a single value cannot be used to decide how much margin to buy; the standard textbook on forecasting makes the same point about prediction intervals (23, Hyndman & Athanasopoulos, n.d.). A forecast is accepted when its back-test shows how often the upper quantile was exceeded, and an upper quantile nominally set at 95 per cent can be exceeded more often on the peaks that matter, because peaks are rare and the model learns mainly from ordinary days. The remedy is empirical: measure the coverage on past peaks and apply an uplift until measured coverage reaches the nominal figure, or state the shortfall.

Capacity record


Kind	Artefact
Origin	AI Operations, Chapter 11 and Appendix A.7
Purpose	Turns a forecast into a proposal: backtest, uplift for under-coverage, the guardrails capacity may not be cut below, and the approving person.
Use when	Each planning cycle, and whenever a capacity or FinOps agent proposes a change.
Inputs	Demand history with its gaps, known events, the service record's redundancy and standby floors, the provider usage export for the cost estimate.
Outputs	A decision by the service owner, a review date and the conditions on which the proposal expires.
Identifier family	`CAP-*` (example `CAP-HM-2028-014`)
Full template	Quoted below

Quoted from the text of AI Operations as compiled on 2026-11-11 (illustrative in the originating book). It is Hansa Mutual's record for the settlement payments service ahead of a quarter-end run, proposed by a capacity and FinOps agent at Level 1 Assisted.

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}

The artefact must never contain a forecast without a backtest, a reduction of the standby floor before a failover re-test, a cost estimate taken from the agent instead of the provider export, or resources under retention or protection labels. The standby floor cites the restore test RST-HM-2027-007, which links this record to the resilience register of Chapter 13: capacity may be cut only after a failover re-test inside the recovery time objective. The record's measured coverage of 0.80 against a nominal 0.95 and its uplift of 1.15 (48,000 raised to 55,200, which at a 70 per cent target utilisation requires 78,857, answered by 8 replicas) show the rule at work.

Capacity plan as code


Kind	Artefact
Origin	AI Platform and Security, Chapter 13
Purpose	Declares accelerator capacity and placement by pool.
Use when	Reviewing accelerator capacity quarterly against observed utilisation.
Inputs	Pools by location and accelerator class, workload classes, routing thresholds, observed peak utilisation.
Outputs	A reviewed file that states a decision (the example: no change, revisit if the claims assistant extends to commercial lines).
Identifier family	`platform/capacity/*.yaml` (kind `CapacityPlan`)
Full template	AI Platform and Security, Chapter 13 (`platform/capacity/prod.yaml`)

The example reserves eight accelerators in the Frankfurt data centre for interactive and fallback inference and four reserved plus up to twelve burstable at an EU cloud provider for batch, evaluation and fine-tuning. It caps agent traffic at 150 concurrent tasks without burst, and shifts routing to a smaller model when utilisation exceeds 0.80. The fallback-inference class reserves enough capacity to carry the claims assistant on an open-weight model if the external provider is lost, which the originating chapter calls the technical half of the DORA exit strategy. Article 28(8) of Regulation (EU) 2022/2554 requires financial entities to put in place exit strategies for ICT services supporting critical or important functions (197, European Union, 2022).

GPU capacity plan


Kind	Artefact
Origin	AI Platform and Security, Chapter 22
Purpose	A capacity plan for accelerators: demand, reserved and on-demand supply with trigger, utilisation targets and a renewal decision date.
Use when	Each quarter, derived from the previous quarter's gateway telemetry.
Inputs	Peak tokens per second, latency objective, daily batch tokens and window, reserved and on-demand prices.
Outputs	A plan that reserves for the baseline and bursts only when latency is at risk, with a utilisation-floor alert (0.45) that turns accelerator hoarding into a visible finding, and a renewal decision two months before the commitment ends.
Identifier family	`capacity/*.yaml` (kind `GpuCapacityPlan`; example `capacity/benefits-platform-2027q1.yaml`)
Full template	AI Platform and Security, Chapter 22

The example is Nordvik Region's: 16 reserved accelerators at EUR 1.85 an hour with a 12-month commitment, up to 8 on-demand accelerators at EUR 3.40 triggered by an interactive queue time above 400 ms for 5 minutes, and a fallback route to a hosted model if the reservation is not renewed. The two plans in this family use different schemas and different apiVersion domains (see the findings); the plan of Chapter 13 of that volume is a pool declaration, the plan of its Chapter 22 a demand-and-supply plan, and an organisation that adopts both should say which governs.

Cost-aware model routing policy


Kind	Artefact
Origin	AI Platform and Security, Chapter 22 and Appendix A (`22_CODE_ROUTING`)
Purpose	Routes requests across model tiers by task, data classification and budget at the AI gateway.
Use when	For each business area served by the gateway.
Inputs	Model tiers with cost, hosting, permitted data classifications and energy per million tokens; ordered rules; budgets.
Outputs	Routing decisions made by the first matching rule; a cascade that escalates to a larger model only when the small model's confidence is low and a groundedness check passes; a fallback and a budget behaviour at the soft limit.
Identifier family	`policies/routing/*.yaml` (kind `RoutingPolicy`)
Full template	AI Platform and Security, Appendix A

The Appendix A policy evaluates data classification first, so that a confidential or personal request never leaves EU-hosted capacity whatever it costs; then task type; then context length. Its energy field is null for a vendor service that does not disclose it, which is the honest value. Chapter 22 of the same volume shows a different, shorter schema (ModelRoutingPolicy) for the same job. The cascade idea is the subject of the FrugalGPT paper, which AI Operations cites for lowering cost with cascades of models (20, Chen et al., 2023); the series cites it in passing and does not claim its savings for its own examples.

Model-routing and carbon policy


Kind	Artefact
Origin	AI Threat, Chapter 17
Purpose	A routing policy that defaults to the smallest adequate model, with footprint reporting.
Use when	A shared platform reports the energy of a service by entity and route.
Inputs	Adequacy evidence for each route, a monthly energy budget, a schedule rule for flexible work.
Outputs	A monthly report of energy, location-based emissions and a water estimate split by entity and route, with a review trigger when the share of queries on the default model falls below 0.7.
Identifier family	`RP-*` (example `RP-HM-CLAIMS-2026-02`)
Full template	AI Threat, Chapter 17

Each route carries the evaluation that shows the small model is adequate (adequacy_evidence), and flexible work such as nightly evaluation runs is scheduled in the window of lowest forecast grid carbon intensity. The reporting method is stated: measured power on self-hosted nodes and a token-based estimate for the hosted route. The RP-* prefix is not used elsewhere in this book's inventory for a different artefact; the AI Operations volume's RBK-* is the runbook family.

Token and GPU economics

The unit of cost of an AI request differs from the unit of cost of a virtual machine, and the tools above only work if the arithmetic is right. AI Operations, Chapter 15, states the arithmetic that the budget and the forecast depend on. For a hosted model billed by the token, the cost of a call is the sum of input tokens at the input price, output tokens at the output price and any cached or batch variants; the billed input includes the system prompt, the conversation history and retrieved content, so cost cannot be estimated from the user's message. For an agent the unit is the run, not the call: if every step adds about k tokens to a context that is resent at each step, input tokens over n steps are roughly k times n(n+1)/2, so a run twice as long costs close to four times as much in input tokens unless caching absorbs the repeated prefix. That is the book's own arithmetic and not a measurement, and it is why the budget of an agent is expressed per run as well as per day: a daily cap alone lets one looping run consume the day.

For capacity the organisation reserves or owns, the unit cost is a quotient whose denominator moves. A pool that is paid for and half used costs twice as much per request as one kept busy, and a reservation priced at 60 per cent of on-demand pays for itself only above 60 per cent utilisation. The FinOps working-group paper recommends measuring the use case and not the token alone, and reporting distributions because AI cost varies from run to run (19, FinOps Foundation, 2026).

Cost-and-latency budget


Kind	Artefact
Origin	AI Operations, Chapter 15 and Appendix A.11
Purpose	Holds capacity, unit cost, objectives, fallback ladder and stop for an AI service, with per-run, daily and monthly cost limits where the service is an agent.
Use when	For every AI service that has a cost and a latency objective; reviewed on any model, image, price or provider change.
Inputs	Load-test results, the allocated cost of capacity, the service level objective, the golden set that sets the quality floor.
Outputs	A ladder of fallbacks, a stop with a named holder outside the agent, and an energy claim only where it is metered.
Identifier family	`CAP-*` (examples `CAP-NR-AI-001`, `CAP-HM-AI-001`)
Full template	Quoted below

Quoted from the text of AI Operations as compiled on 2026-11-11 (illustrative in the originating book). It is Nordvik Region's budget for the citizen-service assistant. The Hansa Mutual record CAP-HM-AI-001 of the same appendix adds per-run limits of 12 steps and EUR 0.36, a daily cap of EUR 1,900 with a warning at 80 per cent, a monthly cap of EUR 38,000, a rule that a breach degrades and never halts a critical service without the manual rung staffed, and a metered energy claim of 1.8 Wh per triaged claim; it is left to the originating appendix.

record: CAP-NR-AI-001
service: SVC-NR-005          # citizen-service assistant, Mode 4
decision: AIDR-0915          # 2028-11-14; reviewer: CISO, data protection officer
owner: Maja Lindqvist        # platform lead; service owner: Sara Ekdahl
effective: 2028-11-14
review_by: 2029-02-14        # or on any model, image, price or provider change
capacity:
  form: reserved accelerators, Nordic hosting provider
  allocated_cost_eur_month: 53300      # illustrative share of EUR 1.6 million a year
  load_test: {date: 2028-10-19, config: pool-v3, saturation_rps: 11}
  planned_utilisation_max: 0.65        # interactive pool; headroom kept
volume_illustrative: {conversations_month: 60000, peak_driver: benefit decision dates}
unit_cost:
  eur_per_conversation: 0.89           # allocated cost / conversations
  p95_tokens_per_conversation: 5200    # measured 2028-10, new
objectives:
  latency_p95_s: 8                     # SLO-NR-005
  quality_floor: {golden_set: GS-NR-005-v4, pass_rate_min: 0.90, last: 0.93, date: 2028-11-07}
fallback_ladder:
  - {rung: 1, model: primary,   slo_p95_s: 8,  pass_rate: 0.93}
  - {rung: 2, model: smaller open-weight model, same pool, slo_p95_s: 6, pass_rate: 0.88, tier: public}
  - {rung: 3, path: published FAQ search, no generation, pass_rate: n/a}
  - {rung: 4, path: hand-off to the service desk, hours: 07:00-17:00 working days}
trigger: {probe: external synthetic probe OBS-NR-0001, failure_domain: outside the Region Cloud}
stop:
  holder: [duty manager, platform lead]
  action: open gateway circuit; rung 3
  last_drill: {date: 2028-10-26, result: rung 2 in 41 s, rung 3 in 4 min, hand-off staffed in 12 min}
energy:
  claim_available: false
  reason: provider supplies metered kWh per reserved accelerator from 2029-01 (requested, contract NR-2026-031 annex)
  boundary_when_available: accelerators + host + facility share, idle included, per completed conversation

The artefact must never contain an energy claim without a metered boundary, a critical service that halts on a budget breach without the manual rung staffed, or a stop inside the agent. The energy block shows what an unavailable claim looks like: claim_available: false, the reason, the date the provider is expected to supply a figure, and the boundary that will apply then. The unit cost of EUR 0.89 is the allocated monthly cost divided by conversations (53,300 over 60,000), and the 95th-percentile token count is a measurement the record flags as new.

Capacity forecasting with backtest and cost per outcome

Entry	Kind	Origin	One-line purpose
Capacity forecasting with backtest	Method	AI Operations, Chapter 11	A forecast as a distribution, backtested, with an uplift where measured coverage falls below nominal.
Cost per outcome as a distribution	Method	AI Operations, Chapter 15	Report unit cost per outcome as a distribution and not a mean, with the 50th, 95th and 99th percentiles per run and the cost per successful outcome against the quality bar that defines success.

Serving software, autoscaling and sizing evidence

Three third-party entries in this family concern the software that sets how much a pool can do or how it scales. They are described here only to the extent that the originating volume relies on them.

Entry	Kind	Origin	Use in the series and limit
vLLM	Open-source serving system	AI Operations, Chapter 15	Cited for serving cost and capacity: its authors report that managing the memory that holds each request's context raised throughput of popular language models by two to four times at the same latency against the systems they compared with (21, Kwon et al., 2023). That is a comparison on the authors' workloads; the series' inference is that a change of serving stack or batching configuration is a capacity event, load-tested and recorded, and a capacity figure carries the configuration it was measured on.
KEDA	Open-source autoscaler	AI Operations, Chapter 17	An event-driven autoscaler whose admission webhooks validate the setup and prevent two ScaledObjects from targeting one workload (175, KEDA Authors, n.d.); cited as an example of a guard against reconcilers that fight over a field.
FrugalGPT	Research approach	AI Operations, Chapter 15	A paper on using language models while lowering cost through cascades (20, Chen et al., 2023); cited in passing.

The one piece of public evidence that AI Operations gives for automated sizing is Google's Autopilot, whose authors report about 23 per cent slack for autopiloted jobs against about 46 per cent for manually managed jobs, and a tenfold fall in jobs severely affected by out-of-memory events (22, Rzadca et al., 2020). The originating chapter's reading is that the conditions are narrow (Google's own workloads and platform, a comparison of managed with unmanaged jobs, an objective of waste at a given failure rate and not of preserving a recovery capability), so a European authority or insurer cannot read the figures as a forecast of its own savings. Slack is the margin that absorbs error, and removing it is the saving.

Energy and carbon

Energy accounting in the volumes rests on one specification and one rule. The specification is the Software Carbon Intensity (SCI) of the Green Software Foundation, adopted as ISO/IEC 21031:2024 (100, Green Software Foundation, 2024). Its form, as the volumes quote it, is SCI = ((E × I) + M) per R, where E is the energy used, I the carbon intensity of that energy by location and time, M the embodied emissions of the allocated hardware and R a functional unit. AI Platform and Security observes that the score rewards reduction rather than offsetting, so purchased offsets do not lower it, and that the functional unit should be the same one used for cost, such as a resolved enquiry or a processed claim. The rule, from AI Operations, is that an energy claim is a measurement with a boundary, a period and a count, and that a published figure for a provider's service is not used as the energy of the operator's own use.

Software Carbon Intensity calculation


Kind	Method
Origin	AI Platform and Security, Chapter 22
Purpose	Computes the carbon emissions of a software system per functional unit: energy times carbon intensity, plus allocated embodied emissions, per unit.
Use when	For each use case, monthly, in a record that states boundary, method and limitations.
Inputs	Metered or estimated energy, the power usage effectiveness of the facility, hourly grid carbon intensity, allocated embodied emissions, the count of functional units.
Outputs	An SCI value, a target, a sensitivity line and known limitations.
Identifier family	`sustainability/sci/*.yaml`
Full template	Quoted below

Quoted from the text of AI Platform and Security as compiled on 2026-11-11 (illustrative in the originating book). It is Nordvik Region's calculation for its citizen FAQ service on reserved accelerators for October 2026.

sci_calculation:
  specification: ISO/IEC 21031:2024
  use_case: citizen-faq
  period: 2026-10
  functional_unit: resolved enquiry
  boundary:
    included: [gpu servers, host cpu and memory, cooling share, gateway nodes]
    excluded: [citizen end-user devices, network transit outside data centre]
  energy:
    gpu_and_host_kwh: 1970
    pue: 1.15
    total_kwh_E: 2266
  carbon_intensity:
    source: grid-operator-hourly, location-based, weighted by hourly load
    grams_co2e_per_kwh_I: 32
  operational_emissions_g: 72512
  embodied_emissions_M_g: 62400
  functional_units_R: 71000
  result:
    sci_g_co2e_per_unit: 1.90
    target: 2.0
  sensitivity:
    same_workload_at_350_g_per_kwh: 12.05
  known_limitations:
    - Hosted large-provider-model route excluded; provider publishes no per-request energy
  reviewed_by: sustainability-lead

The record is worth reading for what it refuses to claim. The hosted route is excluded and the limitation is stated. The sensitivity line applies the same workload to a gas-dominated grid and shows the score rising more than sixfold (from 1.90 to 12.05 grams per enquiry), which is the location argument expressed as a number. The arithmetic can be checked: 2,266 kWh at 32 grams is 72,512 grams; adding 62,400 grams of embodied emissions and dividing by 71,000 enquiries gives 1.90. The record notes that hosted providers rarely disclose per-request energy, so a deployer estimates from model characteristics and token counts and states the method. The AI Act asks providers of general-purpose AI models to document the known or estimated energy consumption of the model in the technical documentation under Annex XI (195, European Union, 2024), which should give deployers a better basis over time and a reason to ask for the figure in procurement. That is an architectural implication and not legal advice.

Carbon-aware scheduling


Kind	Artefact (code listing)
Origin	Architecture as Code (Chapter 25)
Purpose	A Python example that schedules work by carbon intensity, mapping EU cloud regions to national grid zones and falling back to indicative values when live data are unavailable.
Use when	Placing or timing flexible workload where a carbon-intensity signal is available.
Inputs	A grid carbon-intensity service.
Outputs	A selection of region or time.
Identifier family	`carbon_aware_scheduling.py` (a path comment in the listing)
Full template	Architecture as Code (Chapter 25); the listing is in the chapter text, and no such file exists in the repository

The listing uses the Electricity Maps API as its signal source and refers to the Green Software Foundation's Carbon Aware SDK as the same kind of signal that schedulers can use (177, Green Software Foundation, n.d.). The later volumes use the idea with a stricter condition: flexible work moves to a window of low carbon intensity only where it does not cross a deadline, and AI Operations adds that the batch run on which a settlement deadline depends cannot move to a cheaper hour that crosses the deadline.

The Software Carbon Intensity specification and the Carbon Aware SDK

The SCI specification appears as four separate inventory entries (Architecture as Code by name with the Carbon Aware SDK, AI Governance in Appendix B, AI Platform and Security Chapter 22 and AI Operations Chapter 15). They are one standard. The chapter treats them together: the specification is the form of the calculation, the SDK a software source of a grid signal, and neither supplies a measured figure for the operator's own service. AI Operations adds a statement of scope for the regulatory context. Directive (EU) 2023/1791 requires, in Article 12, that Member States require owners and operators of data centres with an installed information technology power demand of at least 500 kW to make the Annex VII information publicly available, from 15 May 2024 and annually, and Commission Delegated Regulation (EU) 2024/1364 sets the first phase of the rating scheme at the same threshold (214, European Union, 2023) (215, European Commission, 2024). Three consequences follow in the originating chapter: the duty falls on the owner or operator of the data centre, so an organisation renting capacity obtains the figures from its provider and the contract should say so; the figures are annual and site-level, and attribution to a service is the organisation's own work; and the metering must exist.

Worked example: a consumption forecast with a budget alert

AI Governance, Chapter 16A, supplies a forecast file for an autonomous agent and the rules for the alerts that govern it. The example is Hansa Mutual's claims-triage agent, a Mode 5 autonomous production agent working through the Polish service centre for four markets. The forecast is quoted from the text of AI Governance as compiled on 2026-11-11 (illustrative in the originating book).

use_case: UC-2026-014                   # claims-triage agent, AIDR-0024
period: 2027-01-04/2027-04-04           # 91 days
markets: [DE, NL, SE, NO]               # through the Polish service centre
assumptions:
  claims_per_day: 1500
  actions_per_claim: 2.6
  tokens_per_action: {p50: 125000, p90: 285000, mean: 145000}
  retry_rate: 0.08
  model_mix: {compact-tier: 0.70, large-tier: 0.30}
  blended_eur_per_million_tokens: 1.339
  price_basis: "supplier price lists of 2026-10-01, no change assumed"
cases_eur: {low: 61900, expected: 74500, high: 89200}
previous_forecast_error: {period: 2026-Q3, error: "+13 %"}   # retries on scanned documents
consumption_envelope:
  weekly_eur: 6500
  quarterly_eur: 84500
  daily_hard_cap_eur: 1300              # gateway; fallback: handler triage queue
cost_per_completed_action_eur: {p50: 0.18, p90: 0.41, p90_ceiling: 0.60}
review: {forecast_revision: monthly, envelope_review: AI Governance Board, quarterly}

Every figure traces to an assumption, as the originating practical guide requires. The expected case can be recomputed from the recorded assumptions: 1,500 claims a day at 2.6 actions is 3,900 actions a day, or 354,900 over 91 days; at a mean of 145,000 tokens, with the 8 per cent retry rate, and the blended price of EUR 1.339 per million tokens, the cost is about EUR 74,400, which the record rounds to 74,500. The mean is used and not the median, because the tail is billed too. The envelope follows the guide's rule for an operating system, the expected case plus the previous forecast error, which here was +13 per cent because of retries on scanned documents.

The alert thresholds come from the same chapter's practical guide on setting an envelope: a soft alert at 80 per cent of the envelope consumed before 80 per cent of the period has elapsed, and a hard stop at 100 per cent with a defined fallback, paired with a unit-cost ceiling at the 90th percentile and a quality floor, because a unit cost that falls because quality was lowered is a breach and not a saving. The chapter's own reading of the weekly envelope is that the soft alert falls at EUR 5,200. The stop authority is named: the on-call role can execute the hard stop alone and the budget owner is informed within an hour. Raising the envelope or switching model needs the budget owner; changing the mandate or restarting a high-risk system after a hard stop waits for the governance forum.

The originating chapter shows what the daily hard cap of EUR 1,300 did on the one morning in its stop record. A release of the core claims system API added a mandatory field, the agent's route actions began failing and the agent retried each one. The record shows 6,184 actions attempted against 194 completed, EUR 965 spent in the window, the soft alert at 09:52 and the hard cap reached at 10:14, when the gateway paused the agent and invoked the fallback before the budget owner had replied. 418 claims were delayed and none passed its handling deadline. Two corrective actions were recorded: a retry budget of two per action, then routing to the handler queue, and a circuit breaker after 20 validation errors in 60 seconds. The stop record is not a separate inventory entry and is left to the originating chapter. The example shows the difference between a budget enforced by the gateway and one noticed on an invoice.

Across the degrees of delegation

The cost and capacity tools bound what an agent may do with money and capacity. The table gathers the ceilings that AI Operations, Chapter 11, recommends as the starting point; they are the book's recommendations and not a requirement of any instrument. Level 4 Autonomous is not used for 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 practice an agent never reduces the observer's capacity to save cost.

Action	Ceiling at the start	Condition
Forecast demand and cost (read, annotate)	Level 3 Bounded	Interval and back-test shown; the model cannot change its own inputs
Notify of an expiry or a breach of forecast	Level 3 Bounded	The alert is tested by a seeded case; the path does not depend on the agent
Scale out within bounds	Level 3 Bounded	Catalogued runbook; floors enforced outside the agent; reversible
Rightsize or schedule	Level 1 Assisted, then Level 2 Supervised for non-production	Floors, windows and veto; two clean quarters before the next step
Delete an unused resource	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	Not delegated	A finance decision with the forecast interval and exit cost
Stop a spending agent at its budget	Gateway rule, with a named human stop holder	The stop is outside the agent

For usage modes, the cost record differs most between Mode 3 and Mode 5. At Mode 3 the envelope is per team and per task; at Mode 5 the budget is per run, per day and per month, with the unit of cost being the run. The allocation map and the SCI record do not differ by mode.

Nordvik Region and Hansa Mutual

Nordvik Region's cost problem is irreversibility and lead time. It runs its own cloud in two halls and reserved accelerators (about EUR 1.6 million a year of the unit's budget of about EUR 38 million, according to the profile), and a wrong forecast is paid for in months, with procurement lead times of 9 to 14 months for its own Region Cloud. Its tools are the GPU capacity plan with a renewal decision date, the cost-and-latency budget CAP-NR-AI-001 with a rung-by-rung fallback, and an SCI record that excludes the hosted route and an energy claim that the budget declares unavailable until the provider supplies metered kWh. It runs no autonomous production agent; its operations assistant works at Level 0 Advisory and may draft the capacity record, which the platform lead reviews.

Hansa Mutual consumes capacity from its Frankfurt data centre and two hyperscaler tenancies and already has an agent in the loop. Its tools are the allocation map across seven entities, the Mode 3 envelope for platform engineering, the forecast and daily hard cap for the claims-triage agent, the per-run budget CAP-HM-AI-001 with a metered energy claim, and the capacity record CAP-HM-2028-014, in which a floor tied to a dated failover test stops the capacity agent proposing too much. Its routing policy defaults to the small self-hosted model with adequacy evidence and a monthly report split by entity. Nordvik's risk is that a wrong forecast cannot be undone; Hansa's is that a right-sized estate could lose the margin on which a failover relies.

Summary

The tools of this chapter share a design. A decision about cost, capacity or energy is taken before money or capacity is committed, it is written in a file with a named owner and a date, and the system that enforces it reads the same file that the report does. An allocation map and an envelope attribute and limit consumption; a forecast with stated assumptions and a back-test sizes it; a capacity record states what may not be cut; a budget gives an agent a per-run, daily and monthly limit and a stop that sits outside it; and an SCI record states a boundary and refuses to claim what has not been metered.

The chapter's own conclusions are three. First, the unit of cost of an agent is the run, so a daily cap alone is not a control. Second, a forecast that does not show its back-test and its uplift cannot be challenged, so a capacity record without them is a hope. Third, an energy figure without a boundary cannot be compared, so the right entry when no metered figure exists is that the claim is not yet available, with the party and the date. All 31 entries of the slice are accounted for, in full entries or in family tables; the four entries for the SCI specification and the three for the FinOps Framework are one standard each and are treated together, and two (the pipeline stage table and the FINOS blueprint) belong to Chapters 5 and 4 and are recorded in the findings for reassignment. Appendix A lists every entry. The findings record the schemas that overlap and the code listings that have no file in the repository.

Sources

Nordqvist, G. Architecture as Code. (1, Nordqvist, 2025)
Nordqvist, G. AI Governance: Governing Artificial Intelligence in European Enterprises and Public Authorities. (2, Nordqvist, 2026)
Nordqvist, G. AI Platform and Security: Building and Securing AI Platforms in European Enterprises and Public Authorities. (3, Nordqvist, 2026)
Nordqvist, G. AI Operations: How Artificial Intelligence Transforms IT Operations in European Enterprises and Public Authorities. (10, Nordqvist, 2026)
FinOps Foundation. FinOps for AI Overview. (19, FinOps Foundation, 2026)
Chen, L., Zaharia, M., Zou, J. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. (20, Chen et al., 2023)
Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H., Stoica, I. Efficient Memory Management for Large Language Model Serving with PagedAttention. (21, Kwon et al., 2023)
Rzadca, K., Findeisen, P., Swiderski, J., Zych, P., Broniek, P., Kusmierek, J., Nowak, P. K., Strack, B., Witusowski, P., Hand, S., Wilkes, J. Autopilot: Workload Autoscaling at Google Scale. (22, Rzadca et al., 2020)
Hyndman, R. J., Athanasopoulos, G. Forecasting: Principles and Practice. (23, Hyndman & Athanasopoulos, n.d.)
FinOps Foundation. FinOps Framework. (99, FinOps Foundation, n.d.)
Green Software Foundation. Software Carbon Intensity (SCI) specification,. (100, Green Software Foundation, 2024)
KEDA Authors. KEDA Concepts. (175, KEDA Authors, n.d.)
OpenCost. OpenCost Documentation: Overview. (176, OpenCost, 2022)
Green Software Foundation. Carbon Aware SDK. (177, Green Software Foundation, n.d.)
Infracost. Get started. (194, Infracost (n.d.), n.d.)
European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). (195, European Union, 2024)
European Parliament and Council of the European Union. Directive (EU) 2023/1791 of 13 September 2023 on energy efficiency and amending Regulation (EU) 2023/955 (recast). (214, European Union, 2023)
European Commission. Commission Delegated Regulation (EU) 2024/1364 of 14 March 2024 on the first phase of the establishment of a common Union rating scheme for data centres. (215, European Commission, 2024)