Project and baseline scope
Project scope
Project developers must define the scope of the project, i.e. the mitigation activities that are under consideration for RCC issuance. The scope specifies the geographic, temporal (i.e. project start date), site, and operation limits of the project. Only activities that are additional shall be considered in the project scope.
The project start date is when the mitigation activity within the project scope first begins. This date shall fall within three years of the , unless the project was previously registered under a different standard/program.
The crediting period is the duration of project mitigation activities that are eligible for credit issuance under the Rainbow Standard. The maximum duration of the crediting period shall be defined by the methodology. Upon reaching the maximum duration, a project's crediting period may be renewed, according to the Crediting Period Renewal procedure.
If the project is already registered with Rainbow as of the project start date, the crediting period start date shall start when the mitigation activities begin.
If the project is already underway upon registration with Rainbow, the crediting period may start up to 18 months prior to its registration date with Rainbow.
Baseline scope
General baseline setting requirements
Baselines shall be set according to the following principles.
Realistic: The baseline shall include the likely, appropriate, technically-plausible scenario and/or product that is substituted by the project mitigation activity.
For projects that manufacture a product, and claim RCCs from their product's substitution of a baseline product, Project Developers shall prove that their product has similar performance metrics to the baseline product and delivers equivalent functions. Project Developers shall identify and quantify performance metrics to compare between the baseline and the project scenario.
Defensible: The method for setting the baseline shall be backed up by proof.
Conservative: The baseline shall be set in a conservative way that does not lead to overestimating project benefits and overissuing RCCs. In cases of uncertainty, the modeling approach, assumptions, and data sources for the baseline scenario should adopt conservative estimates.
Transparent: The baseline, the method for setting baselines, and/or their underlying assumptions shall be transparently described, with proof and justification, in the methodology and PDD. The choice of the baseline scenario is approved by the Rainbow team, and audited by the third-party VVB in the validation audit and the ongoing verification audits.
Consistent: The quantification approach for the baseline scenario shall be comparable to the project scenario. Methodologies shall establish baseline scenarios, or baselining setting methodologies, that ensure consistent results across similar circumstances.
Approach to setting the baseline
Methodologies shall provide specific instructions for setting baselines, including defining whether an activity-specific or a standardized baseline shall be used.
A standardized baseline may be defined in a methodology if the BAU conditions are highly certain and unchanging between project contexts.
If this is not possible due to lacking data or heterogeneous conditions, an activity-specific baseline based on the operator’s individual performance shall be used.
Methodologies may outline a mixed approach based on the:
geography of the project: standardized baselines may be defined for only specific geographies, and activity-specific baselines used elsewhere
component of the baseline: e.g. the emission factor of a product in the baseline may be standardized at the methodology level, but the amount of the product substituted by the project is activity-specific.
Where a standardized baseline cannot be identified, an activity-specific baseline may be set according to:
Best available technology (BAT): the practice or technology that results in the lowest baseline emissions or highest baseline removals and is also a reasonable substitute, meaning it is economically and technically feasible, and geographically available.
Historical or current market conditions: if the project mitigation activity replaces specific, known products or practices, that were used before the project implementation and could continue to be used, the baseline may be set as the specific replaced product or practice.
The selected baseline scenario shall be highly representative of the standard performance of comparable practices and processes in similar social, economic, environmental, technological and regulatory circumstances. It shall take into account the geographical context, including local environmental and market conditions.
The degree of conservativeness in this choice shall be based on the level of the overall uncertainty, taking into account the choice of assumptions, models, parameters, data sources, measurements methods and other factors (e.g., assuming a better-performing baseline in case of higher uncertainties).
The choice of a baseline shall account for any regulatory conditions that support a given baseline technology or scenario. Any government policies and legal requirements that lower baseline emissions shall be explicitly considered and accounted for in the establishment of the baseline scenario (e.g. feed-in tariffs for renewable energy, minimum product efficiency standards, carbon taxes...). If a technology or practice is required by regulations, and these regulations are enforced, then this shall be reflected in the baseline (see also the Additionality section). This ensures that the project is only credited for emission reductions and removals that are additional to what would have occurred anyway.
The choice of a baseline scenario shall address any rebound effects. Any direct, quantifiable rebound effects shall be explicitly included in the GHG quantification.
If the project activity is multifunctional, the baseline scenario shall cover all functions of the project, and different approaches to baseline setting may be used for the different project activities.
When the average market solution is represented by a market mix of solutions, the market mix shall include the portion of the project mitigation activity that is already used in the market.
Updating the baseline
Standardized baselines shall be updated in the methodology at a minimum every 5 years. Activity-specific baselines shall be updated for a given project at a minimum frequency of each crediting period renewal.
The chosen baseline for a project may be revised more frequently due to changing baseline conditions, such as regulatory or market changes.
A project's updated baseline shall be audited by the VVB upon the next verification.
Last updated