Embodied Emissions: consider making estimate of all the embodied emissions optional

[dschien]

Data on all aspects is very sparse, in particular on "Total Embodied Emissions" and "Expected Lifespan", notwithstanding the methodological ambiguity mentioned in issue #152

The potential to develop a concrete method based on this standard will be limited by this requirement.

[atg-abhishek]

Can you clarify more on what you mean by data is very sparse? The standard cannot be too prescriptive tying it down to specifics cc @jawache @Henry-WattTime

[jawache]

It's a very fair point and the lack of data has been raised by many others. In a way it is optional already, we don't specify the accuracy and we make it clear that people can use models, even very simplistic models. So you can optionally use a very low resolution model that is accurate enough OR you can invest the time and resources to measure/calculate something at a higher resolution.

E.g. take this example from Benjamin Davy, the model they propose for cloud is very very simple (see section 5.2) https://medium.com/teads-engineering/building-an-aws-ec2-carbon-emissions-dataset-3f0fd76c98ac

The hope is through the Innovation Working Group and the SCI Open Data we can make all the models people need freely available at low resolutions. That's the bet at least, we'll see if it pans out!

[davidmytton]

I would guess @dschien is referring to the fact that there is no data available for most hardware. The spec makes embodied emissions a required variable:

You MUST include an estimate of all the embodied emissions for the hardware used within your software boundary.
You MAY use simple models to estimate embodied emissions; however, you SHOULD use the most granular data possible and ideally emissions data from a devices life cycle analysis when calculating your embodied carbon.

If you're on AWS you can use the Teads model @jawache references, and Cloud Carbon Footprint is bringing that to Azure and GCP, so this would count as a simple model. And if you're running it on Apple or (some) Dell hardware you can get embodied emissions numbers, but what about everything else? Very few vendors produce LCAs to get these figures from.

So you can optionally use a very low resolution model that is accurate enough

Perhaps it would be useful to provide links to these models (that aren't AWS, GCP, Azure, Apple or Dell), or at say something like "In the absence of data, the closest equivalent e.g. a Dell server LCA, or if you're using Cloudflare Workers you could use figures from AWS Lambda?

[atg-abhishek]

This is a fair point @davidmytton, the thing that I'm wondering in terms of allowing people to compare to related pieces of hardware in absence of direct data is the threshold that we want to define for the "closeness" of the other chosen hardware. Any ideas on how we could frame that?

[davidmytton]

I'm currently working on cloud-carbon-footprint/cloud-carbon-footprint#579 which is defining coefficients for each of the three hyperscale cloud providers (AWS, GCP, Azure) based on a general proxy (a Dell server LCA). In the absence of provider specific numbers, perhaps that should be adopted as the reference dataset?

[mrchrisadams]

I'd request that this wasn't optional, and I'll outline my reasons below.

If the issue is that we don't have data, and basically every single academic paper and report says that a lack of transparency is a key barrier to meaningful action, then my fear is that saying this is optional sends the message that well, this isn't really an issue after all, and we don't need it.

If you know this is a necessary variable, and your fallback is to use an average value as David Mytton suggests, then you if you are doing better than the average, you at least have an incentive to disclose information - you would be rewarded with what amounts to 'a better score'.

If it isn't necessary, you have much less incentive to add this information, even if you are doing better than average.

In the case of something like re-using end of life hardware that may still be power efficient enough for your use case (this is a valid strategy, and there companies doing this), removing this makes it much harder to have these measures recognised. This again removes an incentive to disclose information.

Given how openness has been a key idea all through the process of creating the SCI, I feel the SCI spec would be less useful without it.

[davidmytton]

Agreed. And using an average will add further pressure because that average may be much worse than the actual. A vendor showing how the value is better than the average could be seen as a good thing.

But if it is required and there is no data, there needs to be guidance on what data to use as the fallback.

[jawache]

This is exactly what the https://greensoftware.foundation/projects/sci-open-data project has been kicked off to provide. The data required to execute the SCI.

[atg-abhishek]

I think keeping it in also serves the purpose of producing demand-side pressure and us providing one avenue for supply can help the market arrive to a state where both the data is available more widely and it is utilized in the calculation of the SCI value.

[Henry-WattTime]

Working group thoughts:
-even though data is sparse, using defaults or averages may meaningfully inform decisions
-If included will pressure/create demand for this data
-Making optional could maintain status quo and lead to organizations under report
-Comes up frequently, may make sense to include a data requirements discussion
-Benjamin Davies formula for embodied emissions is straightforward and effective to get started (but can be hard to find all components)
-in Wiki?: https://github.com/Green-Software-Foundation/software_carbon_intensity/wiki
-USGBC/LEED as a good model or a cautionary tale for clarifying requirements?
-Current plan is to retain it as a requirement
-SCI data project will help provide data
-'Error bounds' in UI? In reporting requirements?
-best and worst cases
-Underreported data will unlikely to be corrected, should overestimate, forcing organizations to report correctly
-tending to overreporting will help push.