ISO Reporting Questionnaire

[jawache]

For the self-certification reporting mechanism, we need to agree on a set of questions which people requesting certification need to answer.

There are a few pieces of the puzzle here:

• What questions do we want to ask, what is an appropriate answer to this question.
• When does this group want a submission to be flagged for discussion vs. be accepted automatically, if hit that bar too low and this group will be spending significant time reviewing submissions, set the bar too high and we risk letting things through that we shouldn't.

Here are some suggested questions based on analysis of past case studies and an examination of the SCI specification itself (it's musts and recommendations)

Mandatory Disclosure

When reporting a score, the following SHALL be disclosed:

Score:

• The score value and units
• The measurement period

Software Boundary:

• Components explicitly included
• Components explicitly excluded and rationale for exclusion
• Any assumptions made about shared infrastructure
• Allocation methods for shared resources

Functional Unit:

• The functional unit chosen
• Rationale for the choice
• How the unit is counted or measured
• Any conversion factors used (with justification)

Quantification Methodology:

• Description of the key methodologies employed (measurement, calculation, coefficients, or combination)
• Any assumptions made
• Known limitations or uncertainties
• Any material coefficients or emission factors leveraged

Recommended Disclosure

The following SHOULD be disclosed for transparency:

• Description of methodology per component, in as much detail and granularity as possible
• Detailed disclosure of all data sources used
• Scores broken down by sub-component in the software system

Baseline Comparison Reporting

When reporting a comparison to a baseline, the following SHALL be disclosed:

• The baseline score (with full disclosure as per 11.1)
• The proposed/new score (with full disclosure as per 11.1)
• The actions taken between baseline and proposed measurement
• Explanation of differences between baseline and proposed scores

Domain-Specific Reporting

Domain guidelines MAY define additional reporting requirements specific to their domain.
If a domain guideline exists and has additional reporting requirements this section SHALL contain the domain specific reporting requirements.

[jmcook1186]

Example Certification Application 1: E-commerce API Service

As requested in SSWG call, an example of a certification application which I'd anticipate would PASS.

Overview

A REST API service running on AWS EC2 in us-east-1, serving product catalog queries. We're calculating SCI per 1,000 API requests.

Software Boundary

Included:

• Application servers (2x t3.medium EC2 instances)
• Load balancer
• Database server (1x r6g.large RDS instance)
• Network traffic

Excluded:

• CDN (static assets handled separately)
• CI/CD pipeline (calculated separately for development)
• End-user devices (beyond our operational control)

Justification: We control and can measure the backend infrastructure. CDN and CI/CD are separate services with different scaling characteristics.

Functional Unit

R = 1,000 API requests

Rationale: API requests are the primary measure of application usage and scale linearly with load. Measured via application logs over a 30-day period.

Calculation Walk-through

Step 1: Energy Consumption (E)

Measurement Period: 30 days (January 2025)
Total API Requests: 45,000,000

Application Servers (2x t3.medium):

• Instance specs: 2 vCPUs, 4 GB RAM
• TDP per instance: 15W average (AWS CloudWatch metrics)
• Runtime: 720 hours (30 days)
• Energy per instance: 15W × 720h = 10.8 kWh
• Total for 2 instances: 21.6 kWh

Load Balancer:

• Estimated: 2W continuous
• Energy: 2W × 720h = 1.44 kWh

Database (r6g.large):

• Instance specs: 2 vCPUs, 16 GB RAM
• TDP: 20W average
• Runtime: 720 hours
• Energy: 20W × 720h = 14.4 kWh

Network:

• Data transferred: 900 GB
• Energy coefficient: 0.001 kWh/GB (literature-based estimate)
• Energy: 900 × 0.001 = 0.9 kWh

Total E per period: 21.6 + 1.44 + 14.4 + 0.9 = 38.34 kWh

PUE adjustment: AWS us-east-1 PUE ≈ 1.2
Adjusted E: 38.34 × 1.2 = 46.01 kWh total

E per 1,000 requests: (46.01 kWh / 45,000) × 1,000 = 1.022 kWh per 1,000 requests

Step 2: Carbon Intensity (I)

Location: us-east-1 (Virginia, USA)
Grid carbon intensity: 340 gCO2eq/kWh (EPA eGrid 2024 annual average for Virginia)

Data source: EPA eGrid, no market-based measures (RECs excluded)

Step 3: Operational Emissions (O)

O = E × I
O = 1.022 kWh × 340 gCO2eq/kWh = 347.48 gCO2eq per 1,000 requests

Step 4: Embodied Emissions (M)

Application Servers (2x t3.medium):

• Total Embodied Emissions (TE): 1,200 kg CO2eq per server (AWS Customer Carbon Footprint Tool estimate)
• Expected Lifespan (EL): 4 years = 35,040 hours
• Time Reserved (TiR): 720 hours (measurement period)
• Resources Reserved (RR): 2 vCPUs (100% allocated to our app)
• Total Resources (ToR): 2 vCPUs (dedicated instances)
• M per server = 1,200,000g × (720/35,040) × (2/2) = 24,657.5 g
• M for 2 servers: 49,315 g

Database Server (r6g.large):

• TE: 1,500 kg CO2eq (larger instance)
• EL: 4 years = 35,040 hours
• TiR: 720 hours
• RR: 2 vCPUs (100% dedicated)
• ToR: 2 vCPUs
• M = 1,500,000g × (720/35,040) × (2/2) = 30,821.9 g

Load Balancer:

• TE: 800 kg CO2eq (network appliance)
• M = 800,000g × (720/35,040) × 1 = 16,438 g

Total M per period: 49,315 + 30,821.9 + 16,438 = 96,574.9 gCO2eq

M per 1,000 requests: (96,574.9 / 45,000) × 1,000 = 2.146 gCO2eq per 1,000 requests

Step 5: Final SCI Score

SCI = (O + M) per R
SCI = (347.48 + 2.146) gCO2eq per 1,000 API requests
SCI = 349.63 gCO2eq per 1,000 API requests

Summary

Score: 349.63 gCO2eq per 1,000 API requests
Measurement Period: January 2025 (30 days)
Quantification Method: Measurement (CloudWatch metrics) + calculation (embodied emissions via AWS CCF Tool)
Key Assumptions:

• PUE 1.2 for AWS us-east-1
• 100% resource allocation (dedicated instances)
• Network energy coefficient from literature (Aslan et al. 2018)

Limitations: Network energy is estimated; actual hardware embodied emissions from AWS aggregated data

Impact Framework file

Attached optional (but recommended IMP file)
example-1-api-service.yml

[jmcook1186]

Example 2: Machine Learning Model Training Job

Scenario Overview

Training a computer vision model (ResNet-50) on Google Cloud Platform using a single GPU instance in europe-west4 (Netherlands).

Software Boundary

Included:

• GPU compute instance (n1-standard-8 + 1x NVIDIA V100)
• Storage for dataset (500 GB on persistent SSD)
• Network transfer for dataset download

Excluded:

• Data preparation pipeline (separate SCI calculation)
• Model serving infrastructure (different functional unit)
• Development environment (not part of production training)

Justification: Training is a distinct workload with clear boundaries. We measure one complete training run as the functional unit.

Functional Unit

R = 1 complete training run (to convergence)

Rationale: ML training jobs are discrete tasks with a defined start and end. Each training run produces one model version. This allows comparison across different training approaches.

Calculation Walkthrough

Step 1: Energy Consumption (E)

Measurement Period: Single training run (12 hours)

GPU Compute (NVIDIA V100):

• TDP: 300W under training load (measured via nvidia-smi)
• Runtime: 12 hours
• Energy: 300W × 12h = 3.6 kWh

CPU (8 vCPUs, n1-standard):

• TDP: 60W average (GCP documentation, 30% utilization)
• Runtime: 12 hours
• Energy: 60W × 12h = 0.72 kWh

Memory (30 GB RAM):

• Power: 10W (estimated for DDR4)
• Energy: 10W × 12h = 0.12 kWh

Storage I/O (500 GB SSD reads):

• Idle power: 5W
• Energy: 5W × 12h = 0.06 kWh

Network (dataset download - 500 GB):

• Energy: 500 GB × 0.001 kWh/GB = 0.5 kWh

Total E: 3.6 + 0.72 + 0.12 + 0.06 + 0.5 = 5.0 kWh

PUE adjustment: GCP europe-west4 PUE = 1.1 (Google data center efficiency)
Adjusted E: 5.0 × 1.1 = 5.5 kWh per training run

Step 2: Carbon Intensity (I)

Location: europe-west4 (Netherlands)
Grid carbon intensity: 420 gCO2eq/kWh (Netherlands grid 2024 average - Electricity Maps)

Data source: National grid data, location-based (no renewable energy credits applied)

Step 3: Operational Emissions (O)

O = E × I
O = 5.5 kWh × 420 gCO2eq/kWh = 2,310 gCO2eq per training run

Step 4: Embodied Emissions (M)

GPU (NVIDIA V100):

• TE: 150 kg CO2eq (from NVIDIA LCA data)
• EL: 5 years = 43,800 hours
• TiR: 12 hours
• RR: 1 GPU (100% allocated)
• ToR: 1 GPU
• M = 150,000g × (12/43,800) × 1 = 41.1 gCO2eq

Server Hardware (n1-standard-8):

• TE: 1,000 kg CO2eq
• EL: 4 years = 35,040 hours
• TiR: 12 hours
• RR: 8 vCPUs (100% allocated)
• ToR: 8 vCPUs
• M = 1,000,000g × (12/35,040) × 1 = 342.5 gCO2eq

Storage (500 GB SSD):

• TE: 160 kg CO2eq for 1 TB SSD (Dell LCA data)
• Allocated: 500 GB = 50% of capacity
• M = (160,000g × 0.5) × (12/35,040) × 1 = 27.4 gCO2eq

Total M: 41.1 + 342.5 + 27.4 = 411 gCO2eq per training run

Step 5: Final SCI Score

SCI = (O + M) per R
SCI = (2,310 + 411) gCO2eq per training run
SCI = 2,721 gCO2eq per training run
or 2.72 kgCO2eq per training run

Certification Documentation

Score: 2.72 kgCO2eq per training run
Measurement Period: Single 12-hour training job (March 2025)
Quantification Method:

• E: Direct measurement (nvidia-smi, GCP monitoring)
• M: Calculation using manufacturer LCA data

Key Assumptions:

• V100 at full TDP during training (conservative)
• Server hardware fully allocated to single training job
• Storage embodied emissions pro-rated by capacity used

Data Sources:

• GPU power: nvidia-smi telemetry
• Carbon intensity: Electricity Maps Netherlands grid data
• Embodied emissions: NVIDIA and Dell LCA reports

IMP file

example-2-ml-training-final.yml

[jmcook1186]

Example 3: Mobile Banking App (Client-Side)

Scenario Overview

A mobile banking application running on user devices (iOS and Android). We're calculating the carbon impact of the app's energy consumption on end-user devices.

Software Boundary

Included:

• Mobile app execution on user devices
• Local data storage and caching
• API calls to backend (network energy)

Excluded:

• Backend servers (calculated separately with different R)
• App Store distribution (one-time cost, not operational)
• Device manufacturing not attributable to this app

Justification: This calculation focuses on the incremental carbon cost of running our specific app. Backend has separate SCI with different functional unit (API requests).

Functional Unit

R = 1 active user per month

Rationale: Users access the app multiple times per month. This unit captures the full monthly impact per user and allows comparison with other apps or versions.

Calculation Walkthrough

Step 1: Energy Consumption (E)

Measurement Period: 30 days (February 2025)
Sample Size: 1,000 active users (instrumented devices)

Average Usage Pattern per User:

• App opens per month: 20 sessions
• Average session duration: 3 minutes
• Total active time: 60 minutes per month
• Background sync time: 120 minutes per month (overnight)

Device Split:

• 60% iPhone (estimate: iPhone 13)
• 40% Android (estimate: Samsung Galaxy S21)

Energy - iPhone Users:

• Active mode power draw: 2.5W (measured via Xcode Energy Log)
• Active energy: 2.5W × (60/60)h = 2.5 Wh = 0.0025 kWh
• Background sync power: 0.5W
• Background energy: 0.5W × (120/60)h = 1 Wh = 0.001 kWh
• Total per iPhone user: 0.0035 kWh

Energy - Android Users:

• Active mode power draw: 3.0W (measured via Android Battery Stats)
• Active energy: 3.0W × (60/60)h = 3 Wh = 0.003 kWh
• Background sync: 0.6W
• Background energy: 0.6W × (120/60)h = 1.2 Wh = 0.0012 kWh
• Total per Android user: 0.0042 kWh

Weighted Average E per User:
E = (0.60 × 0.0035) + (0.40 × 0.0042) = 0.0021 + 0.00168 = 0.00378 kWh per user-month

Network Transfer Energy:

• Data per user per month: 15 MB (API calls + sync)
• Network energy: 0.015 GB × 0.001 kWh/GB = 0.000015 kWh
• Total E: 0.00378 + 0.000015 = 0.003795 kWh per user-month

Step 2: Carbon Intensity (I)

Challenge: Users distributed globally.

Approach: Weighted average based on user distribution:

• 40% users in EU (average: 300 gCO2eq/kWh)
• 35% users in North America (average: 400 gCO2eq/kWh)
• 25% users in Asia-Pacific (average: 600 gCO2eq/kWh)

Weighted I: (0.40 × 300) + (0.35 × 400) + (0.25 × 600) = 120 + 140 + 150 = 410 gCO2eq/kWh

Data source: Regional grid averages from Electricity Maps, no market-based measures

Step 3: Operational Emissions (O)

O = E × I
O = 0.003795 kWh × 410 gCO2eq/kWh = 1.56 gCO2eq per user-month

Step 4: Embodied Emissions (M)

Challenge: We don't manufacture devices, but must allocate portion of device embodied carbon to our app.

Approach: Time-share and resource-share calculation

iPhone 13 (60% of users):

• TE: 72 kg CO2eq (Apple Environmental Report)
• EL: 3 years = 26,280 hours
• TiR per user per month: (60 + 120) minutes = 3 hours
• Resource-share: Estimated 5% of device capacity (based on profiling)
  • Our app uses ~5% of CPU cycles, 100 MB of 128 GB storage
• M per iPhone user = 72,000g × (3/26,280) × 0.05 = 4.11 gCO2eq

Samsung Galaxy S21 (40% of users):

• TE: 68 kg CO2eq (Samsung Eco-Product Report)
• EL: 3 years = 26,280 hours
• TiR: 3.2 hours (slightly longer active + background time)
• Resource-share: 6% (Android app uses slightly more resources)
• M per Android user = 68,000g × (3.2/26,280) × 0.06 = 4.97 gCO2eq

Weighted M: (0.60 × 4.11) + (0.40 × 4.97) = 2.47 + 1.99 = 4.46 gCO2eq per user-month

Step 5: Final SCI Score

SCI = (O + M) per R
SCI = (1.56 + 4.46) gCO2eq per user-month
SCI = 6.02 gCO2eq per user-month

Certification Documentation

Score: 6.02 gCO2eq per user-month
Measurement Period: February 2025 (30 days, 1,000 instrumented users)
Quantification Method:

• E: Direct measurement via device profiling tools (Xcode, Android Battery Stats)
• I: Calculation using geographic user distribution and regional grid data
• M: Calculation using manufacturer LCA data with time/resource-share allocation

Key Assumptions:

• Representative device models (iPhone 13, Galaxy S21) for user base
• 5-6% resource-share allocation based on profiling data
• 3-year device lifespan
• Geographic distribution from user analytics data

Limitations:

• Device model assumptions may not reflect full user base diversity
• Resource-share estimation is approximate (based on CPU profiling, not full hardware utilization)
• Network energy uses literature-based coefficient

Uncertainty Analysis: ±20% due to device model assumptions and resource-share estimation

IMP file

example-3-mobile-app-final.yml

---

[birtheb]

• It seems that the questionnaire covers all relevant components.
• The level of detail of the examples seems to be adequate for conformance submissions.
• An automated validation would make sure that validation can be done immediately, in a standardized way, and in an inexpensive way.
• Potential barriers: Data availability - What would be extremely helpful for organisations that want to calculate the SCI and fill in the questionnaire are literature values that can be assumed if no numbers are available. E.g., Network energy coefficient from literature (Aslan et al. 2018) that is mentioned in the first example.

[jmcook1186]

agree with your assessment, thanks. :o)

