Small scale self-consumed solar methodology, by PeerCo

[Pierre-VF]

PeerCo is herewith submitting its first methodology for approval.
This methodology was developed by @mollywebbtech , @trimblee and myself.

This is the first methodology submission by a 3rd party, so we are uncertain about the exact format, content and level of detail required. We are therefore very open to discussing the content, carrying out adjustments and upgrades, and looking forward to input from the community.

[mattwc-openeac]

Since the method is meant to be general, we could say that the data needs to be made available to multiple via a certain format but not declare where it should be stored.

[Pierre-VF]

Here's where we had some uncertainty about how much the approach consists in disclosing one's own methodology (i.e. with the details of one's context) versus making it generic for anyone to use.
We therefore chose the first approach (also made further visible by the use of a "PeerCo" folder), which implied that we'd specify PeerCo's cloud. I can however see that your vision differs on this, which makes it worth bringing this up in the Steering Committee

[mollywebbtech]

Agree that we should discuss in the steering group meeting.

[mattwc-openeac]

We can add the EIA for the US

[nicholasburgess-eac]

I'm not sure we should be specifying particular data sources. Think we should just define the requirements these data sources need to meet.

[Pierre-VF]

I agree that this would make the method easier to scale to new countries without amending.

I proposed an update of this in a new commit.

@mattwc-openeac - happy to add the EIA if you provide me the link to that dataset.

[mollywebbtech]

agree

[mattwc-openeac]

Propose adding in a time period, i.e. over a trailing week or month period.

[Pierre-VF]

Agreed. I'm adding a "per calendar month" in a new commit.

[mattwc-openeac]

Thank you, Pierre!

[nicholasburgess-eac]

Is CCS an appropriate Sectoral Scope for solar self consumption? Is this referencing a particular/well known methodology for scope?

[mollywebbtech]

This was from a sectoral scope linked to the carbon market / clean development mechanism methodologies we based this on. We can remove sectoral scope if it isn't relevant or remove CCS specifically

[Pierre-VF]

CCS is now removed (revision here) - for the general relevance of the sectoral scope, there is a bigger question whether we want to have it in all methodologies or whether it is not regarded as a relevant element by the alliance.

[nicholasburgess-eac]

Let's discuss when development attribution should be stated. My thought is that it makes sense for this early stage where we should have a central champion to answer questions, but eventually we want these to be generic/coming from the EAC Alliance

[nicholasburgess-eac]

Sample for once we get there:

"This methodology was developed by the Technical Committee on Solar Consumption, under the jurisdiction of the Strategic Steering Committee, and has been formally approved by the Technical Committee.

If needed This methodology has been developed in compliance with XYZ (Level 10, Green-e etc.) requirements."

[mollywebbtech]

In the voluntary carbon markets, the people who develop the methodology are paid a small licensing fee of some kind to recover costs of developing the methodology in the first place. In this model, the group that develops and approves this would be compensated. Does the initiating company get some form of 'lead author' or 'initiating company' designation so that any questions can go back to us specifically. Some of the people in the technical committee might be representing their personal views, whereas PeerCo is initiating this as a company. There needs to be a clear distinction or understanding. One to be discussed in the steering committee.

[nicholasburgess-eac]

Think we should state explicitly that the purpose is to generate an Environmental Attribute Certificate representing the environmental attributes of the specific generation and consumption (such as location and time) of on-site solar energy.

[Pierre-VF]

Agreed. This is addressed in a new version here

[nicholasburgess-eac]

Can we define demand side here? Also point in time, aka hourly?
"Average kilowatt-hour consumed" in a grid subregion? In a balancing region?

[Pierre-VF]

Addressed here.
We deliberately kept flexibility for the zone definition as this fundamentally depends on the geography and the data (e.g. emission intensity data) available. However, I added a requirement to disclose this choice at EAC level.

[nicholasburgess-eac]

Open to discussion, but why does the data need to be communicated automatically by digital means? Could imagine a solar system which stores hourly data but is read manually each month

[mollywebbtech]

Agreed we should be able to have a way to not have full technical integration if this becomes a huge cost/barrier. Verification would therefore need to be robust enough to not allow 'gaming' of the spreadsheet that is read manually.

[Pierre-VF]

Agreed, automatic data communication can be a barrier which we don't want to have. 'Gaming' is in practice as much of a concern for automatic communication as it is with spreadsheet (unless a trusted 3rd party API is used - e.g. with large established inverter manufacturers where the extra context provides extra robustness).

I've addressed this here and here, where I also added a requirement on metering of the site demand and export (so we're sure to not include the exported fraction in our EACs)

[nicholasburgess-eac]

