Measure Before You Claim: Carbon Accounting for Software Systems
Most software sustainability reporting is arithmetic performed on assumptions. A defensible baseline is harder to build and far more useful — it tells you which levers exist and what moving them did.
Software sustainability reporting has a credibility problem, and it is self-inflicted. A great deal of what gets published is an estimate multiplied by an assumption and presented as a measurement. The arithmetic is fine. The inputs are guesses.
This matters beyond honesty. A baseline built on guesses cannot tell you which lever to pull, because the guesses dominate the variance. The work of measuring properly is also the work of finding out where the consumption actually is.
Start with what is metered
Some things are genuinely measured. Cloud providers publish region-level carbon intensity and per-service consumption data with varying granularity. Data centre operators report power usage effectiveness. Grid operators publish real-time carbon intensity per region, often at hourly resolution or better. Server hardware exposes power draw through management interfaces.
Build the baseline from these first, and record the provenance of every figure alongside it — source, granularity, and the date it was retrieved. When the number is challenged, and it will be, provenance is the difference between a discussion and a retraction.
Be explicit about the estimated parts
Some things cannot be metered directly. Embodied carbon in hardware is amortised from manufacturer disclosures of varying quality. End-user device energy is modelled, because you cannot instrument your users. Network transfer energy is estimated from coefficients that vary by an order of magnitude across published studies.
The answer is not to omit these. It is to label them. A baseline that separates measured, derived and estimated components, and states the assumption behind each estimate, is a document that survives scrutiny. A single aggregate figure is not, because the first question will be how it was produced and there will be no answer.
Where a coefficient is genuinely uncertain, carry the range rather than the midpoint. A result expressed as a range with stated bounds is more useful than a false point estimate, and it makes clear which uncertainties are worth reducing.
The levers that actually exist
Once the baseline separates measurement from estimate, the levers become visible. In practice they are a short list.
Utilisation is usually the largest and the least glamorous. Idle infrastructure consumes a substantial fraction of its peak power while producing nothing. Consolidation, right-sizing and shutting down non-production environments outside working hours are boring changes with real effect, and they are measurable directly rather than modelled.
Placement matters where workloads are movable. Carbon intensity varies by region by a factor of several, and by time of day within a region. Batch work — training runs, reports, backups, reindexing — can often be scheduled against intensity signals without any user-visible change. Interactive workloads usually cannot, and pretending otherwise produces a latency incident.
Efficiency in hot paths matters at scale and almost nowhere else. Optimising a function that runs a thousand times a day is an engineering exercise; optimising one that runs a billion times is an energy decision. Profile before choosing.
Data retention is quietly significant. Storage consumes power continuously and grows monotonically unless someone decides otherwise. Lifecycle policies, tiering to cold storage and actually deleting what has no owner are among the few changes that reduce both cost and consumption without any trade-off worth arguing about.
Hardware lifetime is the lever most often ignored. Embodied carbon is a large share of a server total footprint. Extending useful life through repair, reallocation to less demanding workloads, or resale usually beats replacing with a marginally more efficient generation — and it is a procurement decision, not an engineering one, which is why it needs the baseline to be argued at all.
Report the delta, not the absolute
The absolute footprint of a software system is a number with wide error bars, and defending it consumes energy of a different kind. The change in that footprint, measured with a consistent method before and after a specific intervention, is far more robust: the systematic errors largely cancel.
So report deltas. Name the intervention, state the method, show the before and after, and keep the method stable across reporting periods. That is a claim that holds up.
Anything else is arithmetic performed on assumptions, and it should not be published with a percentage sign attached.