Open Standards for Measuring Carbon, Energy, and Water in Software and AI

It was great to present at Open Source Summit Europe + Embedded Linux Conference Europe in Prague with Sean Mcilroy on “Open Standards for Measuring Carbon, Energy, and Water in Software and AI.”

Presenting the GSF measurement standards at Open Source Summit Europe, Prague.

We shared the work we are advancing at the Green Software Foundation to make the environmental impact of software and AI more measurable, consistent, and actionable.

Three questions worth sitting with

We began with three questions that are easy to ask and surprisingly hard to answer. What is the carbon footprint of one transaction in your busiest service? What is the energy cost of one inference call? How many litres of water did your last fine-tuning run consume?

For most teams, the cost version of each of these is readily available. The environmental version usually is not.

That gap is not simply a missing dashboard. There is often no agreed unit of work, and a total on its own tells an engineer little. The parties are different: whoever trains a model is rarely whoever runs it. The coefficients move, because grid carbon intensity varies by the hour and by the region. And embodied hardware emissions, while real and material, are rarely available in mainstream observability tooling.

What exists today

Four specifications, each addressing a distinct part of the problem:

• SCI — Software Carbon Intensity, now ISO/IEC 21031:2024. Expresses carbon as a rate per unit of useful work: SCI = ((E × I) + M) per R. Offsets and market-based instruments do not reduce an SCI score — it improves through energy efficiency, hardware efficiency, or carbon-aware choices about when and where software runs.
• SCI for AI, ratified by GSF in December 2025. Two persona-based boundaries — a provider score for model development and training, a consumer score for inference and monitoring — so each party reports what it can actually reduce. Training is not amortised into a per-inference figure, and the specification asks you to declare what was measured, what was estimated and what was assumed — which is what makes it auditable.
• SEI — Software Energy Intensity, pre-draft. Isolates energy from grid carbon intensity, so the score stops moving when the grid does. Report carbon upward; optimise energy inward.
• SWI — Software Water Intensity, pre-draft. Direct operational, indirect operational and embodied water, each on a consumption and a withdrawal basis — because consumption and withdrawal are distinct pressures, and a litre in a stressed basin is not just a litre.

These measures compose into one picture only where they share the same boundary, the same functional unit, the same time window, and the same water basis.

The obligations now in force

Sustainability in software and AI is moving beyond voluntary reporting. The EU AI Act’s GPAI obligations apply, with Annex XI requiring known or estimated model energy consumption in technical documentation. CSRD reporting scope and the revised ESRS continue to evolve. And in May 2026 the French G7 Presidency published an international overview of voluntary initiatives for measuring and reporting the energy and resource requirements of AI models, including SCI for AI.

Consistent, credible measurement is becoming increasingly important for meeting these emerging expectations.

From specification to number

A specification becomes useful when someone can run it. Impact Framework turns a declarative manifest — stating the workload, the boundary and the functional unit — into a reproducible number through a plugin pipeline. CARMEN, the Carbon Measurement Engine built on Impact Framework, measures cloud software at infrastructure and application level, integrating with Kubernetes, Prometheus and related telemetry.

The output is reproducible: the same manifest produces the same numbers, and can be re-run by someone who was not in the room.

What remains challenging

We also spent time on the open challenges. Embodied hardware data depends on vendor disclosure that is uneven and rarely current. Granular inference telemetry is still unavailable from many model and API providers, so practitioners combine measurement with estimation. Workload-level water data remains limited while SWI is still defining attribution and regional stress. And functional-unit comparability across organisations remains difficult, because the same service can often be measured in more than one defensible way.

Skills and capability building

We also shared the launch of the Green Software & AI Academy, whose pilot opened on 1 October 2026 with 14 courses across five role tracks — from leaders, architects and developers to data and ML practitioners and platform teams. Every course stands alone, covers environmental and financial impact together, and ends in a scenario-based assessment and a GSF credential.

Where you come in

Two of the four specifications are still being written, and standards are easiest to shape while the methodology is still being developed. The specifications and Impact Framework are on GSF’s GitHub; the Standards and Policy Working Groups are open to members; and the Academy is at academy.greensoftware.foundation.

This is where open standards, open source, policy, and education come together.

Thank you to the Linux Foundation, the Open Source Summit Europe community, and everyone who joined our session and continued the conversation afterwards.