Template V2 target format change

[MichaelTiemannOSC]

Since the start, we have imagined targets data as stating a base year (starting point of a data series), a start year (publication date of the target), an end date (the date by which the target reduction should be achieved), and a base year quantity, which is the starting data amount that will be reduced by the target reduction amount.

The OECM Production-Centric benchmark complicates this, because it folds sector-specific S3 data into S1 metrics (which directly or indirectly also affects S1+S2 metrics). The stipulation that Company X has, in year Y, S1+S2 base emissions of 1.2 Mt CO2e and S3 base emissions of 3.6 Mt CO2e means we must show that for year Y, it actually has emissions of 4.8 Mt CO2e, because that is the production-centric amount. Imagine that it has an initial intensity expressed in S1+S2 terms, also in year Y, of 1 Mt/GWh, with a goal of reducing that 50% to 0.5 Mt CO2e/GWh in 2030.

Question 1: Do we likely believe that Company X has already done the production-centric math to create a production-centric number? Almost certainly not.

If we want to create a production-centric intensity number, we need to add the production intensity of S3 into S1+S2, which would be 3.6/1.2 = 3 Mt/GWh, for a total production-centric S1+S2 intensity of 4 Mt/GWh, and a production-centric intensity goal of 2 Mt/GWh.

Question 2: Should we drop the concept of storing base year data in the target sheet and instead ensure that we have base year data (which can be production-centric-corrected or not, depending on user or ITR tool choices)? The V2 template makes this easy (and the V1 template makes it annoyingly difficult).

For quality and robustness purposes, we ideally want to have only a single source of truth for any number. By eliminating base year data from the target template and holding it only in the esg data page, we have a single source of truth (whose truth value can be consistently converted to production-centric when required). Otherwise, we need to perform production-centric conversions on all the target data separately, and ensure the completeness and consistency of those operations with conversions applied to the general disclosure data.

Question 3: Should we convert target specifications that mention S3 objectives into production-centric terms, doing all our projection math in production-centric terms, or should we attempt to maintain everything within their separate scopes and only do the production-centric conversion at the very end, when we report data?

Presently we do a mix of both approaches, which leads to inconsistencies that are causing unit tests (rightly) to fail.

Another way to frame Question 3: should we require that sectors using production-centric benchmarks present only S1+S2 data (in esg and targets), flagging as an error any S3 data in that context? Or should we accept S3-related data and targets, project accordingly, and simply fold S3 projections into S1 projections when computing final temperature scores and constructing the final amended portfolio? In the latter case, the tool will not report S1+S2+S3 statistics as such, but only S1+S2 as a production-centric number.

Please comment with your thoughts @LeylaJavadova @ImkeHorten @BertKramer

[BertKramer]

Hi Michael, I agree with moving base year data from the target sheet to the data sheet. Extending the limited S1+2 target to a production-centric version in the way you suggest in the lines between Q1 and Q2 intuitively makes sense, but it is actually not that straightforward. The span of control companies have over the different scopes is different, and therefore also how easy they can reduce their emissions per scope. So even though a company might have set a S1+S2 reduction target, non-published underlying reduction targets might be quite different between S1 and S2, and extending to include S3 is nontrivial. Let’s elaborate further on this early next year. Bert From: Michael Tiemann ***@***.***> Sent: zaterdag 17 december 2022 21:16 To: os-climate/ITR ***@***.***> Cc: Bert Kramer ***@***.***>; Mention ***@***.***> Subject: [os-climate/ITR] Template V2 target format change (Issue #173) Since the start, we have imagined targets data as stating a base year (starting point of a data series), a start year (publication date of the target), an end date (the date by which the target reduction should be achieved), and a base year quantity, which is the starting data amount that will be reduced by the target reduction amount. The OECM Production-Centric benchmark complicates this, because it folds sector-specific S3 data into S1 metrics (which directly or indirectly also affects S1+S2 metrics). The stipulation that Company X has, in year Y, S1+S2 base emissions of 1.2 Mt CO2e and S3 base emissions of 3.6 Mt CO2e means we must show that for year Y, it actually has emissions of 4.8 Mt CO2e, because that is the production-centric amount. Imagine that it has an initial intensity expressed in S1+S2 terms, also in year Y, of 1 Mt/GWh, with a goal of reducing that 50% to 0.5 Mt CO2e/GWh in 2030. Question 1: Do we likely believe that Company X has already done the production-centric math to create a production-centric number? Almost certainly not. If we want to create a production-centric intensity number, we need to add the production intensity of S3 into S1+S2, which would be 3.6/1.2 = 3 Mt/GWh, for a total production-centric S1+S2 intensity of 4 Mt/GWh, and a production-centric intensity goal of 2 Mt/GWh. Question 2: Should we drop the concept of storing base year data in the target sheet and instead ensure that we have base year data (which can be production-centric-corrected or not, depending on user or ITR tool choices)? The V2 template makes this easy (and the V1 template makes it annoyingly difficult). For quality and robustness purposes, we ideally want to have only a single source of truth for any number. By eliminating base year data from the target template and holding it only in the esg data page, we have a single source of truth (whose truth value can be consistently converted to production-centric when required). Otherwise, we need to perform production-centric conversions on all the target data separately, and ensure the completeness and consistency of those operations with conversions applied to the general disclosure data. As it stands, the conversion of esg disclosure data and non-conversion of target data creates a gaping inconsistency. Please comment with your thoughts @LeylaJavadova<https://github.com/LeylaJavadova> @ImkeHorten<https://github.com/ImkeHorten> @BertKramer<https://github.com/BertKramer> — Reply to this email directly, view it on GitHub<#173>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUWPCCOGLCS566C4J5E3EE3WNYNQNANCNFSM6AAAAAATCDWDWQ>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>