Software system boundary requirements for comparing scores

[davidmytton]

The comparability of scores then hinges on the definition of "significantly" in:

The calculation of software carbon intensity MUST include all supporting infrastructure and systems that significantly contribute to the software operation.

If the software system boundary may include a large range of different components (monitoring, testing, training ML, etc), how can scores be compared? More guidance (or stricter system boundaries) may be necessary otherwise the comparisons become less valid.

[atg-abhishek]

That's a great point @davidmytton - any suggestions from your work that we could lean on to define significantly more concretely?

[davidmytton]

I would suggest being specific about what must be included rather than relying on the word "significant". It's too difficult to define.

The GHG Protocol says that Scope 3 should include "Purchased goods and services" and that the minimum boundary is "All upstream (cradle-to-gate) emissions of purchased goods and services". The only reason to exclude is if there are no emissions. A recent paper on this explains:

We assume categories to be relevant unless the company specifically states that emissions are non-existent. All other justification, such as unavailability of data, non-significant amounts of emissions, or the lack of evaluation are not accepted. This strict approach helps to overcome the challenge posed by the qualitative formulation of the criteria for identifying relevant scope 3 activities in the GHG Protocol. It avoids different interpretations and limits the leeway granted in favor of enhanced comparability.

[Henry-WattTime]

Working group thoughts:
-We agree that 'significant' is currently vague.
-Future versions my be more prescriptive. To start, this lets users figure it out themselves.
-May be linked to future reporting requirements. Publishing how you calculated the score.
-Use cases will help illustrate what may or may not be significant