Smart. Maybe require both? Also, we should state that the address must be complete, and maybe we should put the onus on the asset owner to report the grid and grid subregion e.g. Zone J NYISO

[Pierre-VF]

It's easy to retrieve one from the other using an API, so for user practical/convenience reasons we're sticking to one mandatory here.
Regarding the disclosure, I wouldn't put that burden on the asset owner, as (1) not all of these might have that kind of fluency, (2) the choice also depends on the carbon intensity data available for the zone, (3) the zone details might change over time (e.g. geographical granularity becomes better) while we wouldn't want to have to update an agreement with the user if this changes (as the elements disclosed in this list are likely to be part of a written contract with an asset owner, it's good to stay minimal)

[nicholasburgess-eac]

Interesting, why is this? Also, we should state that that these arrays are not installed on more than 10% of all buildings "during the hours when carbon credits are generated" or similar

[mollywebbtech]

Again, in the carbon markets there is a goal of not investing in things that are already 'mainstream' but for these Energy Attribute Certificates there are other goals for the certificates (like hourly matching) which means we should remove this.

[Pierre-VF]

The methodology has now been made EAC specific (so these carbon credit-related requirements are removed) - see changes here

[nicholasburgess-eac]

I'm not sure we should be specifying particular data sources. Think we should just define the requirements these data sources need to meet.

[ssuffian]

It'd be great to include some guidance on some proposed methods around filling those gaps!

[mollywebbtech]

There will be different methods depending on how the gaps appear. How detailed should this methodology get in defined the acceptable methods or is this up to the verification party?

[Pierre-VF]

My thought at this stage further to Stephen's input was to propose a few options in appendix. I just haven't written them in there yet. What is clear to me is that we need to restrict to 'explainable' methods (i.e. blackbox AI is a no-go) for accountability reasons.

@ssuffian - if you guys have some specific ones already, I'm happy to reference them here too. Probably not down to code details, but a reasonably sharp method description allowing to reproduce and assess specifically enough.

[ssuffian]

We don't have anything super specific at WattCarbon yet, as our approach has been to only mint EACs for hours that we have actual data.

I imagine for solar it might be safe to do something as simple as a linear interpolation if an individual gap is no more than an hour long, and for longer gaps possibly using a previous day, same hour value, and as a last resort, some sort of solar+weather model to predict? I think it'd be important to make sure that the output data indicates whether a value was measured or computed, as that might change the end value of that EAC.

I was at the most recent meeting for the LF Energy OpenEEMeter and they had something cool but a bit more complex related to auto-correlation, it might be worth it to reach out to them: https://lfenergy.org/projects/openeemeter/ if we want to come up with a general approach.

[Pierre-VF]

Thanks @ssuffian for the input.

At this stage, given that others do not consider gap filling, that other methodologies (even OpenEEmeter has carefully avoided formalising this in their latest version so far) do not do it either, and that we want to keep the discussion focus on essential points (governance etc - rather than such technical details which can be divisive), we decided to withdraw the acceptance of missing data with a threshold.

This is reflected in this commit.

@ssuffian, we may however want to address this in a future version, once we have the big picture agreements in place and gather experience as an alliance. Happy to take the discussion again when we get there

[paulteehan]

Hello, I'm joining from Rewiring America where I'm developing an M&V methodology for heat pump and other residential electrification installs under IRA/GGRF. I've left a few comments which are related to similar issues I've been thinking about for our work. I look forward to working with you, thank you!

[paulteehan]

Have you thought about the emissions due to other life-cycle phases e.g. manufacturing, installation etc?

[Pierre-VF]

Whether these are taken into account depends on the emission intensity data. ElectricityMaps uses lifecycle data (from IPCC) so that it would take this into account if you use that specific factor of theirs. Other providers typically take a fuel-based approach (i.e. more or less scope 1), which would not account for the lifecycle.
On this level, we're therefore bound by what's available for a given geography.

Speaking of lifecycle, we would then need to also have a model of the emission intensity for the PV panels (lifecycle impact of the installation / expected MWh of production over lifetime) which adds significant complexity. At this stage, data available on most installations wouldn't allow us to accurately compute such a number - so I would not advocate for making it a mandatory requirement (however, optional might make sense, just like EnergyTag does)

[paulteehan]

It seems to me that the offset should be based on the difference between the amount of grid electricity that would have been consumed in the counterfactual no-solar-panel world, and which is not consumed because of the installation.

Is that number the same number as the total self-consumption? I think it could be, but I could also imagine a customer self-consuming more electricity than they otherwise would have without panels. You could even end up with a perverse incentive where people deliberately self-consume more and more electricity to fraudulently generate larger credits. Have you thought about checking for this?

[mollywebbtech]

We are assuming there are other incentives at play that make the maximising for self-consumption aligned with those other incentives. If they have a battery, they will also be trying to use that and discharge rather than using the grid. If they have an electric car, they may be trying to charge it. For SMEs the idea of having contextual data so that we can show their per unit energy and carbon intensity (and that it is going down) will also be possible.

[Pierre-VF]

@paulteehan - the counterfactual in this methodology is indeed assumed to be grid import for the whole value for the PV production (i.e. we assume that no demand change happens following the installation of PV - neither in amount or time of demand).

Here, we need to remember that the credits are either used in reporting or trading.

• When reporting, they wouldn't really profit from more demand, as that's a cost implying more import or less export (while no profit from EAC sale).
• For trading, the same applies (bearing in mind that the EAC value is likely going to be significantly under the kWh value for the electricity itself - so that they would actually make a loss by gaming). On top of this, entities that need to report would therefore give away the 'greenness' of that demand (as the attribute is sold) which would then result in degrading their carbon reporting further and have even less incentive to game it.

Does that make sense to you?

[paulteehan]

We discussed this in the open EAC alliance meeting today and the following points came through:

• It's not obvious if the assumption of no demand change following PV installation is valid or not.
• Because these EACs will be used as carbon offsets, any optimistic over-counting of emissions reductions will result in double-emissions so it's important to get the numbers right
• The group recognizes that the burden of evaluating counterfactuals is significant, especially if you get into the full protocol of 12 months of baseline data, max bias and error thresholds, non-routine event adjustment, etc. Some people think this analysis is necessary and some take a more pragmatic approach to getting the projects done.
• Are there studies that exist which could validate the assumption?
• Perhaps this could be an issue for residential but not commercial customers
• Perhaps customers that make material changes e.g. EV installation following installation should be excluded

[Pierre-VF]

Thanks for the summary of your subgroup's reflection yesterday. We definitely agree that counterfactual building is a difficult task where the method and outcome depend on the application case (eg. residential, industrial process, commercial,...). Without resorting to a full-scale literature review, the following demand changes can be named: demand flexibility to match local production (which in practice is a combination of PV installation and the introduction of a demand control scheme), further electrification on site (EV, heat pump, ... - where again a combination of actions is happening), increase in demand (either due to rebound effect on power cost, or production expansion for industry). While some of these are a combination of actions, where solar might have acted as a trigger, it isn't clear how and where to draw the line of the solar-specific change.

Having said that, and witnessing the agreement on the complexity of the matter, there's a question whether we could specify counterfactual models precisely enough to be transparent while covering most cases. Another question arising then is whether this would reach a methodology size, consensus level and complexity that is compatible with our review process. On this level, we would expect that the answer is far from a 'yes' within a reasonable time horizon.

This is why we propose to stand by the current counterfactual, maybe making it more explicit so that it doesn't appear to be a blind spot but rather a mindful choice. The specification of this counterfactual could be a more central/defining element of this methodology (eg by also adjusting the title to signal this), so that it'd be clear and transparent to users and EAC buyers. For applications where counterfactual building can be specified and agreed upon more easily, we should promote the creation of new versions as opportunities arise.

From a tradeable instrument perspective (rather than carbon credit), it is also worth bearing in mind that the counterfactual might need to be thought of differently and more from a market based approach. Specifically here, what the EACs represent is the solar power that was used on a site (rather than importing) which is transacted with another party as a way to 'swap' their import of power with the solar production on the other site. Adopting this perspective does raise much fewer questions as to the validity of the current counterfactual.

However, this is more of an EAC discussion than an M&V one.

Please let us know what your thoughts are on the above.

[paulteehan]

Hi @Pierre-VF , I'm happy to give my personal perspective on this approach, with the caveat that I'm not sure what happens when I do - do we have to reach a kind of consensus in order to move the method forward, or is it more that you might take my comments under advisement? I might make a critique in the interests of maximizing rigour, but I wouldn't necessarily want to be an obstacle, and I'm just a practitioner with a perspective which is as valid as anyone else's here. Perhaps a question for someone from WattCarbon (@ssuffian ?)

My opinion is that if you have factors in your equation that are uncertain or unknown, such as rebound effects, additional electrification, etc, then you need to model these as accurately as you can, and issue a credit which is conservatively on the low end of your range to account for the unknowns. (This also holds for life cycle impacts mentioned above.) I don't think that measurement complexity or difficulty in obtaining good numbers are reasons to conclude that factors can be ignored completely or assumed to be zero. Rather these are arguments that an accurate calculation cannot be made at all, and therefore we should not be issuing credits at all. I do agree with the point about tradeable instruments; I would hold offsets or credits to a far higher methodological standard since they are associated with actual physical emissions and if the numbers are found to be overly optimistic that could undermine the integrity of the market and the goal of decarbonization itself.

If this was my project, my next step would be to try to get hold of some pre/post data for a sample of customers and see if I could measure the change in demand and determine whether increased self-consumption perfectly matches decreased demand, and if it's off, by how much. Or, perhaps find some reasonably proxies in the literature. Then I would include that error in my equations so that I'm reporting a pessimistic number.

[paulteehan]

That's an interesting strategy, can you say what percentage of income is re-invested and how you chose that number?

Do you see a possibility of free-riders in your programs and is this investment meant to balance against those?

[mollywebbtech]

We were initially addressing this for carbon market audiences and because we are now purely looking at EACs, the point made here is more for the carbon markets and we should potentially remove this. We don't see people 'free riding' but we want to - as much as possible - prove an ongoing journey of electrification and decarbonisation which means we would like to see them build on their investments. One solar provider did want to offer this kind of proof of reinvestment and another wanted to use the proceeds to invest in more metering. but this is likely to be on a case by case basis.

[eliotcrowe]

Comment for OpenEAC committee rather than on this specific method: should there be a central library of acronyms & glossary, to avoid a future situation where we are seeing the same terms used with different definitions?

[mollywebbtech]

good idea

[Pierre-VF]

In principle, that's a good idea. However, for validation purposes given that methodologies with a given version are considered normative, there would be a need to always synchronise a given methodology version with the corresponding glossary/acronym list etc.
The current approach where methodologies are self-contained allows us to circumvent that complexity.

[eliotcrowe]

Add kWp and MWp to the acronym table?

[Pierre-VF]

We had considered it obvious in our context, but it's potentially good to remind in an international context. This is now added here

[ssuffian]

@Pierre-VF what is the reason for these sizing constraints? Is this purposely meant to exclude residential solar?

[Pierre-VF]

We're actually removing the lower bar now (we want small scale to happen - I'll update the PR). However, the upper bar is basically to explicitly exclude large-scale

