diff --git a/.github/ISSUE_TEMPLATE/case-study-template.md b/.github/ISSUE_TEMPLATE/case-study-template.md
deleted file mode 100644
index 9aa4bab..0000000
--- a/.github/ISSUE_TEMPLATE/case-study-template.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-name: Case-study template
-about: This is a template to use for case studies that are submitted to apply the
- SCI.
-title: Test case submission
-labels: Case-study submission
-assignees: atg-abhishek, Henry-WattTime
-
----
-
-# Case Study Template
-
-*This is a template to use for case studies that are submitted to apply the SCI. *
-
-*Please delete the text in italics and replace it with the appropriate information.*
-
-*For more information on any of the items, the final reference is the [SCI Specification](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md)*
-
-*If you find errors, or have further questions, please feel free to engage with us in the [discussions](https://github.com/Green-Software-Foundation/software_carbon_intensity/discussions) section.*
-
-## Overview
-
-_Please provide information describing the use case in a few bullet points_
-
-## Architecture for the system under consideration
-
-_An architecture diagram of the system described in this use case_
-
-### Technical details of the components in the architecture
-
-_Textual description with technical details of each component provided in the architecture diagram_
-
-## Sites for Software Sustainability Actions
-
-_For each of the following sub-sections, indicate **where** and **how** actions can be taken in the following categories_:
-
-### Energy Efficiency
-
-1. _site of action_
-2. _description of the action_
-
-### Hardware Efficiency
-
-1. _site of action_
-2. _description of the action_
-
-### Carbon Awareness
-
-1. _site of action_
-2. _description of the action_
-
-## Procedure
-
-### (What) Software boundary
-
-_Describe the components that are included in the software systems, if any major components are not included then please provide **reasons for exclusion**_.
-
-For example:
-- Front end mobile application
-- Network traffic between client mobile applications and servers
-- Network traffic between servers and database
-- Back-end servers.
-- Databases
-- Test infrastructure
-
-### (Scale) Functional unit
-
-_Describe the [functional unit](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#functional-unit-r) that best controls the scaling of the software system.
-
-The choice of functional unit applies to all components in your software boundary.
-
-For example:
-- per API Call
-- per User
-_
-
-### (How) Quantification method
-
-_For each software component in your software boundary, decide whether you are going to **measure** using real-world data or **calculate** an estimate via models, provide a reason and any useful details for each choice.
-
-For example:
-- Front-end mobile application.
- - Calculate an estimate using a model that represents a single user using the application.
- - We do not have the right to export real-world measurements from individuals mobiles.
-
-- Back-end servers
- - Calculate an estimate of the energy consumption using models which take as input the CPU utilization of servers.
- - Calculate an estimate of the embodied carbon using the Treads low-resolution models based on AWS data.
-
-_Also, describe the reason for your choice_
-
-### (Quantify) SCI Value Calculation
-
-_Show your work! For each of the component of your software system, show how you arrived at the SCI value._
-
-_Guidance for this is available in the [Methodology summary](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#methodology-summary) section._
-
-### (Report)
-
-_Disclose the software boundary and your calculation methodology, including items that you might not have included in the previous sections_
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
new file mode 100644
index 0000000..34b5c71
--- /dev/null
+++ b/.github/workflows/deploy.yml
@@ -0,0 +1,53 @@
+# Simple workflow for deploying static content to GitHub Pages
+name: Deploy static content to Pages
+
+on:
+ # Runs on pushes targeting the default branch
+ push:
+ branches: ["dev"]
+
+ # Allows you to run this workflow manually from the Actions tab
+ workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+ contents: read
+ pages: write
+ id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+ group: "pages"
+ cancel-in-progress: false
+
+jobs:
+ # Single deploy job since we're just deploying
+ deploy:
+ environment:
+ name: github-pages
+ url: ${{ steps.deployment.outputs.page_url }}
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v3
+ - name: Install Node.js
+ uses: actions/setup-node@v2
+ with:
+ node-version: '18'
+
+ - name: Install dependencies and build
+ run: |
+ npm install
+ npm run build
+
+ - name: Setup Pages
+ uses: actions/configure-pages@v3
+ - name: Upload artifact
+ uses: actions/upload-pages-artifact@v2
+ with:
+ # Upload entire repository
+ path: '.'
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v2
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..b512c09
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
+node_modules
\ No newline at end of file
diff --git a/Software_Carbon_Intensity/License.md b/LICENCE.md
similarity index 100%
rename from Software_Carbon_Intensity/License.md
rename to LICENCE.md
diff --git a/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md b/SPEC.md
similarity index 90%
rename from Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md
rename to SPEC.md
index bda02a0..4e72adb 100644
--- a/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md
+++ b/SPEC.md
@@ -1,300 +1,301 @@
----
-version: 1.0.0
----
-
-# Software Carbon Intensity (SCI) Specification
-
-## Introduction
-
-> "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](#exclusions)). 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.
-
-## Scope
-
-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.
-
-## Normative reference
-There are no normative references in this document.
-
-## 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:
-- ISO Online browsing platform: available at https://www.iso.org/obp
-- IEC Electropedia: available at http://www.electropedia.org/
-
-T.1
-**action**
-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.
-
-T.2
-**carbon-aware**
-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.
-
-## Procedure
-
-The steps required to calculate and report an SCI score are:
-
-1. **Bound**: Decide on the [software boundary](#software-boundary); i.e., the components of a software system to include.
-1. **Scale**: As the SCI is a rate (carbon emissions per one [functional unit](#functional-unit-r)), pick the functional unit which best describes how the application scales.
-1. **Define**: For each software component listed in the software boundary, decide on the [quantification method](#quantification-method); real-world measurements, based on telemetry, or lab-based measurements, based on models.
-1. **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.
-1. **Report**: Disclose the SCI score, software boundary, and the calculation methodology.
-
-## Methodology summary
-
-### General
-
-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`
-
-Where:
-
-- 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
-
-#### General
-
-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)`
-
-#### Energy
-
-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](#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](#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 1000 kg 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 28 g 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`
-
-Where:
-
-- `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)`
-
-Where:
-
-- `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](#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
-
-### General
-
-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](#measurement) via real-world data or [calculation](#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.
-
-### Measurement
-
-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.
-
-### Calculation
-
-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 developer's 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 Awareness, 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. While local-level optimizations might lead to micro improvements, they might lead to 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](#software-boundary) of the software and its associated infrastructure, keeping in mind the [exclusions](#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.
-
-## Exclusions
-
-### General
-
-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
-
-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)
-
-## Bibliography
-
-The following documents are useful references for implementers and users of this document:
-
-[1] *The Net-Zero STANDARD*, Science Based Targets initiative (SBTi), https://sciencebasedtargets.org/net-zero
+---
+version: 1.1.0
+---
+# Software Carbon Intensity (SCI) Specification
+
+## Introduction
+
+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](#exclusions)). 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.
+
+## Scope
+
+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.
+
+## Normative references
+There are no normative references in this document.
+
+## 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:
+- ISO Online browsing platform: available at https://www.iso.org/obp
+- IEC Electropedia: available at http://www.electropedia.org/
+
+T.1
+**action**
+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.
+
+T.2
+**carbon-aware**
+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 – Region-specific 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
+
+T.3
+**carbon**
+Greenhouse gases are a group of gases contributing to global warming. In this specification we use 'carbon' as a broad term to refer to the impact of all types of emissions and activities on global warming.
+
+## 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.
+
+## Procedure
+
+The steps required to calculate and report an SCI score are:
+
+1. **Bound**: Decide on the [software boundary](#software-boundary); i.e., the components of a software system to include.
+1. **Scale**: As the SCI is a rate (carbon emissions per one [functional unit](#functional-unit-r)), pick the functional unit which best describes how the application scales.
+1. **Define**: For each software component listed in the software boundary, decide on the [quantification method](#quantification-method); real-world measurements, based on telemetry, or lab-based measurements, based on models.
+1. **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.
+1. **Report**: Disclose the SCI score, software boundary, and the calculation methodology.
+
+## Methodology summary
+
+### General
+
+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`
+
+Where:
+
+- 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
+
+#### General
+
+To calculate the operational emissions associated with software, multiply the electricity consumption of the hardware the software is running on by the region-specific carbon intensity.
+
+To calculate the operational emissions `O` for a software application, use the following:
+
+`O = (E * I)`
+
+#### Energy
+
+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).
+
+The energy consumption should include all energy consumed by hardware reserved or provisioned, not just the hardware actually used to meet the software needs.
+
+#### Region-specific 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.
+
+Region-specific carbon intensity factors measure the grid carbon intensity of electricity in a grid region. If the electricity consumption is connected to a grid, the short run marginal, long run marginal, or average emissions grid intensity of that grid shall be used, which excludes any [market-based measures](#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](#market-based-measures) and is distinct from 100% renewable energy claims.
+
+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 1000 kg 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 28 g 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`
+
+Where:
+
+- `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)`
+
+Where:
+
+- `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](#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
+
+### General
+
+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](#measurement) via real-world data or [calculation](#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.
+
+### Measurement
+
+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.
+
+### Calculation
+
+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 may be created that models a user interacting with a software application and then measures 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 Awareness, 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. While local-level optimizations might lead to micro improvements, they might lead to 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](#software-boundary) of the software and its associated infrastructure, keeping in mind the [exclusions](#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.
+
+## Exclusions
+
+### General
+
+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
+
+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)
+
+## Bibliography
+
+The following documents are useful references for implementers and users of this document:
+
+[1] *The Net-Zero STANDARD*, Science Based Targets initiative (SBTi), https://sciencebasedtargets.org/net-zero
diff --git a/Software_Carbon_Intensity/Appendix_A_Further_Information_on_Reporting_Requirements.md b/Software_Carbon_Intensity/Appendix_A_Further_Information_on_Reporting_Requirements.md
deleted file mode 100644
index 20788da..0000000
--- a/Software_Carbon_Intensity/Appendix_A_Further_Information_on_Reporting_Requirements.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# Appendix A: Further information on Reporting Requirements
-This appendix provides additional detail on validly formed machine-readable SCI reporting files, in YAML format.
-
-## File Structure
-
-To comply with this specification and implement carbon transparency, an entity MUST meet these reporting requirements. The hierachical structure of the YAML file is described below.
-
-### Data elements to be reported
-The following list contains the REQUIRED and OPTIONAL data elements to be reported.
-
-| Name | Identifier | Optionality | Format | Notes |
-| - | - | - | - | - |
-| Supporting infrastructure and systems contained within the [Software Boundary](Software_Carbon_Intensity_Specification#software-boundary) | sci/software-boundary | MUST | Text | A description of the software boundary for the entity. |
-| [Software Carbon Intensity](Software_Carbon_Intensity_Specification#reporting-the-sci-value) - `SCI`| sci/sci | MUST | Numeric | The [Software Carbon Intensity](Software_Carbon_Intensity_Specification#reporting-the-sci-value) of the entity itself.
-| [Software Carbon Intensity](Software_Carbon_Intensity_Specification#reporting-the-sci-value) - `R` baseline value | sci/r | MUST | Numeric |
-| [Software Carbon Intensity](Software_Carbon_Intensity_Specification#reporting-the-sci-value) - `R` baseline source| sci/r-source | MUST | Text | The text CAN refer to one of the identifiers in the [pre-set list](Software_Carbon_Intensity_Specification#preset-list-for-baselines), but it can also refer to a similar concept. |
-| Product Name, entity name, or Software Product | metadata/name | MUST | Text | |
-| Contact name | metadata/contact-name | MUST | Text | The point of contact responsible and accountable for the report. |
-| Contact email | metadata/contact-email | MUST | Text | The point of contact responsible and accountable for the report. |
-| Organization | metadata/organization | SHOULD | Text | This SHALL be populated where the report is not by an individual contributor, otherwise it is not required. |
-| GUID | metadata/guid | MUST | GUID | Following a format in [RFC4122], provided to uniquely identify this particular product, resource, or service. |
-| Software or Product Version | metadata/entity-version | MUST | Text | |
-| SCI Specification Version | metadata/sci-version | MUST | Numeric | The version of the SCI specification against which this report is being made. |
-| Date of Calculation | metadata/calculation-date | MUST | Date | Following a format described in [RFC3339], [a subset](https://ijmacd.github.io/rfc3339-iso8601/) of ISO 8601 |
-| Further information on calculation | metadata/calculation-information | MAY | Text | More information on your calculation methodology can be provided as freetext, or as a URL to an external document or software repository. |
-| Further information on report | metadata/report-information-url | MAY | URL | More information on your calculation methodology MAY be provided, and this MUST be a URL to an external document or software repository. |
-
-## YAML File Example
-
-### 1. Generic Example without an additional report
-File name: `25c78b6d-b049-424d-87c1-28f07e41bb23/report.yaml`
-
-```yaml
-sci:
- software-boundary: 'The software boundary of this report is limited to a single markdown file, as it is provided for example only.'
- sci: 0.5
- r: 1
- r-source: machine-learning-baseline
-metadata:
- name: Example Report
- contact-name: Responsible Point of Contact
- contact-email: report-example@greensoftware.foundation
- organization: GSF
- guid: 25c78b6d-b049-424d-87c1-28f07e41bb23
- entity-version: '0.1'
- sci-version: 1.0
- calculation-date: '2021-10-20'
- calculation-information: 'https://github.com/Green-Software-Foundation/software_carbon_intensity'
-
-```
-### 2. Generic Example with an additional report
-File name: `25c78b6d-b049-424d-87c1-28f07e41bb23/report.yaml`
-
-```yaml
-sci:
- software-boundary: 'The software boundary of this report is limited to a single markdown file, as it is provided for example only.'
- sci: 0.5
- r: 1
- r-source: machine-learning-baseline
-metadata:
- name: Example Report
- contact-name: Responsible Point of Contact
- contact-email: report-example@greensoftware.foundation
- organization: GSF
- guid: 25c78b6d-b049-424d-87c1-28f07e41bb23
- entity-version: '0.1'
- sci-version: 1.0
- calculation-date: '2021-10-20'
- calculation-information: 'https://github.com/Green-Software-Foundation/software_carbon_intensity'
- report-information-url: 'https://github.com/Green-Software-Foundation/software_carbon_intensity'
-
-```
-
-### 3. Generic Example by an individual contributor
-File name: `25c78b6d-b049-424d-87c1-28f07e41bb23/report.yaml`
-
-```yaml
-sci:
- software-boundary: 'The software boundary of this report is limited to a single markdown file, as it is provided for example only.'
- sci: 0.5
- r: 1
- r-source: machine-learning-baseline
-metadata:
- name: Example Report
- contact-name: Individual Point of Contact
- contact-email: report-example@greensoftware.foundation
- guid: 25c78b6d-b049-424d-87c1-28f07e41bb23
- entity-version: '0.1'
- sci-version: 1.0
- calculation-date: '2021-10-20'
- calculation-information: 'https://github.com/Green-Software-Foundation/software_carbon_intensity'
-
-```
\ No newline at end of file
diff --git a/Software_Carbon_Intensity/case_study_template.md b/Software_Carbon_Intensity/case_study_template.md
deleted file mode 100644
index ee48cf3..0000000
--- a/Software_Carbon_Intensity/case_study_template.md
+++ /dev/null
@@ -1,90 +0,0 @@
-# Case Study Template
-
-*This is a template to use for case studies that are submitted to apply the SCI. *
-
-*Please delete the text in italics and replace it with the appropriate information.*
-
-*For more information on any of the items, the final reference is the [SCI Specification](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md)*
-
-*If you find errors, or have further questions, please feel free to engage with us in the [discussions](https://github.com/Green-Software-Foundation/software_carbon_intensity/discussions) section.*
-
-## Overview
-
-_Please provide information describing the use case in a few bullet points_
-
-## Architecture for the system under consideration
-
-_An architecture diagram of the system described in this use case_
-
-### Technical details of the components in the architecture
-
-_Textual description with technical details of each component provided in the architecture diagram_
-
-## Sites for Software Sustainability Actions
-
-_For each of the following sub-sections, indicate **where** and **how** actions can be taken in the following categories_:
-
-### Energy Efficiency
-
-1. _site of action_
-2. _description of the action_
-
-### Hardware Efficiency
-
-1. _site of action_
-2. _description of the action_
-
-### Carbon Awareness
-
-1. _site of action_
-2. _description of the action_
-
-## Procedure
-
-### (What) Software boundary
-
-_Describe the components that are included in the software systems, if any major components are not included then please provide **reasons for exclusion**_.
-
-For example:
-- Front end mobile application
-- Network traffic between client mobile applications and servers
-- Network traffic between servers and database
-- Back-end servers.
-- Databases
-- Test infrastructure
-
-### (Scale) Functional unit
-
-_Describe the [functional unit](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#functional-unit-r) that best controls the scaling of the software system.
-
-The choice of functional unit applies to all components in your software boundary.
-
-For example:
-- per API Call
-- per User
-_
-
-### (How) Quantification method
-
-_For each software component in your software boundary, decide whether you are going to **measure** using real-world data or **calculate** an estimate via models, provide a reason and any useful details for each choice.
-
-For example:
-- Front-end mobile application.
- - Calculate an estimate using a model that represents a single user using the application.
- - We do not have the right to export real-world measurements from individuals mobiles.
-
-- Back-end servers
- - Calculate an estimate of the energy consumption using models which take as input the CPU utilization of servers.
- - Calculate an estimate of the embodied carbon using the Treads low-resolution models based on AWS data.
-
-_Also, describe the reason for your choice_
-
-### (Quantify) SCI Value Calculation
-
-_Show your work! For each of the component of your software system, show how you arrived at the SCI value._
-
-_Guidance for this is available in the [Methodology summary](https://github.com/Green-Software-Foundation/software_carbon_intensity/blob/main/Software_Carbon_Intensity/Software_Carbon_Intensity_Specification.md#methodology-summary) section._
-
-### (Report)
-
-_Disclose the software boundary and your calculation methodology, including items that you might not have included in the previous sections_
\ No newline at end of file
diff --git a/Software_Carbon_Intensity/images/GSF_logo.png b/Software_Carbon_Intensity/images/GSF_logo.png
deleted file mode 100644
index e7cf4cc..0000000
Binary files a/Software_Carbon_Intensity/images/GSF_logo.png and /dev/null differ
diff --git a/Software_Carbon_Intensity/images/Green Software Foundation Reference Guide_Manual.png b/Software_Carbon_Intensity/images/Green Software Foundation Reference Guide_Manual.png
deleted file mode 100644
index 1c9e602..0000000
Binary files a/Software_Carbon_Intensity/images/Green Software Foundation Reference Guide_Manual.png and /dev/null differ
diff --git a/Software_Carbon_Intensity/images/readme.md b/Software_Carbon_Intensity/images/readme.md
deleted file mode 100644
index 55f985c..0000000
--- a/Software_Carbon_Intensity/images/readme.md
+++ /dev/null
@@ -1 +0,0 @@
-place holder
diff --git a/Software_Carbon_Intensity/index.yaml b/Software_Carbon_Intensity/index.yaml
deleted file mode 100644
index 954672d..0000000
--- a/Software_Carbon_Intensity/index.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: "Software Carbon Intensity Specification"
-status: "Draft"
-version: "v.Alpha"
-organisationName: "Green Software Foundation"
-date: "2021-11-11"
-copyrightDate: "2021"
-logo: "images/GSF_logo.png"
-documentName: "Software_Carbon_Intensity_Specification-v.Alpha"
-files:
- - License.md
- - Software_Carbon_Intensity_Specification.md
- - Appendix_A.md
----
diff --git a/assets/css/styles.css b/assets/css/styles.css
new file mode 100644
index 0000000..a17cd62
--- /dev/null
+++ b/assets/css/styles.css
@@ -0,0 +1,1174 @@
+/*
+! tailwindcss v3.3.3 | MIT License | https://tailwindcss.com
+*/
+
+/*
+1. Prevent padding and border from affecting element width. (https://github.com/mozdevs/cssremedy/issues/4)
+2. Allow adding a border to an element by just adding a border-width. (https://github.com/tailwindcss/tailwindcss/pull/116)
+*/
+
+*,
+::before,
+::after {
+ box-sizing: border-box;
+ /* 1 */
+ border-width: 0;
+ /* 2 */
+ border-style: solid;
+ /* 2 */
+ border-color: #e5e7eb;
+ /* 2 */
+}
+
+::before,
+::after {
+ --tw-content: '';
+}
+
+/*
+1. Use a consistent sensible line-height in all browsers.
+2. Prevent adjustments of font size after orientation changes in iOS.
+3. Use a more readable tab size.
+4. Use the user's configured `sans` font-family by default.
+5. Use the user's configured `sans` font-feature-settings by default.
+6. Use the user's configured `sans` font-variation-settings by default.
+*/
+
+html {
+ line-height: 1.5;
+ /* 1 */
+ -webkit-text-size-adjust: 100%;
+ /* 2 */
+ -moz-tab-size: 4;
+ /* 3 */
+ -o-tab-size: 4;
+ tab-size: 4;
+ /* 3 */
+ font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
+ /* 4 */
+ font-feature-settings: normal;
+ /* 5 */
+ font-variation-settings: normal;
+ /* 6 */
+}
+
+/*
+1. Remove the margin in all browsers.
+2. Inherit line-height from `html` so users can set them as a class directly on the `html` element.
+*/
+
+body {
+ margin: 0;
+ /* 1 */
+ line-height: inherit;
+ /* 2 */
+}
+
+/*
+1. Add the correct height in Firefox.
+2. Correct the inheritance of border color in Firefox. (https://bugzilla.mozilla.org/show_bug.cgi?id=190655)
+3. Ensure horizontal rules are visible by default.
+*/
+
+hr {
+ height: 0;
+ /* 1 */
+ color: inherit;
+ /* 2 */
+ border-top-width: 1px;
+ /* 3 */
+}
+
+/*
+Add the correct text decoration in Chrome, Edge, and Safari.
+*/
+
+abbr:where([title]) {
+ -webkit-text-decoration: underline dotted;
+ text-decoration: underline dotted;
+}
+
+/*
+Remove the default font size and weight for headings.
+*/
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6 {
+ font-size: inherit;
+ font-weight: inherit;
+}
+
+/*
+Reset links to optimize for opt-in styling instead of opt-out.
+*/
+
+a {
+ color: inherit;
+ text-decoration: inherit;
+}
+
+/*
+Add the correct font weight in Edge and Safari.
+*/
+
+b,
+strong {
+ font-weight: bolder;
+}
+
+/*
+1. Use the user's configured `mono` font family by default.
+2. Correct the odd `em` font sizing in all browsers.
+*/
+
+code,
+kbd,
+samp,
+pre {
+ font-family: ui-monospace, SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace;
+ /* 1 */
+ font-size: 1em;
+ /* 2 */
+}
+
+/*
+Add the correct font size in all browsers.
+*/
+
+small {
+ font-size: 80%;
+}
+
+/*
+Prevent `sub` and `sup` elements from affecting the line height in all browsers.
+*/
+
+sub,
+sup {
+ font-size: 75%;
+ line-height: 0;
+ position: relative;
+ vertical-align: baseline;
+}
+
+sub {
+ bottom: -0.25em;
+}
+
+sup {
+ top: -0.5em;
+}
+
+/*
+1. Remove text indentation from table contents in Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=999088, https://bugs.webkit.org/show_bug.cgi?id=201297)
+2. Correct table border color inheritance in all Chrome and Safari. (https://bugs.chromium.org/p/chromium/issues/detail?id=935729, https://bugs.webkit.org/show_bug.cgi?id=195016)
+3. Remove gaps between table borders by default.
+*/
+
+table {
+ text-indent: 0;
+ /* 1 */
+ border-color: inherit;
+ /* 2 */
+ border-collapse: collapse;
+ /* 3 */
+}
+
+/*
+1. Change the font styles in all browsers.
+2. Remove the margin in Firefox and Safari.
+3. Remove default padding in all browsers.
+*/
+
+button,
+input,
+optgroup,
+select,
+textarea {
+ font-family: inherit;
+ /* 1 */
+ font-feature-settings: inherit;
+ /* 1 */
+ font-variation-settings: inherit;
+ /* 1 */
+ font-size: 100%;
+ /* 1 */
+ font-weight: inherit;
+ /* 1 */
+ line-height: inherit;
+ /* 1 */
+ color: inherit;
+ /* 1 */
+ margin: 0;
+ /* 2 */
+ padding: 0;
+ /* 3 */
+}
+
+/*
+Remove the inheritance of text transform in Edge and Firefox.
+*/
+
+button,
+select {
+ text-transform: none;
+}
+
+/*
+1. Correct the inability to style clickable types in iOS and Safari.
+2. Remove default button styles.
+*/
+
+button,
+[type='button'],
+[type='reset'],
+[type='submit'] {
+ -webkit-appearance: button;
+ /* 1 */
+ background-color: transparent;
+ /* 2 */
+ background-image: none;
+ /* 2 */
+}
+
+/*
+Use the modern Firefox focus style for all focusable elements.
+*/
+
+:-moz-focusring {
+ outline: auto;
+}
+
+/*
+Remove the additional `:invalid` styles in Firefox. (https://github.com/mozilla/gecko-dev/blob/2f9eacd9d3d995c937b4251a5557d95d494c9be1/layout/style/res/forms.css#L728-L737)
+*/
+
+:-moz-ui-invalid {
+ box-shadow: none;
+}
+
+/*
+Add the correct vertical alignment in Chrome and Firefox.
+*/
+
+progress {
+ vertical-align: baseline;
+}
+
+/*
+Correct the cursor style of increment and decrement buttons in Safari.
+*/
+
+::-webkit-inner-spin-button,
+::-webkit-outer-spin-button {
+ height: auto;
+}
+
+/*
+1. Correct the odd appearance in Chrome and Safari.
+2. Correct the outline style in Safari.
+*/
+
+[type='search'] {
+ -webkit-appearance: textfield;
+ /* 1 */
+ outline-offset: -2px;
+ /* 2 */
+}
+
+/*
+Remove the inner padding in Chrome and Safari on macOS.
+*/
+
+::-webkit-search-decoration {
+ -webkit-appearance: none;
+}
+
+/*
+1. Correct the inability to style clickable types in iOS and Safari.
+2. Change font properties to `inherit` in Safari.
+*/
+
+::-webkit-file-upload-button {
+ -webkit-appearance: button;
+ /* 1 */
+ font: inherit;
+ /* 2 */
+}
+
+/*
+Add the correct display in Chrome and Safari.
+*/
+
+summary {
+ display: list-item;
+}
+
+/*
+Removes the default spacing and border for appropriate elements.
+*/
+
+blockquote,
+dl,
+dd,
+h1,
+h2,
+h3,
+h4,
+h5,
+h6,
+hr,
+figure,
+p,
+pre {
+ margin: 0;
+}
+
+fieldset {
+ margin: 0;
+ padding: 0;
+}
+
+legend {
+ padding: 0;
+}
+
+ol,
+ul,
+menu {
+ list-style: none;
+ margin: 0;
+ padding: 0;
+}
+
+/*
+Reset default styling for dialogs.
+*/
+
+dialog {
+ padding: 0;
+}
+
+/*
+Prevent resizing textareas horizontally by default.
+*/
+
+textarea {
+ resize: vertical;
+}
+
+/*
+1. Reset the default placeholder opacity in Firefox. (https://github.com/tailwindlabs/tailwindcss/issues/3300)
+2. Set the default placeholder color to the user's configured gray 400 color.
+*/
+
+input::-moz-placeholder, textarea::-moz-placeholder {
+ opacity: 1;
+ /* 1 */
+ color: #9ca3af;
+ /* 2 */
+}
+
+input::placeholder,
+textarea::placeholder {
+ opacity: 1;
+ /* 1 */
+ color: #9ca3af;
+ /* 2 */
+}
+
+/*
+Set the default cursor for buttons.
+*/
+
+button,
+[role="button"] {
+ cursor: pointer;
+}
+
+/*
+Make sure disabled buttons don't get the pointer cursor.
+*/
+
+:disabled {
+ cursor: default;
+}
+
+/*
+1. Make replaced elements `display: block` by default. (https://github.com/mozdevs/cssremedy/issues/14)
+2. Add `vertical-align: middle` to align replaced elements more sensibly by default. (https://github.com/jensimmons/cssremedy/issues/14#issuecomment-634934210)
+ This can trigger a poorly considered lint error in some tools but is included by design.
+*/
+
+img,
+svg,
+video,
+canvas,
+audio,
+iframe,
+embed,
+object {
+ display: block;
+ /* 1 */
+ vertical-align: middle;
+ /* 2 */
+}
+
+/*
+Constrain images and videos to the parent width and preserve their intrinsic aspect ratio. (https://github.com/mozdevs/cssremedy/issues/14)
+*/
+
+img,
+video {
+ max-width: 100%;
+ height: auto;
+}
+
+/* Make elements with the HTML hidden attribute stay hidden by default */
+
+[hidden] {
+ display: none;
+}
+
+*, ::before, ::after {
+ --tw-border-spacing-x: 0;
+ --tw-border-spacing-y: 0;
+ --tw-translate-x: 0;
+ --tw-translate-y: 0;
+ --tw-rotate: 0;
+ --tw-skew-x: 0;
+ --tw-skew-y: 0;
+ --tw-scale-x: 1;
+ --tw-scale-y: 1;
+ --tw-pan-x: ;
+ --tw-pan-y: ;
+ --tw-pinch-zoom: ;
+ --tw-scroll-snap-strictness: proximity;
+ --tw-gradient-from-position: ;
+ --tw-gradient-via-position: ;
+ --tw-gradient-to-position: ;
+ --tw-ordinal: ;
+ --tw-slashed-zero: ;
+ --tw-numeric-figure: ;
+ --tw-numeric-spacing: ;
+ --tw-numeric-fraction: ;
+ --tw-ring-inset: ;
+ --tw-ring-offset-width: 0px;
+ --tw-ring-offset-color: #fff;
+ --tw-ring-color: rgb(59 130 246 / 0.5);
+ --tw-ring-offset-shadow: 0 0 #0000;
+ --tw-ring-shadow: 0 0 #0000;
+ --tw-shadow: 0 0 #0000;
+ --tw-shadow-colored: 0 0 #0000;
+ --tw-blur: ;
+ --tw-brightness: ;
+ --tw-contrast: ;
+ --tw-grayscale: ;
+ --tw-hue-rotate: ;
+ --tw-invert: ;
+ --tw-saturate: ;
+ --tw-sepia: ;
+ --tw-drop-shadow: ;
+ --tw-backdrop-blur: ;
+ --tw-backdrop-brightness: ;
+ --tw-backdrop-contrast: ;
+ --tw-backdrop-grayscale: ;
+ --tw-backdrop-hue-rotate: ;
+ --tw-backdrop-invert: ;
+ --tw-backdrop-opacity: ;
+ --tw-backdrop-saturate: ;
+ --tw-backdrop-sepia: ;
+}
+
+::backdrop {
+ --tw-border-spacing-x: 0;
+ --tw-border-spacing-y: 0;
+ --tw-translate-x: 0;
+ --tw-translate-y: 0;
+ --tw-rotate: 0;
+ --tw-skew-x: 0;
+ --tw-skew-y: 0;
+ --tw-scale-x: 1;
+ --tw-scale-y: 1;
+ --tw-pan-x: ;
+ --tw-pan-y: ;
+ --tw-pinch-zoom: ;
+ --tw-scroll-snap-strictness: proximity;
+ --tw-gradient-from-position: ;
+ --tw-gradient-via-position: ;
+ --tw-gradient-to-position: ;
+ --tw-ordinal: ;
+ --tw-slashed-zero: ;
+ --tw-numeric-figure: ;
+ --tw-numeric-spacing: ;
+ --tw-numeric-fraction: ;
+ --tw-ring-inset: ;
+ --tw-ring-offset-width: 0px;
+ --tw-ring-offset-color: #fff;
+ --tw-ring-color: rgb(59 130 246 / 0.5);
+ --tw-ring-offset-shadow: 0 0 #0000;
+ --tw-ring-shadow: 0 0 #0000;
+ --tw-shadow: 0 0 #0000;
+ --tw-shadow-colored: 0 0 #0000;
+ --tw-blur: ;
+ --tw-brightness: ;
+ --tw-contrast: ;
+ --tw-grayscale: ;
+ --tw-hue-rotate: ;
+ --tw-invert: ;
+ --tw-saturate: ;
+ --tw-sepia: ;
+ --tw-drop-shadow: ;
+ --tw-backdrop-blur: ;
+ --tw-backdrop-brightness: ;
+ --tw-backdrop-contrast: ;
+ --tw-backdrop-grayscale: ;
+ --tw-backdrop-hue-rotate: ;
+ --tw-backdrop-invert: ;
+ --tw-backdrop-opacity: ;
+ --tw-backdrop-saturate: ;
+ --tw-backdrop-sepia: ;
+}
+
+.prose {
+ color: var(--tw-prose-body);
+ max-width: 65ch;
+}
+
+.prose :where(p):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 1.25em;
+ margin-bottom: 1.25em;
+}
+
+.prose :where([class~="lead"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-lead);
+ font-size: 1.25em;
+ line-height: 1.6;
+ margin-top: 1.2em;
+ margin-bottom: 1.2em;
+}
+
+.prose :where(a):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-links);
+ text-decoration: underline;
+ font-weight: 500;
+}
+
+.prose :where(strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-bold);
+ font-weight: 600;
+}
+
+.prose :where(a strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(blockquote strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(thead th strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(ol):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: decimal;
+ margin-top: 1.25em;
+ margin-bottom: 1.25em;
+ padding-left: 1.625em;
+}
+
+.prose :where(ol[type="A"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: upper-alpha;
+}
+
+.prose :where(ol[type="a"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: lower-alpha;
+}
+
+.prose :where(ol[type="A" s]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: upper-alpha;
+}
+
+.prose :where(ol[type="a" s]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: lower-alpha;
+}
+
+.prose :where(ol[type="I"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: upper-roman;
+}
+
+.prose :where(ol[type="i"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: lower-roman;
+}
+
+.prose :where(ol[type="I" s]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: upper-roman;
+}
+
+.prose :where(ol[type="i" s]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: lower-roman;
+}
+
+.prose :where(ol[type="1"]):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: decimal;
+}
+
+.prose :where(ul):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ list-style-type: disc;
+ margin-top: 1.25em;
+ margin-bottom: 1.25em;
+ padding-left: 1.625em;
+}
+
+.prose :where(ol > li):not(:where([class~="not-prose"],[class~="not-prose"] *))::marker {
+ font-weight: 400;
+ color: var(--tw-prose-counters);
+}
+
+.prose :where(ul > li):not(:where([class~="not-prose"],[class~="not-prose"] *))::marker {
+ color: var(--tw-prose-bullets);
+}
+
+.prose :where(dt):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 600;
+ margin-top: 1.25em;
+}
+
+.prose :where(hr):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ border-color: var(--tw-prose-hr);
+ border-top-width: 1px;
+ margin-top: 3em;
+ margin-bottom: 3em;
+}
+
+.prose :where(blockquote):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 500;
+ font-style: italic;
+ color: var(--tw-prose-quotes);
+ border-left-width: 0.25rem;
+ border-left-color: var(--tw-prose-quote-borders);
+ quotes: "\201C""\201D""\2018""\2019";
+ margin-top: 1.6em;
+ margin-bottom: 1.6em;
+ padding-left: 1em;
+}
+
+.prose :where(blockquote p:first-of-type):not(:where([class~="not-prose"],[class~="not-prose"] *))::before {
+ content: open-quote;
+}
+
+.prose :where(blockquote p:last-of-type):not(:where([class~="not-prose"],[class~="not-prose"] *))::after {
+ content: close-quote;
+}
+
+.prose :where(h1):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 800;
+ font-size: 2.25em;
+ margin-top: 0;
+ margin-bottom: 0.8888889em;
+ line-height: 1.1111111;
+}
+
+.prose :where(h1 strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 900;
+ color: inherit;
+}
+
+.prose :where(h2):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 700;
+ font-size: 1.5em;
+ margin-top: 2em;
+ margin-bottom: 1em;
+ line-height: 1.3333333;
+}
+
+.prose :where(h2 strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 800;
+ color: inherit;
+}
+
+.prose :where(h3):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 600;
+ font-size: 1.25em;
+ margin-top: 1.6em;
+ margin-bottom: 0.6em;
+ line-height: 1.6;
+}
+
+.prose :where(h3 strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 700;
+ color: inherit;
+}
+
+.prose :where(h4):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 600;
+ margin-top: 1.5em;
+ margin-bottom: 0.5em;
+ line-height: 1.5;
+}
+
+.prose :where(h4 strong):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 700;
+ color: inherit;
+}
+
+.prose :where(img):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 2em;
+ margin-bottom: 2em;
+}
+
+.prose :where(picture):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ display: block;
+ margin-top: 2em;
+ margin-bottom: 2em;
+}
+
+.prose :where(kbd):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ font-weight: 500;
+ font-family: inherit;
+ color: var(--tw-prose-kbd);
+ box-shadow: 0 0 0 1px rgb(var(--tw-prose-kbd-shadows) / 10%), 0 3px 0 rgb(var(--tw-prose-kbd-shadows) / 10%);
+ font-size: 0.875em;
+ border-radius: 0.3125rem;
+ padding-top: 0.1875em;
+ padding-right: 0.375em;
+ padding-bottom: 0.1875em;
+ padding-left: 0.375em;
+}
+
+.prose :where(code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-code);
+ font-weight: 600;
+ font-size: 0.875em;
+}
+
+.prose :where(code):not(:where([class~="not-prose"],[class~="not-prose"] *))::before {
+ content: "`";
+}
+
+.prose :where(code):not(:where([class~="not-prose"],[class~="not-prose"] *))::after {
+ content: "`";
+}
+
+.prose :where(a code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(h1 code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(h2 code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+ font-size: 0.875em;
+}
+
+.prose :where(h3 code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+ font-size: 0.9em;
+}
+
+.prose :where(h4 code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(blockquote code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(thead th code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: inherit;
+}
+
+.prose :where(pre):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-pre-code);
+ background-color: var(--tw-prose-pre-bg);
+ overflow-x: auto;
+ font-weight: 400;
+ font-size: 0.875em;
+ line-height: 1.7142857;
+ margin-top: 1.7142857em;
+ margin-bottom: 1.7142857em;
+ border-radius: 0.375rem;
+ padding-top: 0.8571429em;
+ padding-right: 1.1428571em;
+ padding-bottom: 0.8571429em;
+ padding-left: 1.1428571em;
+}
+
+.prose :where(pre code):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ background-color: transparent;
+ border-width: 0;
+ border-radius: 0;
+ padding: 0;
+ font-weight: inherit;
+ color: inherit;
+ font-size: inherit;
+ font-family: inherit;
+ line-height: inherit;
+}
+
+.prose :where(pre code):not(:where([class~="not-prose"],[class~="not-prose"] *))::before {
+ content: none;
+}
+
+.prose :where(pre code):not(:where([class~="not-prose"],[class~="not-prose"] *))::after {
+ content: none;
+}
+
+.prose :where(table):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ width: 100%;
+ table-layout: auto;
+ text-align: left;
+ margin-top: 2em;
+ margin-bottom: 2em;
+ font-size: 0.875em;
+ line-height: 1.7142857;
+}
+
+.prose :where(thead):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ border-bottom-width: 1px;
+ border-bottom-color: var(--tw-prose-th-borders);
+}
+
+.prose :where(thead th):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-headings);
+ font-weight: 600;
+ vertical-align: bottom;
+ padding-right: 0.5714286em;
+ padding-bottom: 0.5714286em;
+ padding-left: 0.5714286em;
+}
+
+.prose :where(tbody tr):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ border-bottom-width: 1px;
+ border-bottom-color: var(--tw-prose-td-borders);
+}
+
+.prose :where(tbody tr:last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ border-bottom-width: 0;
+}
+
+.prose :where(tbody td):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ vertical-align: baseline;
+}
+
+.prose :where(tfoot):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ border-top-width: 1px;
+ border-top-color: var(--tw-prose-th-borders);
+}
+
+.prose :where(tfoot td):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ vertical-align: top;
+}
+
+.prose :where(figure > *):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+.prose :where(figcaption):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ color: var(--tw-prose-captions);
+ font-size: 0.875em;
+ line-height: 1.4285714;
+ margin-top: 0.8571429em;
+}
+
+.prose {
+ --tw-prose-body: #374151;
+ --tw-prose-headings: #111827;
+ --tw-prose-lead: #4b5563;
+ --tw-prose-links: #111827;
+ --tw-prose-bold: #111827;
+ --tw-prose-counters: #6b7280;
+ --tw-prose-bullets: #d1d5db;
+ --tw-prose-hr: #e5e7eb;
+ --tw-prose-quotes: #111827;
+ --tw-prose-quote-borders: #e5e7eb;
+ --tw-prose-captions: #6b7280;
+ --tw-prose-kbd: #111827;
+ --tw-prose-kbd-shadows: 17 24 39;
+ --tw-prose-code: #111827;
+ --tw-prose-pre-code: #e5e7eb;
+ --tw-prose-pre-bg: #1f2937;
+ --tw-prose-th-borders: #d1d5db;
+ --tw-prose-td-borders: #e5e7eb;
+ --tw-prose-invert-body: #d1d5db;
+ --tw-prose-invert-headings: #fff;
+ --tw-prose-invert-lead: #9ca3af;
+ --tw-prose-invert-links: #fff;
+ --tw-prose-invert-bold: #fff;
+ --tw-prose-invert-counters: #9ca3af;
+ --tw-prose-invert-bullets: #4b5563;
+ --tw-prose-invert-hr: #374151;
+ --tw-prose-invert-quotes: #f3f4f6;
+ --tw-prose-invert-quote-borders: #374151;
+ --tw-prose-invert-captions: #9ca3af;
+ --tw-prose-invert-kbd: #fff;
+ --tw-prose-invert-kbd-shadows: 255 255 255;
+ --tw-prose-invert-code: #fff;
+ --tw-prose-invert-pre-code: #d1d5db;
+ --tw-prose-invert-pre-bg: rgb(0 0 0 / 50%);
+ --tw-prose-invert-th-borders: #4b5563;
+ --tw-prose-invert-td-borders: #374151;
+ font-size: 1rem;
+ line-height: 1.75;
+}
+
+.prose :where(picture > img):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+.prose :where(video):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 2em;
+ margin-bottom: 2em;
+}
+
+.prose :where(li):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0.5em;
+ margin-bottom: 0.5em;
+}
+
+.prose :where(ol > li):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-left: 0.375em;
+}
+
+.prose :where(ul > li):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-left: 0.375em;
+}
+
+.prose :where(.prose > ul > li p):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+}
+
+.prose :where(.prose > ul > li > *:first-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 1.25em;
+}
+
+.prose :where(.prose > ul > li > *:last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-bottom: 1.25em;
+}
+
+.prose :where(.prose > ol > li > *:first-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 1.25em;
+}
+
+.prose :where(.prose > ol > li > *:last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-bottom: 1.25em;
+}
+
+.prose :where(ul ul, ul ol, ol ul, ol ol):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+}
+
+.prose :where(dl):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 1.25em;
+ margin-bottom: 1.25em;
+}
+
+.prose :where(dd):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0.5em;
+ padding-left: 1.625em;
+}
+
+.prose :where(hr + *):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+}
+
+.prose :where(h2 + *):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+}
+
+.prose :where(h3 + *):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+}
+
+.prose :where(h4 + *):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+}
+
+.prose :where(thead th:first-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-left: 0;
+}
+
+.prose :where(thead th:last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-right: 0;
+}
+
+.prose :where(tbody td, tfoot td):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-top: 0.5714286em;
+ padding-right: 0.5714286em;
+ padding-bottom: 0.5714286em;
+ padding-left: 0.5714286em;
+}
+
+.prose :where(tbody td:first-child, tfoot td:first-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-left: 0;
+}
+
+.prose :where(tbody td:last-child, tfoot td:last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ padding-right: 0;
+}
+
+.prose :where(figure):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 2em;
+ margin-bottom: 2em;
+}
+
+.prose :where(.prose > :first-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-top: 0;
+}
+
+.prose :where(.prose > :last-child):not(:where([class~="not-prose"],[class~="not-prose"] *)) {
+ margin-bottom: 0;
+}
+
+.absolute {
+ position: absolute;
+}
+
+.relative {
+ position: relative;
+}
+
+.left-0 {
+ left: 0px;
+}
+
+.top-2 {
+ top: 0.5rem;
+}
+
+.mx-auto {
+ margin-left: auto;
+ margin-right: auto;
+}
+
+.my-16 {
+ margin-top: 4rem;
+ margin-bottom: 4rem;
+}
+
+.my-8 {
+ margin-top: 2rem;
+ margin-bottom: 2rem;
+}
+
+.-ml-5 {
+ margin-left: -1.25rem;
+}
+
+.mb-2 {
+ margin-bottom: 0.5rem;
+}
+
+.mb-5 {
+ margin-bottom: 1.25rem;
+}
+
+.grid {
+ display: grid;
+}
+
+.hidden {
+ display: none;
+}
+
+.h-12 {
+ height: 3rem;
+}
+
+.h-4 {
+ height: 1rem;
+}
+
+.w-4 {
+ width: 1rem;
+}
+
+.w-auto {
+ width: auto;
+}
+
+.max-w-4xl {
+ max-width: 56rem;
+}
+
+.border-l-4 {
+ border-left-width: 4px;
+}
+
+.border-l-accent-default {
+ --tw-border-opacity: 1;
+ border-left-color: rgb(174 204 83 / var(--tw-border-opacity));
+}
+
+.bg-accent-lighter {
+ --tw-bg-opacity: 1;
+ background-color: rgb(235 242 212 / var(--tw-bg-opacity));
+}
+
+.bg-accent-lightest-1 {
+ --tw-bg-opacity: 1;
+ background-color: rgb(251 252 246 / var(--tw-bg-opacity));
+}
+
+.p-4 {
+ padding: 1rem;
+}
+
+.px-8 {
+ padding-left: 2rem;
+ padding-right: 2rem;
+}
+
+.pr-5 {
+ padding-right: 1.25rem;
+}
+
+.text-center {
+ text-align: center;
+}
+
+.text-sm {
+ font-size: 0.875rem;
+ line-height: 1.25rem;
+}
+
+.font-bold {
+ font-weight: 700;
+}
+
+.text-primary-dark {
+ --tw-text-opacity: 1;
+ color: rgb(0 82 79 / var(--tw-text-opacity));
+}
+
+.underline {
+ text-decoration-line: underline;
+}
+
+.no-underline {
+ text-decoration-line: none;
+}
+
+.hover\:underline:hover {
+ text-decoration-line: underline;
+}
+
+.group:hover .group-hover\:block {
+ display: block;
+}
\ No newline at end of file
diff --git a/assets/favicon.svg b/assets/favicon.svg
new file mode 100644
index 0000000..627c41a
--- /dev/null
+++ b/assets/favicon.svg
@@ -0,0 +1,7 @@
+
diff --git a/assets/js/compile.js b/assets/js/compile.js
new file mode 100644
index 0000000..c96b3da
--- /dev/null
+++ b/assets/js/compile.js
@@ -0,0 +1,99 @@
+const marked = require("marked");
+const fs = require("fs");
+const matter = require('gray-matter');
+
+// Read your Markdown content from a file or provide it as a string.
+const markdownContent = fs.readFileSync("SPEC.md", "utf8");
+
+// Create a custom renderer with your HTML template.
+const customRenderer = new marked.Renderer();
+
+// Get frontmatter from markdown
+const { data:frontmatter } = matter(markdownContent);
+
+// Remove the front matter from the markdown content.
+const markdownContentWithoutFrontmatter = markdownContent.replace(/^---[\s\S]*?---/, "");
+
+// Add an 'id' attribute to headings with the heading text as the 'id' value.
+customRenderer.heading = function (text, level) {
+ const id = text.toLowerCase().replace(/[^\w]+/g, "-");
+ return `
+ Version ${frontmatter.version} of the Software Carbon Intensity (SCI) specification by the Standards Working Group in the Green Software Foundation. The SCI technical specification describes how to calculate the carbon intensity of a software application. It describes the methodology of calculating the total carbon emissions and the selection criteria to turn the total into a rate that can be used to achieve real-world, physical emissions reductions. To see the latest version, raise an issue or ask a question visit the GitHub repository. +
++ Version 1.0.0 of the Software Carbon Intensity (SCI) specification by the Standards Working Group in the Green Software Foundation. The SCI technical specification describes how to calculate the carbon intensity of a software application. It describes the methodology of calculating the total carbon emissions and the selection criteria to turn the total into a rate that can be used to achieve real-world, physical emissions reductions. To see the latest version, raise an issue or ask a question visit the GitHub repository. +
+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:
+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.
+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: +- ISO Online browsing platform: available at https://www.iso.org/obp +- IEC Electropedia: available at http://www.electropedia.org/
+T.1
action
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.
+T.2
carbon-aware
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 – Region-specific 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
+T.3
+carbon
Greenhouse gases are a group of gases contributing to global warming. In this specification we use 'carbon' as a broad term to refer to the impact of all types of emissions and activities on global warming.
All actions that serve to reduce the carbon emissions of a piece of software fit into one of the following categories:
+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:
+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
Where:
+C
the software causes to be emitted.R
(e.g., carbon emissions per additional user, API-call, or ML training run).This can be expanded to:
+SCI = (O + M) per R
To calculate the operational emissions associated with software, multiply the electricity consumption of the hardware the software is running on by the region-specific carbon intensity.
+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:
+Units: this shall be in kilowatt hours (kWh).
+The energy consumption should include all energy consumed by hardware reserved or provisioned, not just the hardware actually used to meet the software needs.
+The carbon intensity of electricity is a measure of how much carbon (CO2eq) emissions are produced per kilowatt-hour (kWh) of electricity consumed.
+Region-specific carbon intensity factors measure the grid carbon intensity of electricity in a grid region. If the electricity consumption is connected to a grid, the short run marginal, long run marginal, or average emissions grid intensity 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.
+Units: this shall be in grams of carbon per kilowatt hours (gCO2eq/kWh).
+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
Where:
+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)
Where:
+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).
+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.
+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:
+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.
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:
+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.
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.
+As this specification develops, the following core characteristics shall remain true:
+The SCI is sensitive to carbon awareness, energy efficiency, and hardware efficiency
+The SCI takes a systems-impact view
+The SCI is easy to implement
To achieve impact at scale, the SCI encourages adoption through ease of implementation.
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 are financial instruments designed to neutralize or offset carbon emissions. Market-based measures include, but are not limited to the following:
+The following documents are useful references for implementers and users of this document:
+[1] The Net-Zero STANDARD, Science Based Targets initiative (SBTi), https://sciencebasedtargets.org/net-zero
+