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.
Primary topics explored
- Cost management and FinOps
- Capacity records
- Token and GPU economics
- Energy and carbon
- Worked example: a consumption forecast with a budget alert
- Across the degrees of delegation
About Tools
Tools is a companion to The Transformed Architecture. It collects the tools that Books 1 to 10 describe in one reference, organised by what the practitioner is doing: artefacts (templates, manifests, records), own tools, third-party tools and standards, and methods. Each entry says what a tool is for, when to use it, what it needs and produces, and where the book that defines it explains the reasoning. The book covers choosing, adopting and retiring tools, architecture and delivery, governing AI, securing and testing, operating, agents and autonomy, and people, organisation and society, for European enterprises and public authorities. It comes with a template library, an inventory, three web tools and the Toolbox Maturity Method.
It builds on the conclusions of Architecture as Code, AI Governance, AI Platform and Security, AI Red Team, AI Threat, The Transformed Security Architect, AI Boss, AI Blue, AI Purple and AI Operations.
Architects and security architects, CIOs and CISOs, platform and operations leads, heads of governance, risk, compliance and third-party risk, AI governance and AI platform teams, red, blue and purple team leads, boards and management bodies, procurement and vendor managers, supervisors and auditors, works councils and unions, data protection officers, and public-sector leaders.
Continue with the full chapter
Chapter 17: Capacity, Cost and Energy Tools in Tools gives the detailed explanations, practical examples and implementation patterns behind this summary.
This whitepaper belongs to “Operating” and is one of 29 drawn from the manuscript.