Software Carbon Intensity (SCI) Specification

The specification defines SCI as a rate: Carbon per Functional Unit. The formula is SCI = ((E * I) + M) per R.

• E (Energy): Total energy consumed by the software system.
• I (Location-based Carbon Intensity): The marginal emissions rate of the grid powering the hardware.
• M (Embodied Emissions): The amortized carbon cost of the physical hardware.
• R (Functional Unit): A scaling factor that defines the software's utility (e.g., per API call, per user, per training run).

This structure ensures that carbon efficiency is measured against actual value delivered, not just total emissions.

The Functional Unit (R) is the most critical variable in the SCI, acting as the denominator that scales emissions by utility. It transforms a raw carbon total into a carbon intensity rate.

• Actionable Comparison: It allows comparing two versions of the same application (e.g., a new model vs. an old model) by their carbon cost per prediction.
• Examples: per API request, per minute of streaming, per user session, per training epoch.
• Goal: A smaller SCI score indicates better carbon efficiency, even if total system usage grows.

Choosing the right functional unit is a core governance decision that prevents 'greenwashing' through scale.

The SCI specification requires a clear definition of the software boundary to ensure consistent and auditable measurements.

• Inclusions: All supporting infrastructure and systems that contribute to the software's operation, including gateways, load balancers, and CI/CD pipelines.
• Exclusions: External systems not controlled by the software operator.
• Granularity Levels: The SCI can be calculated at multiple levels—from a single microservice to an entire application suite—as long as the boundary is explicitly stated.

This prevents selective accounting and ensures the full operational footprint is captured.

The SCI is not a static label but a dynamic, actionable score designed to drive a continuous reduction loop.

• Delta Comparison: The primary use case is comparing the SCI of a software system before and after a change (e.g., a code refactor, a cloud region shift, or a hardware refresh).
• Reduction Strategies: The equation directly maps to mitigation levers:
  • Reduce E: Optimize code, use energy-proportional hardware.
  • Reduce I: Shift workloads to low-carbon regions via carbon-aware scheduling.
  • Reduce M: Extend hardware lifespan, use fewer physical servers.
  • Increase R: Serve more functional units with the same carbon cost.

This makes the specification a prescriptive tool for engineers, not just a reporting metric.

The SCI specification explicitly rejects carbon offsetting as a component of the score. It measures gross emissions intensity, not net-zero claims.

• No Offsetting: Purchasing carbon credits or renewable energy certificates (RECs) does not reduce the SCI score.
• Direct Decarbonization: The specification forces organizations to focus on actual engineering improvements—energy efficiency, hardware longevity, and demand shifting—rather than accounting maneuvers.
• Complementary Role: Offsetting is recognized as a separate, valid corporate strategy but is kept distinct from the technical intensity metric to preserve its integrity as an engineering benchmark.

This hard line ensures the SCI remains a pure measure of software's physical environmental impact.