> For the complete documentation index, see [llms.txt](https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/sections/7.1.-quantification-of-greenhouse-gas-emissions/7.2.-baseline-emissions.md). # 7.2. Baseline Emissions The baseline scenario represents the counterfactual — the emissions trajectory that would occur in the absence of the carbon-financed activity. Baselines are used to calculate the quantity of emissions reductions or removals attributable to a project and must be constructed to avoid overestimating mitigation outcomes. **Carbon credits are issued only for emission reductions or removals that are additional to and exceed the conservative baseline scenario**. Baseline approaches shall be specified at the methodology level. Project-level deviations from approved baseline approaches are only permitted through [the OCP's formal deviation process](https://open-carbon-protocol.gitbook.io/ocp-handbook/projects/project-proposal-flow#project-deviations) and require independent approval. ### Conservativeness Principle All baseline scenarios must be conservative. Where uncertainty exists in data, assumptions, models, or parameter values, the choice that produces the lower estimate of emissions reductions or removals must be selected and explicitly justified. Methodologies must document how conservativeness has been applied at each stage of baseline construction. ### Recognized Baseline Approaches Methodologies must ground baseline scenarios in one or more of the following recognized classes of approach. The selected approach must be appropriate to the activity type and context, and justified in the methodology documentation. * Historical data analysis * Modeling of counterfactual scenarios * Benchmarking * Parameter-based calculations using emission factors We do not allow 'suppressed demand' approaches to baseline scenario setting, due to the risk of overcrediting. ### Baseline Scope and Policy Alignment Baselines must be constructed to reflect the project's crediting period and remain realistic throughout that period. Baselines must account for existing government policies, legal requirements, and market conditions that would, in the absence of the project, independently reduce emissions, including, but not limited to, feed-in tariffs, minimum efficiency standards, air quality regulations, and carbon pricing mechanisms consistent with ICVCM's assessment framework requirements. ### Documentation Requirements All baseline approaches must be fully transparent and data-driven. Methodology documentation must explicitly state: * The baseline approach selected and the justification for its appropriateness to the activity type * All data sources, their provenance, and the time periods they cover * All assumptions made, with justification grounded in evidence * All parameter values used, their sources, and, where a choice was made among defensible options, the basis for selecting the most conservative value * How conservativeness has been applied across modeling, benchmarking, historical data use, and parameter selection * How the baseline accounts for applicable policies and legal requirements --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://open-carbon-protocol.gitbook.io/ocp-methodology-requirements/sections/7.1.-quantification-of-greenhouse-gas-emissions/7.2.-baseline-emissions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.