Regrow’s Inventory Product
An inventory is the emissions (dSOC, N20 and CH4) quantified over a period of time associated with on-field emissions from growing a crop. It’s also referred to as a footprint or an emissions factor. An emissions factor (EF), specifically, is defined as the emissions during the quantified period of time per unit yield. It’s thought of as an emissions starting point or the current emissions for that period. Note, it is not a measure of the impact of a practice change along with a counterfactual (what would have happened without an intervention), learn more in the appendix section below.
Outcomes To Be Provided
Project Level
EF outcomes are generated at the project level with project-level uncertainty. Results are broken out by crop (emissions per bushel) and are inclusive of all project fields producing that crop. Project level outcomes are GHGp compliant, with calculation methodology in Appendix below.
Here is an example, in Excel format. Note that API clients will fetch results and can convert those into Excel manually if desired.
How Can You Use Project Level EFs?
Supported use cases for this product are carbon inventory accounting or corporate reporting. In these cases, companies are not quantifying carbon credits for verification + sale, but rather measure emissions more accurately in a sustainability or net-zero goal, make narrative claims, or provide EFs alongside crops they sell.
What is Considered a “Good” Emission Factor (EF)?
Negative EFs indicate net sequestration is occurring per bushel of crop produced, where positive EFs indicate net emissions are occurring per bushel of crop produced. Therefore, negative numbers are considered better than positive numbers. An EF of zero indicates net emissions are neutral, neither emitting or sequestering. However, even with positive emissions it is important to consider the degree of emissions and reduction of those emissions over time.
Some crops and geographies will often result in positive EFs even when using regenerative agriculture practices. This is why it’s best to compare program numbers against baseline or regional emissions numbers to get a better idea if your program numbers are “good” or not. However, be aware of baseline or regional emissions numbers that may be calculated differently or include different components than your project emission factors.
Field Level
Field level will be generated with no uncertainty applied.There will be two different numbers, and clients may choose which is preferred for grower conversations/payments.
First, is the % contributed to net emissions per field (and optional per gas calculation). Field percentages will sum to 100%.
Second, is the value contributed to net emissions per field (tCO2e/bushel). This is the same calculation as the percentage just represented as a value rather than percent.
Field level per gas (optional)
API clients can inform an optional parameter to TRUE which will then, and only then, calculate field level percentage contributions for all gases (dSOC, CH4, N20 direct and indirect). This is a large payload and is an unusual request, which is why this is an optional parameter.
How Can You Use Field Level?
Regrow supports field level calculations to help inform farmer payment or other incentives for participating farmers. It might be helpful for some companies to compare fields that are growing the same crop, for that specific reporting period (highest performer vs lowest performer). Or for specific incentives for fields that have been on regenerative farming and would otherwise not qualify for intervention accounting.
Regrow Does Not Support The Following Uses Of Field Level Calculations
Field level contributions cannot be used for carbon inventory accounting, corporate reporting, or SBTi target reporting
- As such Regrow will focus presentation of final outcomes at the project level only and will not conduct a full scientific assessment field by field.
- It is expected that field level will have much larger uncertainties than the project level, and likewise that type of analysis is not supported and should not be relied upon for this type of project.
Field level contributions cannot be used for sub dividing into supply sheds.
- Emissions factors with uncertainty are calculated at the project level, and likewise fields cannot be recombined into smaller or different supply sheds.
- If this is required, then those smaller supply sheds should be treated as their own project in order to satisfy the need for uncertainty.
Why Are There Limitations On Supported Use Cases At Field Level?
Regrow’s Inventory module using DNDC generates project-level values for use within carbon accounting and other downstream claims. The DNDC model relies on a large number of input variables, each of which affects the uncertainty of quantification. Small variation in inputs such as weather, crops grown, field histories can lead to differences in results. Regrow measures this uncertainty at the project level and likewise this is the only level that is supported for reporting.
Project-level uncertainty in the aggregate is generally lower than field-level due to the statistical validity of a larger dataset. Field level uncertainty is not provided for this use case. Importantly, project-level uncertainty can increase due to a smaller number of fields (< 100 fields for example) growing a particular crop within the project.
Appendix
What’s the difference in quantification methodology for ‘carbon credits’ and EFs?
Carbon credits are quantified by calculating the impact of measured emissions + removals against a ‘counterfactual’ scenario. The removals/reductions in a measured project year are compared to a ‘hypothetical’ removals/reductions generated by the counterfactual baseline (what the GHG impact would have been had there been no intervention or practice change). In this way, a credit is the delta of the real outcome and the possible outcome.
EFs are an absolute value of the emissions that happened for a given time period (and associated to the production of a single crop). While ‘credits’ are calculated by simulating two scenarios (counterfactual baseline and practice change) and finding the delta, the EF is the GHG impact of a single scenario or measured data.
Uncertainty Methodology and GHGp-Alignment
The Greenhouse Gas Protocol provides a framework for how companies can design carbon program, either for generating carbon credits or quantifying carbon inventory + accounting standards. Most of Regrow’s CPG customers who are interested in quantifying commodity EFs are following standards/precedent set by GHGp. Regrows’s EF outcomes will be calculated with an uncertainty adjustment, to ensure they are compliant with the GHGp framework.
Uncertainty will be applied to all modeled outcomes (the emissions estimates that are quantified with DNDC rather than Tier 1/2 equations), using Regrow’s unpaired uncertainty model. To calculate uncertainty, DNDC structural error is propagated to the final modeled changes to SOC, and N2O and Soil CH4 emissions changes via Monte Carlo simulation. With the unpaired uncertainty model, the Monte Carlo simulation is applied to the modeled outcomes of a single scenario (as opposed to crediting, where uncertainty is applied to the delta of two scenarios (intervention and counterfactual baseline).
The result of applying the uncertainty model to the DNDC-modeled outcomes is a distribution of probable values for each modeled emission. The distributions are summed for every field in the project, at which point the outcomes of the calculated (not modeled) emissions are added as well (for emissions of the same type, such N2O). An uncertainty-adjustment is made (for applicable GHGs) by selecting the value from the distribution at the 50% crediting percentile.
The uncertainty can be reduced by aggregating results across a range of samples as shown below. For example, in the case of a carbon project with multiple fields, the uncertainty is lower for a project with a hundred fields as compared to a project with twenty fields and much lower than the value for a single field. For this reason, we typically provide values at the project level as opposed to a single field.