[eliotcrowe]

No idea if this would be significant, or if it's just unnecessarily pedantic (!), but should "installation" be more specific? eg. it could be physically installed one day, but not fully operational until a later date. Date on which high frequency data generation commences?

[Pierre-VF]

Good point, that phrasing was not sharp enough. It is now updated (as well as a few other places for consistency) here

[eliotcrowe]

intensity data at the national level does not align with my understanding of how OpenEAC was intended to function (maybe it's me that's wrong there!). If this would be sufficient in exceptional circumstances, we need to say clearly what those are

[Pierre-VF]

As a specific example of country-wide data: France where regional data is not available today. Data granularity varies a great deal from one place to another, and we therefore need to support a variety of cases - with, of course, the principle that good local data is always better than national or worse.

More details on this in the next answer to your comment below

[eliotcrowe]

Reinforcing my earlier point - this language would allow for gaming, ie. pick local or national emissions factors based on which would earn the most $$$

[Pierre-VF]

When selling EACs, the value is first and foremost going to be about the kWh, rather than the carbon (which acts as contextual data for buyers, and might provide a premium value).
Ideally, we should indeed have very clear guidelines on this. However, it is tricky to enforce from an international perspective, as granularity hugely depends on the area (you can for example check here comparing European countries where some have national, while others have sub-regions (e.g. Norway, Italy and Sweden) and states like Florida in the US where the resolution is much higher). And the fact that different intensity sources exist for some zones (e.g. carbonintensity.org.uk and electricityMaps for UK, with different methods each) only makes this worse.

We could include that the geographical resolution "should be as high as allowed by the data source" but even this leaves an open door to gaming and update difficulties if the granularity increases in the future (expecting to see an increasing amount of detail enabled in the coming years, if the current trends continue). On the other hand, enforcement with a "must be" would only make these difficulties worse (by invalidating the certificates after time of non compliance).

At this stage, we propose to address this by greater transparency (i.e. disclosing source and resolution) rather than complex criteria whose practicality is far from clear. See the update here as well as the rest of the list of information contained in the EAC

[ssuffian]

Add an additional source for US

Suggested change

	| Great Britain | [National Grid ESO's *carbonintensity.org.uk* API](https://www.carbonintensity.org.uk/) |
	| Great Britain | [National Grid ESO's *carbonintensity.org.uk* API](https://www.carbonintensity.org.uk/) |
	| US | [EIA's Hourly Electric Grid Monitor](https://www.eia.gov/electricity/gridmonitor/) |

[Pierre-VF]

@mattwc-openeac & @ssuffian : FYI, I've now added an M&V plan template in appendix 3 following the workstream call. Let me know if you see anything requiring adjustment in there