re point 2 - I also think we could automate the verification to a large degree - the checks we want to do are simple enough. However, I'd propose launching a minimal MVP with manual verification against some clear acceptance criteria and guage demand - if we see enough demand to justify developing automated verification, do it then.

re point 3 - curious to hear others' opinions on this. I do see the value in this, but we've also tended to stay agnostic about the actual methods people use, as there are a wide range of strong opinions out there and the space changes so fast, being method-agnostic gives us a degree of future-proofing. That said, I totally see how some recommendations would be very useful for users!

I'll post below here a more detailed proposal doc for discussion among the WG.

[ArneTR]

Hey All,

I stumbled over this article in my GitHub Notifications and just wanted to say: Great job on working on an SCI self service certification.

The examples are very thorough and are well readable for me as a GSF outsider who is only familiar with the SCI through select touchpoints.

What cam to my mind with the first example in particular: I would be nice to not only ask for one functional R of choice (API request in the example) but also an R that is always a fixed time frame. Rationale is that it gives a more comprehensive and also comparable picture of the chosen infrastructure emissions. Fixing this to say a 30 day window would allow to quickly see not only the performance characterisics of an implementation but also its idle characterisitics.

Hope you find my 2 cents helpful in generating your set of questions.

• Arne

[navveenb]

These are excellent set of examples. On the disclosure, do we add if Organizations are leveraging carbon aware computing for their workloads and conformance around it.

[navveenb]

@jmcook1186 to add Proposal document for review. This would be self certification hosted on a microsite.