Software Carbon  Intensity (SCI) Specification

Software Carbon Intensity (SCI) Specification

By: Standards Working Group

The Software Carbon Intensity (SCI) Specification defines a methodology for calculating the rate of carbon emissions for a software system. The purpose is to help users and developers make informed choices about which tools, approaches, architectures, and services they use in the future. It is a score rather than a total; lower numbers are better than higher numbers, and reaching 0 is impossible.

chairs
Abhishek Gupta
Abhishek Gupta
Henry Richardson
Henry RichardsonSenior Analyst
members
Anuja Gadre
Asim Hussain
Benjamin Davy
Chris Lloyd-Jones
Dan Lewis-Toakley
Elmar Borgmeier
Fergus Kidd
Jose Lopez Dominguez
Matthew Kotsenas
Navveen Balani
Pierre Lagarde
Santiago Fontanarrosa
Sara Bergman
Sarah Hsu
Srinivasan-Rakhunathan
Taylor Prewitt
Toru Shimogaki
Vaughan Knight
Vinal Bagaria
Yusuke Kobayashi
Ziliang Zong
Summary

"If you can't measure it, you can't improve it." - Peter Drucker

The Software Carbon Intensity (SCI) Specification defines a methodology for calculating the rate of carbon emissions for a software system. The purpose is to help users and developers make informed choices about which tools, approaches, architectures, and services they use in the future. It is a score rather than a total; lower numbers are better than higher numbers, and reaching 0 is impossible.

The SCI is for everyone. It is possible to calculate an SCI score for any software application, from a large distributed cloud system to a small monolithic open source library, any on-premise application or even a serverless function. The product or service may be running in any environment, whether a personal computer, private data center or a hyperscale cloud.

Reducing an SCI score is only possible through changes to a software system to use less physical hardware, less energy, or consume lower-carbon energy sources. Neutralisations such as carbon offsets do not reduce an SCI score.

How we work

This project works via consensus and voting. Our aim is to ensure all members agree on all changes to the specification, in the case where we cannot reach consensus we hold a vote.

We work entirely through GitHub, our GitHub repo is here. We first discuss ideas in the discussions tab. Once we are happy with the state of the discussion and are ready to make a change to the specification we move the discussion to a GitHib issue and start working on details of the pull request. Eventually one of the team members creates a pull request and we then have a process by which we agree on the merging of the PR.

RESOURCES