Skip to content
Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Go to file
* Added template for case studies

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Implement proposed reporting requirements from discussion 103 (#123)

* Add first pass of text

* Add reference to RFC4122

* Added description of valid requirements

* Added first examples

* Grammar review

* Remove JSON

* Move table structure to appendix

* Remove reporting process

* Changed software boundary reporting requirements

* Removed other references to reports

* updated URLs

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Update Software_Carbon_Intensity/

Co-authored-by: Asim Hussain <>

* Changed baseline preset text

* Made software version mandatory

* Removed the requirement to report C and R baseline comment

Co-authored-by: Asim Hussain <>
Co-authored-by: Abhishek Gupta <>

* Market instruments and grid interconnected infrastructure discussion

* Typos

* Update

1. The software-boundary was not linked correctly.
2. Readability - LCA definition was defined later, moved it to the first reference.

* Update

1. Functional Unit was not linked properly

* Update

Qualifying that the elements in the SCI equation scale by the same functional unit R

* adding units to 'M' and reformatting for consistency (#231)

* Add files via upload

* Update issue templates

* adding units

- units added for embodied emissions
- moved units to the bottom of each section 
- reformatted for consistency

Co-authored-by: Abhishek Gupta <>
Co-authored-by: Sean Mcilroy <>
Co-authored-by: Sean Mcilroy <>
Co-authored-by: Henry-WattTime <>

* Eshoppen case study initial draft

* Rename eshoppen to

* Added definition on how software causes emissions

* changed wording to software systems

* Update

Included the changes for the Energy and Embodied emissions values for the database server.

* Update

Updated the Software Carbon Intensity Standard to include guidance on taking into account data center energy efficiency in the Software Boundary section

* Update Software_Carbon_Intensity/

Space added

Co-authored-by: Abhishek Gupta <>

* Added context for SCI reduction for software roles

Added context for SCI reduction for software roles

* Procedure Flow Updates

1. 'scale' should be first step in the process, as it's the key measure of success
2. 'what' is a bit misleading, and is best defined as a boundary  -> 'bound' is a good verb
3. 'how' is a step that best follows the boundary step -> 'bound' is a verb

* Reverse list order

WG approved

* Text edits to introduction

* Focus on elimination/abatement (#290)

* Changed wording to highlight elimination

* Change exclusions

WG Approved

* Add space

WG approved

* Restore dev action sentence

WG Approved

Co-authored-by: Henry-WattTime <>

* Composable SCI Scores

* Update

Updated as per WG feedback

* add space

WG Approved

* Spelling correction in the introduction section

* Be explicit regarding only eliminations

We've made it explicit in `I` but I believe we also need to make it explicit in `M`.

* Copywriter updates

* Update

* Update

a few minor improvements to wording on the readme, including a typo or two...

* Update

WG Approved.

Co-authored-by: Abhishek Gupta <>

* Apply suggestions from code review

WG Approved

Co-authored-by: Abhishek Gupta <>

* Update

Some suggested changes to the 'scope' section, based on my first impressions/first read...

* Update Software_Carbon_Intensity/

WG approved

* Update (#298)

* Update

A few relatively minor suggested updates to the Introduction

* Update Software_Carbon_Intensity/

WG Approved.

* Apply suggestions from code review

WG Approved

Co-authored-by: Abhishek Gupta <>

Co-authored-by: Henry-WattTime <>
Co-authored-by: Abhishek Gupta <>

* Update (#299)

small change to the 'Software Sustainability Actions' section. I'd like to suggest we also rename 'Energy Efficiency' to 'Software Efficiency', but we should discuss that one and I can explain my thinking...

Co-authored-by: Henry-WattTime <>

* Update (#300)

minor suggested tweaks to the Procedure section, that might improve readability

Co-authored-by: Henry-WattTime <>

* Re-order formula for clarity (#304)

* Re-order formula for clarity

Reversed hierarchy from complex formula at the top and simple formula at the bottom. Now you build knowledge as you go down: SCI = C / R -> SCI = (O + M)/R -> SCI = (O formula + M formula)/R.

* Update Software_Carbon_Intensity/

WG removed change.

* Update Software_Carbon_Intensity/

WG Approved

* Update issue templates

* Update issue templates

* Update issue templates

* Refine definitions of O & M

* Removed table from the definitions section 

Removed definitions from the document and added link to the GSF dictionary where definitions for the terms used in the document are / will be stored

* Removed abbreviations section 

Removed the abbreviations section and merged it into the definitions section with a reference to the GSF dictionary for both

* Reorder Embodied Emissions Calculation

* Change Reporting Requirement in Procedure

Instead of requiring reporting (which we have not yet developed requirements for) just indicate that reporting should be done.

* Updated version note

* ISO submission editorials (#331)

* Removed Versions section

* Replace RFC2119 key words with ISO notation

* Revise Scope

* Revised/moved Introduction

* Added Terms and definitions section

* Revised sw sustainability thru location-based

* Revised Embodied Emissions & Functional unit

* Revised s/w boundary thru comparing an SCI

* Revised Code Characteristics thru end; added Bibliography

* Apply minor tweaks

* Update Software_Carbon_Intensity/

* Apply suggestions from code review

Co-authored-by: Rex Jaeschke <>
Co-authored-by: Abhishek Gupta <>

Co-authored-by: Abhishek Gupta <abhishekgupta@Abhisheks-MacBook-Pro.local>
Co-authored-by: Abhishek Gupta <>
Co-authored-by: Asim Hussain <>
Co-authored-by: Chris Lloyd-Jones <>
Co-authored-by: Henry-WattTime <>
Co-authored-by: Navveen Balani <>
Co-authored-by: Srinivasan <>
Co-authored-by: Will Buchanan <>
Co-authored-by: Sean Mcilroy <>
Co-authored-by: GadhuNTTDATA <>
Co-authored-by: Ben Logan <>
Co-authored-by: Rex Jaeschke <>
16 contributors

Users who have contributed to this file

Software Carbon Intensity (SCI) Specification


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

Software systems cause emissions through the hardware that they operate on, both through the energy that the physical hardware consumes and the emissions associated with manufacturing the hardware. This 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. This specification is focused on helping users and developers understand how to improve software to reduce or avoid the creation of emissions.

Reducing an SCI score is only possible through the elimination of emissions. That can be achieved by modifying a software system to use less physical hardware, less energy, or consume lower-carbon energy sources. Neutralization or avoidance offsets do not reduce an SCI score (see exclusions section). This makes the SCI an ideal strategy that organizations can adopt to meet climate targets focused on eliminating emissions, such as those specified by [1].

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 environment the product or service is running in can also vary; from personal computers, private data centers or a hyperscale cloud.

Software practitioners have a significant role to play in collectively reducing the SCI score during the design, development, and delivery of software applications. The following list provides some strategies that can be used to do this across different software roles:

  • For a software programmer, this implies writing energy efficient code.
  • For an AI/ML developer, it implies model optimization, using pre-trained models or leveraging optimized hardware for training.
  • For a database engineer, this comprises choices like schema design, choice of storage, and query optimizations.
  • For a DevOps practitioner, this requires creating a carbon-aware pipeline and considering when to schedule builds and leverage clean energy.
  • For QA engineers, it involves creating energy efficient test automation and performance testing scripts across browsers and devices.
  • For an architect, this implies choices like serverless or event driven architectures, infrastructure optimization, and design for carbon-aware systems.

The SCI encourages calculation using granular real-world data, which is challenging to obtain in some environments, particularly the public cloud. Access to the data needed for higher resolution calculations might not always be available. Where this is the case, users of this specification are strongly advised to request such data from their suppliers (be they hardware, hosting, or other).

In situations where there is a lack of access, capability, or rights to the necessary real-world data, the SCI allows for data generated through modeling, using best estimates instead.


This specification describes a methodology for calculating the rate of carbon emissions for a software system; that is, its SCI score. The purpose of this score is to increase awareness and transparency of an application's sustainability credentials. The score will help software practitioners make better, evidence-based decisions during system design, development, and deployment, that will ultimately minimize carbon emissions. A reliable, consistent, fair and comparable measure allows targets to be defined during development and progress to be tracked.

Terms and definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

explicit outcome taken, or change avoided, depending on the quantifiable emissions measured by this specification

Note to entry: Actions generally relate to using less electricity, using electricity more intelligently, or using less hardware.

attribute of software or hardware that adjusts its behavior (consumption of inputs, processing, or production of outputs) in response to the carbon intensity of the energy it consumes

The following abbreviations are used throughout this specification:

  • E – Energy consumed by a software system
  • I – Location-based marginal carbon intensity
  • M – Embodied emissions of the hardware needed to operate a software system
  • O – Operational emissions based on the emissions caused by energy consumption
  • R – Functional unit

Software sustainability actions

All actions that serve to reduce the carbon emissions of a piece of software fit into one of the following categories:

  • Energy Efficiency: Actions taken to make software use less electricity to perform the same function.
  • Hardware Efficiency: Actions taken to make software use fewer physical resources to perform the same function.
  • Carbon Awareness: Actions taken to time- or region-shift software computation to take advantage of cleaner, more renewable or lower carbon sources of electricity.

It is the intent of this specification to encourage more of these actions to be taken during the design, development, and maintenance of software applications.


The steps required to calculate and report an SCI score are:

  1. Bound: Decide on the software boundary; i.e., the components of a software system to include.
  2. Scale: As the SCI is a rate (carbon emissions per one functional unit), pick the functional unit which best describes how the application scales.
  3. Define: For each software component listed in the software boundary, decide on the quantification method; real-world measurements, based on telemetry, or lab-based measurements, based on models.
  4. Quantify: Calculate a rate for every software component. The SCI value of the whole application is the sum of the SCI values for every software component in the system.
  5. Report: Disclose the SCI score, software boundary, and the calculation methodology.

Methodology summary


SCI is a rate; carbon emissions per one unit of R. The equation used to calculate the SCI value of a software system is:

SCI = C per R


  • The total amount of carbon C the software causes to be emitted.
  • All the elements in the SCI equation scale by the same functional unit of R (e.g., carbon emissions per additional user, API-call, or ML training run).

This can be expanded to:

SCI = (O + M) per R

Operational emissions


To calculate the operational emissions associate with software, multiply the electricity consumption of the hardware the software is running on by the regional, granular marginal emissions rate. The marginal emissions rate reflects the change in emissions associated with a change in demand.

To calculate the operational emissions O for a software application, use the following:

O = (E * I)


This is the energy consumed by a software system for a functional unit of work. This could be applied to several taxonomies:

  • Datacenter
  • Individual machine (e.g., VM/Node)
  • Individual service (e.g., API call or ML training run)
  • Execution of code

Units: this shall be in kilowatt hours (kWh).

Location-based marginal carbon intensity

The carbon intensity of electricity is a measure of how much carbon (CO2eq) emissions are produced per kilowatt-hour (kWh) of electricity consumed. Because this specification uses a consequential approach, marginal emissions rates shall be used for electricity consumption.

Location-based marginal emissions factors measure the grid carbon intensity of a grid region. If the electricity consumption is connected to a grid, the marginal emissions rate of that grid shall be used, which excludes any market-based measures. If the electricity consumption is not connected to a larger regional grid, an appropriate emissions factor for that system shall be used. From a developer perspective, only the location-based info is important in terms of the impact on eliminating carbon emissions. This excludes market-based measures and is distinct from 100% renewable energy claims.

The only figure that matters when trying to optimize the scheduling of a computation in real-time is the marginal emissions intensity. This is the emissions intensity of the marginal power plant which will need to be turned up if a computation is scheduled (e.g., increase electricity demand from the grid) at that moment.

Units: this shall be in grams of carbon per kilowatt hours (gCO2eq/kWh).

Embodied emissions

Embodied carbon (otherwise referred to as “embedded carbon”) is the amount of carbon emitted during the creation and disposal of a hardware device.

When software runs on a device, a fraction of the total embodied emissions of the device is allocated to the software. This is the value of M that needs to be calculated in the SCI equation.

This fraction consists of both a time- and resource-share. The length of time that the software runs on the device determines its time-share. The percentage of the device reserved just for that application during the time-share determines that application's resource-share.

To calculate the time-share, amortize the total embodied carbon over the expected life span of the device and then extrapolate based on the time reserved for the usage. For example, if the device’s embodied carbon was 1000kg with an expected lifespan of four years and it was reserved for use for one hour, the time-share embodied emissions would be 1000 * 1/(4*365*24) or around 28g of the total.

To calculate resource-share, look at the share of total available resources reserved for use by the software. For instance, the percentage of total virtual CPUs reserved for the software is a good choice for the resource-share metric in the virtualized cloud space.

To calculate the share of M for a software application, use the equation:

M = TE * TS * RS


  • TE = Total Embodied Emissions; the sum of Life Cycle Assessment (LCA) emissions for all hardware components.
  • TS = Time-share; the share of the total life span of the hardware reserved for use by the software.
  • RS = Resource-share; the share of the total available resources of the hardware reserved for use by the software.

The equation can be expanded further:

M = TE * (TiR/EL) * (RR/ToR)


  • TiR = Time Reserved; the length of time the hardware is reserved for use by the software.
  • EL = Expected Lifespan; the anticipated time that the equipment will be installed.
  • RR = Resources Reserved; the number of resources reserved for use by the software.
  • ToR = Total Resources; the total number of resources available.

An estimate of all the embodied emissions for the hardware used within the software boundary shall be included.

Simple models to estimate embodied emissions may be used; however, the most granular data possible and ideally emissions data from a device’s LCA when calculating the embodied carbon should be used.

Since the purpose of the SCI is the elimination of emissions M shall not include any market-based measures.

Units: this shall be in grams of carbon (gCO2eq).

Functional unit conversion

An aggregate SCI score can be composed of multiple component SCI scores.

Then, as long as the functional unit of R is the same across all the component SCI scores, these can be summed to calculate the aggregate SCI. To sum multiple component SCI scores into one aggregate score, the functional unit R shall be the same across all components.

If the functional unit of a software component is not the same as the aggregate functional unit, then the component SCI score needs to be converted to match that of the aggregate SCI functional unit. Details of any unit conversion factors used in calculating the SCI score shall be disclosed.

Software boundary

The first step in generating an SCI score is deciding what the boundaries of the software system are; i.e., what software components to include or exclude in the calculation of the SCI score.

The calculation of SCI shall include all supporting infrastructure and systems that significantly contribute to the software’s operation.

Supporting infrastructure and systems may include:

  • compute resources
  • storage
  • networking equipment
  • memory
  • monitoring
  • idle machines
  • logging
  • scanning
  • build and deploy pipelines
  • testing
  • training ML models
  • operations
  • backup
  • resources to support redundancy
  • resources to support failover
  • End user devices
  • IoT devices
  • Edge devices

If the boundary includes on-premise and/or cloud data center operations, E should take into account the efficiency of the data center, including cooling and other energy consumption necessary to operate a data center. The data center's energy efficiency is usually available as a PUE (Power Usage Effectiveness) value.

Functional unit

The second step in generating an SCI score is deciding which functional unit will be used to describe how the application scales. First, decide on the functional unit, using the choice of R. Then calculate how much C is emitted per unit of R.

For instance, if the application scales by number of users then choose this as the functional unit.

A consistent choice of R across all the components in the software boundary shall be used.

A suggested list of functional units includes:

  • API call/request
  • Benchmark
  • User
  • Machine
  • Minute/time unit
  • Device
  • Physical site
  • Data volume
  • Batch/Scheduled Job
  • Transaction
  • Database read/write

Quantification method


The third step in generating an SCI score is deciding the approach to take when quantifying the carbon emissions for each component in the software boundary.

The goal of the SCI is to quantify how much C (carbon) is emitted per one unit of R.

There are two main approaches to quantifying carbon emissions (C), measurement via real-world data or calculation via models.

Each component in the software boundary may use either measurement or calculation to quantify the carbon emissions.

It is strongly advised that suppliers (be they hardware, hosting, or other) be contacted regarding the data needed in the resolution required for quantifying the SCI score.


Carbon emissions may be quantified by measuring the total real-world carbon emissions of the component (C) over a time period and dividing by the number of functional units (R) in the same time period to get C per R. For instance, data regarding the real-world usage of the application "in the wild" might be measured and then divided by the number of users serviced in the same time period to get C per user.


What one unit of R looks like may be modelled and the total carbon (C) calculated for executing one functional unit of work (R) in a controlled lab environment. For instance, a benchmark application may be created that models a user interacting with your application and then measure the C emitted per run of that benchmark. The result is still a C per user.

Comparing an SCI score to a baseline

When taking an action to reduce the carbon intensity of a piece of software, the intensity should be compared to a baseline. The baseline shall be calculated using an identical methodology to how the proposed SCI was calculated, except excluding the proposed action(s). The measurements, assumptions, models, functional units, etc. shall remain the same between the baseline and proposed SCI.

Core characteristics

As this specification develops, the following core characteristics shall remain true:

  • The SCI is sensitive to carbon awareness, energy efficiency, and hardware efficiency

    • The purpose of the SCI is to encourage actions that reduce the carbon emissions of software. Therefore, the SCI shall be sensitive to those actions described in this document under Software Sustainability Actions; specifically, carbon awareness, energy efficiency, and hardware efficiency.
    • If an application's SCI is X, and then actions are taken to make the application more carbon aware, more energy efficient, or more hardware efficient, the value of X shall go down.
  • The SCI takes a systems-impact view

    • The purpose of the SCI is to encourage actions that reduce carbon emissions of software in a way that creates reductions at a system-wide level rather than just at a local level. Local-level optimizations may lead to micro improvements but may have negative downstream impacts at a macro level that negate the impact of those actions.
    • Such a systems view shall be adopted by articulating the boundaries of the software and its associated infrastructure, keeping in mind the exclusions mentioned in this specification.
  • The SCI is easy to implement
    To achieve impact at scale, the SCI encourages adoption through ease of implementation.

    • Anyone without much experience or training shall be able to follow the SCI specification instructions.
    • Calculation of the SCI shall be possible without incurring any cost, for instance, for data, services, or tooling.
    • Where possible, teams should consider investing more time or money in calculating their SCI number to increase its accuracy.
  • The SCI encourages the use of granular data
    In calculating the SCI value, the highest granularity data available should be used to compute each of O, E, I, and M. In cases where temporal granular data is not available, annual values shall be used which are the lowest acceptable level of granularity.



The focus is elimination, not offsetting. One tonne of carbon eliminated (meaning that it was not emitted into the atmosphere) is not the same as one tonne of carbon that has been offset. By far the more preferable goal is never to have emitted the carbon in the first place.

Only actions that eliminate emissions reduce an SCI score. As such, an SCI score cannot be reduced through carbon offsets, such as market-based measures.

Market-based measures

Market-based measures are financial instruments designed to neutralize or offset carbon emissions. Market-based measures include, but are not limited to the following:

  • Carbon offsets or credits
  • A Removal Unit (RMU)
  • An Emission Reduction Unit (ERU)
  • A Certified Emission Reduction (CER)
  • Electricity Attribute Certificates (EACs)
  • Power Purchase Agreements (PPAs)
  • Renewable Energy Credits (RECs)


The following documents are useful references for implementers and users of this document:

[1] The Net-Zero STANDARD, Science Based Targets initiative (SBTi),