Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update SPEC.md #91

Open
wants to merge 1 commit into
base: proposed-new-dev
Choose a base branch
from
Open

Update SPEC.md #91

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
54 changes: 27 additions & 27 deletions SPEC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,14 +5,14 @@ version: 0.0.1

## Introduction

In the context of global digital transformation, the role of software in contributing to carbon emissions has become increasingly significant. This necessitates the development of standardized methodologies for assessing the environmental impact of software systems.
In the context of global digital transformation, software's role in contributing to carbon emissions has become increasingly significant. This necessitates the development of standardized methodologies for assessing software systems' environmental impact.

Rationale:

- The Rising Carbon Footprint of Software: The digitization of nearly every aspect of modern life has led to a surge in demand for software solutions, subsequently increasing the energy consumption and carbon emissions of the IT sector.
- The Need for a Unified Approach: Currently, the lack of a standardized system for labeling the carbon efficiency of software products hinders effective management and reduction of carbon footprints across the industry.
The Need for a Unified Approach: Currently, the lack of a standardized system for labelling software products' carbon efficiency hinders effective management and reduction of carbon footprints across the industry.

This document aims to establish the Software Carbon Efficiency Rating (SCER) Specification, a standardized framework for labeling the carbon efficiency of software systems. The SCER Specification aims to serve as a model for labeling software products according to their Software Carbon Intensity (SCI), and it is adaptable for different software categories.
This document establishes the Software Carbon Efficiency Rating (SCER) Specification, a standardized framework for labelling software systems' carbon efficiency. The SCER Specification serves as a model for labelling software products according to their Software Carbon Intensity (SCI) and is adaptable to different software categories.


## Scope
Expand Down Expand Up @@ -64,32 +64,32 @@ The following abbreviations are used throughout this specification:
## Core Requirements

### Ease of understanding
A label that is hard to understand or requires expertise not available to most software consumers would defeat the purpose of adding transparency and clarity.
A label that is hard to understand or requires expertise unavailable to most software consumers would defeat the purpose of adding transparency and clarity.

So, the SCER shall use common terms on the label instead of more scientific terminology.
So, the SCER shall use standard terms on the label instead of more scientific terminology.

Common terms and their scientific equivalent Shall be defined clearly in the SCER specification to avoid interpretation risks.
Standard terms and their scientific equivalent Shall be defined clearly in the SCER specification to avoid interpretation risks.

SCER labels shall be uncluttered and have a clear and simple design that Shall be easily understood.

### Ease of Verification
The SCER label Shall make it easy for a consumer of a software application to be able to verify any claims made.
The SCER label Shall make it easy for a consumer of a software application to verify any claims made.

Consumers should have all the information they need in order to verify any claims made in the label and to ensure the undering calcualtion methodology or any related specification have been followed accurately.
Consumers should have all the information they need to verify any claims made on the label and ensure the underlying calculation methodology or any related specification has been followed accurately.

### Accessible
The SCER label and format shall be accessible to and meet accessibilty specifications
The SCER label and format shall be accessible to and meet accessibility specifications.

### Language
The SCER label Should be written using the Engline language and alphabet, understanding the SCER label should not require you to learn another language.
The SCER label Should be written using the English language and alphabet; understanding the SCER label should not require you to learn another language.

## Calculation Methodology

The SCI shall be used as the calculation methodology for the SCER label.

Any computation of a SCI score for the SCER label SHALL adhere to all requirements of the SCI specification.

> Note: SCI is a Software Carbon Efficiency Specification which is computed a "Carbon per Functional Unit" of a software product. For example, Carbon per Prompt for a Large Language Model.
> Note: SCI is a Software Carbon Efficiency Specification that computes the "Carbon per Functional Unit" of a software product, such as the Carbon per Prompt for a large language model.

## Presentation Guidelines

Expand All @@ -102,34 +102,34 @@ The presentation of the SCI score Shall follow this template

- Where `[Decimal Value]` is the SCI score itself
- Where the common term `Carbon` Shall be used to represent the more technical term `CO2e` (Carbon Dioxide Equivalent)
- The symbol `/` Shall Not be used in place of `Per`
- The symbol `/` Shall Not be used instead of `Per`.
- Where `[Functional Unit]` is text describing the Functional Unit as defined in the SCI calculation for this software application

### SCI Version
This Should be clearly visiible even at small sizes.
This Should be visible even in small sizes.

This Shall be describe which version of the SCI specification that this SCER label complies with and have the format:
This Shall describe which version of the SCI specification this SCER label complies with and have the format:

`[Short Name] [Version]`

- Where `[Short Name]` is the abreviated version of the SCI specification this SCER label is representing
- Where `[Version]` is the official version of the SCI specification this label is refereing to.
- Where `[Short Name]` is the abbreviated version of the SCI specification, this SCER label is representing
- Where `[Version]` is the official SCI specification version this label refers to.

For example:
- `SCI 1.1`
- `SCI AI 1.0`

### QR Code
This Shall be a URL represented as a QR code as per ISO (?? What's the ISO for QR?)
This Shall be a URL represented as a QR code per ISO (?? What's the ISO for QR?)

The URL Shall point to a publicly accessible website where you can download a manifest file that meets the requrements in the *Supporting Evidence Section*
The URL Shall point to a publicly accessible website where you can download a manifest file that meets the requirements in the *Supporting Evidence Section*

The URL Shall Not require a login, it Shall be publicly accessible by anonymous users or non-human automated bots/scripts.
The URL Shall Not require a login; it Shall be publicly accessible by anonymous users or non-human automated bots/scripts.

## Display Requirements
> TBD, notes for expansion later.
> TBD; notes for expansion later.

The SCER Label Shall coform to this layout:
The SCER Label Shall conform to this layout:

- Color: Black and White
- Size: ??
Expand All @@ -138,32 +138,32 @@ The SCER Label Shall coform to this layout:
- Example: ??

## Supporting Evidence
As per the presentation guidelines the SCER label will point towards a manifest file that provides the evidence to support any claims made in the label.
As per the presentation guidelines, the SCER label will point to a manifest file that provides evidence to support any claims made in the label.

The manifest file Shall meet 3 criteria to pass as supporting evidence.

### Conformance
Evidence that the underlying SCI requirements have been met in the computation of the SCI score.

The Manifest File Shall clearly describe the Software Boundary as per the SCI specification.
The Manifest File Shall clearly describe the Software Boundary, per the SCI specification.

The Manifest File Shall be follow the Impact Manifest Protocol Standard for communicating environemtnal impacts.
The Manifest File Shall follow the Impact Manifest Protocol Standard for communicating environmental impacts.

The Manifest File Should use granular data inline with SCI recommendations.
The Manifest File Should use granular data that aligns with SCI recommendations.

### Correctness
Correctness is the act of confirming the numbers in the manifest file match the information on the SCER label.

The Manifest File Shall have an aggregate value for the SCI score which matches the reported Score in the SCER label.

The Manifest File Shall have a Functional Unit which matches the reported Functional Unit in the SCER label.
The Manifest File Shall have a Functional Unit that matches the reported Functional Unit in the SCER label.

### Verification
Verification is the act of confirming the evidence supports the claim.

Verification of a SCER label Shall be possible using open source software and open data.

Verification Shall be free for the end user and Shall Not require the purchasing of licenses for software or data or the logging into external systems.
Verification Shall be free for the end user and Shall Not require the purchasing of licenses for software or data or logging into external systems.

If Verification requires access to data, that data Shall also be publicly available and free to use.

Expand Down