Question re: location-based marginal emissions

[abeggchr]

The specification regarding location-based marginal carbon emissions states:

_Location-based measures the grid carbon intensity of a regional balancing authority. From a developer perspective, only the location-based info is important for having an impact on reducing carbon emissions. This excludes market-based measures, and is distinct from 100% renewable energy claims.

The only figure that matters if you’re trying to optimize the scheduling of your compute in real-time is the marginal emissions intensity. This is the emissions intensity of the marginal power plant which will be turned up if you schedule some compute (e.g. increase electricity demand from the grid) at that moment._

Questions:

• What's the difference between a "marked-based measure" and "location-based measures"?
• To calculate the SCI, only the carbon emissions in the electricy net where the server is operated is relevant (i.e. 29g in Sweden when writing this issue according to https://app.electricitymap.org/zone/SE)?
• Now when Microsoft claims to operate a 100% renewable energy datacenter (https://azure.microsoft.com/en-us/blog/achieving-100-percent-renewable-energy-with-247-monitoring-in-microsoft-sweden/) - is this a "marked-based measure" or can the factor 0 be used for the location-based marginal carbon emissions?

[atg-abhishek]

Adam: lot of contextual measures in the SCI, so not sure yet on how to incorporate this / if it should be incorporated
Srini: MBM includes neutralizations and offsets,
Adam: we don't want to give specific guidance because that is going to be contextual
Henry: the intent to exclude market-based measures was also that we want to be consequential and make sure that we focus on things that the developer can control / if you change your software, would it reduce the carbon?
Tammy: if you run your app on the DC that is buying renewable energy / market-based

[Henry-WattTime]

As the SCI is currently drafted, market based measures like EACs, RECs, offsets, PPAs, etc are excluded from the calculation. The specification attempts to assess the emissions caused by running that software, making the marginal emissions rate in that region relevant. SCI promotes creating energy efficient applications, targeted for practitioners, hence market-based strategies are excluded at this point. In the Microsoft example, you should use the regional emissions factor, not zero.

This may be a topic if conversation in future versions of the spec.

[atg-abhishek]

Adam: what guidance can we give to people who are looking to pick a vendor?

[atg-abhishek]

Henry: we should have a guide for choosing a vendor

[jawache]

Anything where we say give your money to X instead of Y should be avoided for now. It's something that's come up many times and is planned to be explored in the Policy Working Group. A "Green Product/Service Certification". But it's something we'll carefully explore as there are lots of thorny issues here and as such we should make sure we are covered from a legal standpoint.

We can I think safely for now provide what we think the attributes of a good vendor are vs. a bad vendor and leave it to the user to make their own decisions.

[atg-abhishek]

Agreed @jawache - that's what I had in mind as well re: providing attributes that a procurement officer can use to make a decision on who would be a good/bad vendor. Maybe something that can be included in the guidelines / FAQ / appendix section of the SCI or do you envision it as a separate entity?