Standardize a single comparable carbon metric per unit of software work
#00168
Every tool in this space estimates differently, so numbers are not comparable across teams or vendors. A shared specification expresses software carbon as a rate — emissions per functional unit such as a request, user, or training run — so results can be compared and tracked over
Parent issue
#00164 The carbon footprint of software and AI compute is rarely measured, so it cannot be managed
Tags
Sustainable Development Goals
Location
Description
The proposal
Adopt a common specification that scores software carbon as a rate rather than a total. The metric combines operational energy (E), grid carbon intensity (I), and embodied emissions (M) over a functional unit (R): SCI = (E × I) + M per R, where R is a chosen reference such as per request, per user, or per training run.
Why it works
A rate per functional unit lets teams compare architectures and vendors and track improvement over time — something absolute totals and offset-based accounting do not support. Standardising the method means results from different tools and organisations are directly comparable.
Where it fits
Any team or vendor that wants comparable, reportable software-carbon numbers, and any measurement tool that wants interoperable outputs. It sits on top of existing measurement approaches rather than replacing them.
Trade-offs and limitations
Developers often lack exact hardware specifications or embodied-hardware amortisation periods, making the metric easier to apply to whole applications than to isolated code sections. A marginal, consequential accounting stance ties the score to real-world reductions but is harder to source than average grid factors.
Sub-issues
0Case studies
1