--- title: Day 21 — The Footprint Already Spent type: newsletter date: 2026-07-22 source: linkedin summary: "Day 20 closed the arc on the system around the model with a single frame: once capacity is standing, the bill runs on wall-clock, and utilization becomes the number that matters. That frame covered operational emissions — the electricity, cooling, and compute…" newsletter: Green AI Bytes draft: false --- Day 20 closed the arc on the system around the model with a single frame: once capacity is standing, the bill runs on wall-clock, and utilization becomes the number that matters. That frame covered operational emissions — the electricity, cooling, and compute drawn while the system runs. There is a second footprint alongside the operational one, and most AI reporting misses it entirely. It was paid before the first request arrived. Every GPU in the rack was manufactured. Every server was assembled, shipped, and installed. Every model was trained on hardware whose manufacture already carried an embodied footprint. Every data center was built — poured concrete foundations, steel frames, chillers, electrical systems, and cooling infrastructure. These emissions do not scale with usage. They were paid in full before the system served its first token, and they sit on the ledger whether the system serves ten queries a day or ten million. Operational emissions scale with use. Embodied emissions are largely fixed the day the asset enters service. Utilization determines how thinly that fixed footprint is spread — which is where the discipline built in Day 20 meets the ledger opened today. The next five issues take embodied carbon apart. A financial services company completes its first AI carbon report. The methodology, refined over a year of work with the sustainability team, is rigorous on the operational side. Every inference call is metered. Every kilowatt-hour is tracked. Grid intensity is factored in by region. The final number, published in the annual disclosure, is presented as the company's AI footprint. An external reviewer flags a gap. The number captures what the AI system draws while running. It does not capture what was spent to build it. The audit that follows reconstructs three categories of missing emissions. **The hardware that runs the model.** The GPUs and servers in the company's inference fleet had a manufacturing footprint on the order of the electricity they draw over a full year of operation. That footprint is a one-time cost, but it is not zero, and it belongs to whichever workloads use the hardware over its lifetime. The company had counted the electricity. It had not counted the silicon. **The training that shaped the model.** The company runs a mix of open-weights and proprietary models. The proprietary ones were fine-tuned in house. The training runs occupied weeks of dedicated infrastructure and extensive evaluation. None of it appeared in the inference report, because none of it was inference. It appeared nowhere else either. **The facility that holds it.** The colocation contracts covered electricity and cooling. They did not cover the concrete foundations, steel frames, and cooling infrastructure of the building itself — emissions embedded in the physical facility, amortized across every tenant over the building's operating life. The share attributable to the company's racks was small on a percentage basis and non-trivial in absolute terms. It had never been on the ledger. > Operational emissions are what the system draws. Embodied emissions are what the system cost to exist. Both are on the bill. Only one has been counted. The obvious objection is that embodied carbon is a supply-chain problem, and supply-chain emissions belong to the manufacturer, not the operator. That is not how modern emissions accounting works. Frameworks such as the Greenhouse Gas Protocol treat embodied emissions from purchased hardware as Scope 3 — the buyer's responsibility to disclose, even when the manufacturer disclosed them too. Ignoring embodied carbon does not make it disappear from the atmosphere. It only makes it disappear from the report. Four rungs move embodied carbon from an unnamed category into a measured one. **Name.** The first move is to draw the line — to state, in writing, that the AI footprint has two components, and to name both of them. Operational is the compute drawn while the system runs. Embodied is the compute spent to build, train, and house the system before it runs. Naming the split is the change that lets every subsequent measurement land in the right column. Without the split, embodied emissions arrive as noise in the operational number, or vanish entirely. *You cannot manage what your accounting boundary excludes.* **Attribute.** Embodied emissions belong somewhere. Hardware embodied carbon belongs to the workloads that run on the hardware, apportioned by utilization over the hardware's lifetime. Training embodied carbon belongs to every inference the trained model serves, amortized across queries. Facility embodied carbon belongs to the tenants of the facility, apportioned by rack, by power draw, or by contract share. Attribution begins with consistency, not perfection. **Amortize.** A one-time cost divided across a lifetime of usage becomes a per-query number. That per-query number is small when the asset is well-used and large when it is not. A GPU that serves ten million requests a year carries a fraction of the embodied footprint per request that the same GPU carries when it serves ten thousand. A trained model that grows into a widely-used feature amortizes its training footprint across billions of queries; a trained model that ships and is quickly deprecated carries the full training footprint against a small denominator. Amortization is the arithmetic that connects embodied emissions to the utilization discipline built in Day 20. **Report.** Embodied emissions belong in the AI carbon report as a first-class number, presented alongside operational emissions, with the methodology and assumptions stated openly. The first time a team reports embodied emissions, the total footprint number goes up. That is the point. A larger, honest number is more useful than a smaller, incomplete one, because the honest number is the one that leads to the right decisions about hardware refresh cycles, model reuse, and facility choice. Embodied carbon crosses every seat at the table, but it has historically been claimed by none of them. **Engineering.** Hardware choice, model choice, and training decisions all carry embodied consequences. The engineering seat gains a new question at design review: what is the embodied footprint of the assets this system requires, and how will it be amortized? **Architecture and CTO.** The architecture diagram gains an emissions dimension it did not have before. The choice between a self-hosted trained model and a shared foundation model is now also a choice about who carries the training footprint and how thinly it is spread. **Platform and Infrastructure.** Procurement joins the emissions conversation. Hardware refresh cycles, colocation contracts, and cloud instance choices all have embodied components that platform teams can influence but historically have not been asked to disclose. **Sustainability and ESG.** The reporting boundary widens. Emissions disclosures that covered operational energy alone now extend to the manufactured hardware, the trained models, and the built facilities behind the system. The number is bigger. The disclosure is more defensible. **Business and Product.** Total cost of ownership and total footprint of ownership converge. The same discipline that improves margins — high utilization on well-chosen infrastructure, models that earn their place in the product — improves the embodied per-query number. **Five seats, one footprint.** The work begins with a boundary and ends with a number. Start by drawing the accounting boundary. On one page, record what today's AI footprint includes, what it excludes, and where operational emissions end and embodied emissions begin. Most organisations discover that the line has never been written down, and that the boundary is narrower than anyone would have guessed. The page itself is the first artifact of an embodied-carbon programme. Pick one of the three embodied categories — hardware, training, or facility — and add it to the boundary. Choose a methodology, choose an attribution rule, and produce a first estimate. The estimate will be imperfect. It will still be more useful than the zero it replaces. Publish the widened number alongside the operational number in the next report. **One boundary, one category, one number. That is the work.** > *Operational is what the system draws. Embodied is what the system cost to exist.* Day 22 takes the first of the three embodied categories and opens it up: the silicon in the rack. The manufacturing footprint of GPUs, accelerators, and servers — where it comes from, how it is measured, and why the hardware refresh cycle is one of the largest embodied decisions an AI team makes. * ISO/IEC 21031:2024 — Software Carbon Intensity (SCI) specification, with M-term for embodied emissions. * Greenhouse Gas Protocol. *Corporate Value Chain (Scope 3) Accounting and Reporting Standard.* [ghgprotocol.org](http://ghgprotocol.org) * Green Software Foundation. *Software Carbon Intensity — measurement guidance.* [greensoftware.foundation](http://greensoftware.foundation) * Boavizta. *BoaviztAPI — lifecycle assessment methodology and tooling for IT equipment.* [boavizta.org](http://boavizta.org) and [github.com/Boavizta/boaviztapi](http://github.com/Boavizta/boaviztapi) * Gupta, U. et al. (2021). *Chasing Carbon: The Elusive Environmental Footprint of Computing.* [arXiv:2011.02839](https://arxiv.org/abs/2011.02839) ---