PCS PS 003 Project Standard_v1.0

Document Control

Document identification

• Document code: PCS-PS-003

• Title: Project Standard

• Scope: Defines project-level requirements across the PCS project lifecycle, including eligibility, additionality, baseline rules, boundary rules, leakage, monitoring, post-registration changes, transparency, and continuous compliance obligations.

• Outcome: Provides binding requirements that all PCS projects must meet for registration and issuance, independent of sector methodology specifics.

Version history and change log

Table DC-1. Revision history

Version	Date	Status	Summary of changes	Prepared by	Approved by
V1.0	TBD	Draft	Release for public consultation	PCS	TBD

Superseded versions

No superseded versions for v1.0.

Governance note on versioning and archiving

Only the latest approved version of this Standard shall be used. Superseded versions shall be archived and retained for traceability and audit purposes. Where transition provisions apply, PCS shall specify how registered projects and ongoing crediting are treated under version changes.

ACRONYMS	MEANING / USE IN PCS
AFOLU	Agriculture, Forestry and Other Land Use
AGB	Aboveground Biomass
BGB	Belowground Biomass
BAU	Business-As-Usual
CCS	Carbon Capture and Storage
CO₂	Carbon Dioxide
CO₂e	Carbon Dioxide Equivalent
DACCS	Direct Air Carbon Capture and Storage
DEFF	Design Effect
ESMP	Environmental and Social Management Plan
FPIC	Free, Prior and Informed Consent
GHG	Greenhouse Gas
GIS	Geographic Information System
GPS	Global Positioning System
HWP	Harvested Wood Products
ICS	Improved Cookstove
IoT	Internet of Things
IPCC	Intergovernmental Panel on Climate Change
IRR	Internal Rate of Return
ISO	International Organization for Standardization
MR	Monitoring Report
MRV	Measurement, Reporting, and Verification
NBS	Nature-Based Solutions
NPV	Net Present Value
PCS	Planetary Carbon Standard
PCC	PCS Carbon Credit
PDD	Project Design Document
PMR	Project Monitoring Report
PRC	Post-Registration Change
QA/QC	Quality Assurance / Quality Control
REDD	Reducing Emissions from Deforestation and Forest Degradation
RR	Reference Region
SDG	Sustainable Development Goal
SFM	Sustainable Forest Management
SHS	Solar Home System
SOC	Soil Organic Carbon
SRS	Simple Random Sampling
UNFCCC	United Nations Framework Convention on Climate Change
VVB	Validation and Verification Body
Z-Score	Statistical Standard Score

Chapter 1 - Introduction

1.1 Purpose of the Standard

1. This Project Standard establishes the fundamental rules, criteria, and procedural requirements governing the design, implementation, and continual management of mitigation activities seeking registration under the Planetary Carbon Standard (PCS). It provides the foundational framework upon which all PCS methodologies, safeguards, sustainable development provisions, monitoring systems, and assurance procedures are applied.

2. The Standard ensures that every project entering the PCS project cycle adheres to consistent principles of environmental integrity, transparency, and operational robustness. Its provisions serve as the minimum threshold for PCS project eligibility and lay the groundwork for subsequent validation, verification, monitoring, issuance, and post-registration review processes.

3. This Standard does not replace PCS methodologies, the PCS Sustainability & SDG Integrity Standard, the PCS Validation & Verification Standard, or the PCS Double Counting Standard; instead, it defines the universal requirements that all project types must satisfy regardless of sector, technology, or activity structure.

1.2 Objectives

1. The objectives of this Standard are to:

• ensure that all mitigation activities are designed and implemented in a manner that allows for transparent, reproducible, and verifiable quantification of emission reductions and removals;

• establish project-level requirements that support consistent application of PCS methodologies across diverse geographies and technologies;

• ensure alignment between project design and PCS safeguards, SDG contributions, monitoring rules, and Host Party laws;

• provide a structured basis for the evaluation of project eligibility, baseline conditions, additionality, leakage, monitoring systems, and project boundaries;

• facilitate the generation of high-integrity PCS carbon credits (PCCs) supported by verified evidence and public transparency; and

• support ongoing project governance, including post-registration changes, revalidation, and long-term monitoring.

1.3 Modular Structure of the PCS Project Standard

1. This Standard follows a modular structure, allowing for a clear separation between:

• core requirements that apply to all PCS projects,

• specialized or technical requirements contained in annexes, and

• project-specific rules established in individual PCS methodologies.

1. The modular design ensures that PCS can respond effectively to new mitigation technologies, emerging best practices, and varying sectoral requirements without repeatedly amending the core Standard. It also improves clarity for Project Proponents, VVBs, and Host Parties by distinguishing between binding universal provisions and technical guidelines applicable to specific project types.

2. The modular structure comprises:

• Core Chapters (1–9): Mandatory requirements applicable to all PCS projects.

• Modular Annexes: Detailed rules for additionality, baselines, leakage, sector-specific frameworks, and digital monitoring requirements.

• Methodology Modules: Technical quantification rules that differ by activity type.

1. Compliance with the core Standard is mandatory for all PCS projects. Compliance with modular annexes is mandatory when applicable. Methodology modules are binding for each project type.

1.4 Relationship With Other PCS Standards and Procedures

1. The PCS Project Standard shall be applied together with:

2. PCS-STD-001: Avoidance of Double Counting – ensuring exclusive mitigation outcome claims and registry integrity.

3. PCS-STD-003: Sustainability & SDG Integrity Standard – defining safeguard obligations and SDG contribution requirements.

4. PCS-STD-004: Validation & Verification Standard – specifying assurance processes and VVB requirements.

5. PCS Methodologies – defining project-specific quantification, monitoring, and baseline frameworks.

6. PCS Registry & Digital Infrastructure Protocol – establishing rules for transparency, document submission, and blockchain anchoring.

7. PCS Post-Registration Change Procedures – governing material and non-material project changes.

8. Where conflicts arise, the principle of highest environmental and social integrity applies. The PCS Secretariat retains the authority to interpret requirements and issue clarifications.

1.5 Applicability

1. This Standard applies to all mitigation activities seeking registration under PCS, including new projects, grouped activities, programmatic structures, and activities transitioning from other standards into PCS. It applies equally throughout the project cycle, including initial registration, monitoring, verification, issuance, and renewal of crediting periods.

2. All obligations contained in this Standard are binding unless explicitly indicated as guidance or contained within an informative annex.

1.6 Principles Underpinning the PCS Project Standard

1. The Standard is guided by the following foundational principles:

2. Environmental Integrity: Projects must generate genuine, quantifiable, and verifiable emission reductions or removals that would not have occurred without the project.

3. Transparency: Project information relevant to environmental and social integrity must be publicly accessible through the PCS Registry.

4. Conservativeness: Uncertainty must be addressed using conservative approaches to avoid overestimation of emission reductions or removals.

5. Consistency: Project documentation, monitoring, and reporting must align with PCS methodologies and validation/verification procedures.

6. Traceability: All data used in baseline and monitoring calculations must be traceable to original sources, with audit trails preserved through digital and blockchain-anchored systems where applicable.

7. Inclusiveness and Safeguard Protection: Projects must identify, assess, and mitigate social and environmental risks and engage affected stakeholders in accordance with PCS safeguards.

8. Host Party Compatibility: Where relevant, projects must comply with applicable domestic laws and policies and may (optionally) provide documentation relevant to Host Party reporting or authorization processes.

1.7 Role of the PCS Secretariat

1. The PCS Secretariat oversees the implementation and enforcement of this Standard. Its responsibilities include:

• reviewing project documentation submitted at registration;

• issuing decisions on project eligibility and registration;

• ensuring consistent application of this Standard across all VVBs;

• conducting quality assurance, oversight activities, and spot checks;

• maintaining the PCS Registry as the authoritative system of record.

1. The Secretariat may issue clarifications, updates, or procedural notes where necessary to preserve consistency and integrity.

1.8 Continuous Improvement and Versioning

1. PCS maintains a process of continuous improvement. The PCS Secretariat may update this Standard periodically to incorporate:

• developments in mitigation methodologies;

• updates to international climate frameworks;

• technological advances (including digital MRV tools);

• improved safeguard or SDG performance expectations;

• adjustments required to maintain environmental and social integrity.

1. Projects shall apply the version of this Standard in effect at the time of registration unless the Secretariat mandates transition to an updated version for reasons of integrity.

1.9 Structure of the Project Standard

1. The PCS Project Standard is organized into:

• Chapter 1–9: Core mandatory requirements

• Annexes A–G: Modular technical requirements

• Separate Methodology Modules: Specific to mitigation activity types

1. This structure provides clarity, reduces redundancy across documents, and allows PCS to scale efficiently across sectors and regions.

Chapter 2 - Project Eligibility

2.1 General Eligibility Requirements

1. All mitigation activities seeking registration under the Planetary Carbon Standard (PCS) shall comply with the eligibility requirements established in this chapter.

2. Eligibility refers to the suitability of a project to participate in the PCS crediting framework, considering the project’s characteristics, compliance with methodology requirements, alignment with Host Party regulations, and adherence to PCS safeguards and sustainable development provisions.

3. Eligibility is determined at registration and remains subject to continuous compliance throughout the crediting period.

4. A project shall be deemed eligible only if it is designed and implemented in a manner that enables accurate, transparent, traceable, and verifiable quantification of emission reductions or removals.

2.2 Applicability of PCS Methodologies

1. Projects must apply an approved PCS methodology relevant to their activity type. A project is eligible only if:

• the activity type is expressly covered by an approved PCS methodology;

• the methodology’s applicability conditions are satisfied in full;

• any exclusions defined in the methodology do not apply to the project; and

• the baseline and monitoring approaches are feasible in the project’s context.

1. Where no methodology exists for a given mitigation activity, the project may not be registered until a suitable methodology is approved.

2.3 Legal and Regulatory Compliance

1. Projects must comply with all applicable laws, regulations, and permitting requirements of the Host Party, including but not limited to:

• environmental permits;

• land-use or land-tenure laws;

• labor and occupational health regulations;

• sector-specific licensing requirements;

• national climate or energy policies;

• Indigenous rights, customary rights, and protection frameworks.

1. Legal compliance must be demonstrated through documentation submitted during registration, and maintained throughout the project’s lifetime. Evidence shall be sufficient to enable independent verification.

2. PCS shall not register projects that operate unlawfully, violate human rights, or conflict with protected or sensitive areas where mitigation measures cannot ensure safeguard compliance.

2.4 Project Proponent Eligibility

1. The Project Proponent must:

• have demonstrable authority to implement the project;

• demonstrate legal ownership or contractual rights to emission reductions/removals;

• provide documentation confirming corporate identity or legal registration;

• disclose any partnerships, joint ventures, or implementing partners;

• disclose potential conflicts of interest relevant to the project.

1. The Project Proponent shall be responsible for all documentation submitted under the PCS project cycle.

2.5 Additionality Requirement

1. Projects must demonstrate additionality in accordance with the applicable PCS methodology and Annex A of this Standard. Additionality ensures that emission reductions or removals are not the result of business-as-usual conditions.

2. A project is eligible only if:

• it is not legally required;

• it is not financially or operationally common practice in the region;

• barriers (financial, technological, or institutional) exist that the project overcomes; or

• an investment or regulatory surplus demonstration has been satisfied.

1. Additionality must be demonstrated using recognized tools and must remain valid at validation. Material shifts affecting additionality must be disclosed and reassessed where required.

2.6 Project Types Eligible Under PCS

1. Eligible project categories include, but are not limited to:

• renewable energy generation and energy access;

• energy efficiency improvements;

• avoidance or reduction of industrial or process emissions;

• waste treatment, methane recovery, and circular economy activities;

• agriculture, forestry, and other land-use activities (AFOLU/NBS);

• carbon capture, utilization, and storage (CCS);

• bioenergy with carbon capture and storage (BECCS);

• direct air carbon capture and storage (DACCS);

• cookstove, water purification, and household-level technologies;

• urban mobility, transport efficiency, and public infrastructure;

• emerging mitigation technologies approved under future PCS methodologies.

1. PCS retains the authority to define additional eligible project types as methodologies evolve.

2.7 Ineligible Project Types

1. A project is not eligible for registration under PCS if it:

• is prohibited by Host Party law or international agreements;

• presents irreversible environmental harm that cannot be mitigated;

• involves involuntary displacement or harms protected communities;

• operates in protected or conservation areas without explicit authorization;

• expands or prolongs high-carbon infrastructure (e.g., unabated fossil fuel capacity);

• involves activities deemed inconsistent with PCS safeguards or SDG requirements;

• is designed for speculative purposes without substantive implementation intent.

1. No derogation may be granted for ineligible project types.

2.8 Project Start Date Conditions

1. A project may be eligible only if the project start date meets the requirements defined in Annex B. The start date must be transparent, documented, and verifiable. Where a project began implementation prior to methodology approval, the PCS Secretariat may require additional justification to confirm additionality and baseline alignment.

2.9 Double Counting Prevention

1. Eligibility requires full compliance with PCS-STD-001 (Avoidance of Double Counting), including:

• exclusive ownership of mitigation outcomes;

• no double issuance, double registration, or double claiming;

• alignment with Host Party reporting systems as necessary.

1. Failure to prevent double counting renders a project ineligible.

2.10 Safeguards and SDG Integrity

1. A project is eligible only if it has:

• completed the PCS Safeguards Form;

• identified and classified all environmental and social risks;

• demonstrated mitigation measures for moderate and substantial risks;

• conducted stakeholder consultation in accordance with PCS-STD-003;

• completed the SDG assessment at registration.

1. Projects rated as “high-risk” under safeguards may not proceed unless re-designed to reduce risk to an acceptable level.

2.11 Technological Feasibility and Monitoring Capability

1. A project is eligible only if:

• monitoring equipment and systems can feasibly generate required data;

• the project can maintain consistent monitoring throughout the crediting period;

• data systems allow traceability and verification;

• the project can comply with digital monitoring requirements where methodologies mandate advanced systems.

1. PCS may declare a project ineligible if monitoring feasibility is insufficient for transparent verification.

2.12 Table 2-A – Summary of Eligibility Requirements

Eligibility Domain	Key Requirement	Eligibility Condition
Methodology	Project covered by PCS methodology	Mandatory
Legal compliance	Project complies with Host Party laws	Mandatory
Additionality	Demonstrated in accordance with Annex A	Mandatory
Safeguards	PCS safeguard compliance demonstrated	Mandatory
SDG Assessment	Completed per PCS-STD-003	Mandatory
Boundaries	Clear physical & emission boundaries	Mandatory
Monitoring capability	Sufficient for verification	Mandatory
Start date	Meets Annex B criteria	Mandatory
Double counting	Fully prevented per PCS-STD-001	Mandatory

2.13 Continuous Eligibility

1. Eligibility is not static. A project must remain in continuous compliance with this Standard for the duration of the crediting period. Circumstances that may affect ongoing eligibility include:

• regulatory changes affecting project legality;

• material project modifications;

• safeguard incidents;

• monitoring system failure;

• inconsistent or unreliable data;

• double counting risk;

• failure to implement corrective actions after non-conformities.

1. Where eligibility is compromised, PCS may require corrective actions, revalidation, or suspension of credit issuance.

2.14 Determination of Eligibility by the PCS Secretariat

1. Eligibility is determined solely by the PCS Secretariat based on:

• submitted documentation;

• VVB validation findings;

• Secretariat review;

• any clarifications or evidence requested during review.

1. The PCS Secretariat may reject or conditionally approve a project if eligibility criteria are not met in full.

Chapter 3 - Project Start Date & Crediting Period

3.1 General Provisions

1. This chapter defines the requirements governing the determination of the project start date, the establishment of the crediting period, and the renewal or modification of such periods under the Planetary Carbon Standard (PCS). These temporal elements establish the timeframe within which a project may generate verified emission reductions or removals and ensure that baseline conditions and additionality remain valid throughout the project’s operational life.

2. The rules set forth in this chapter apply to all mitigation activities seeking registration under PCS, regardless of sector, technology, or activity type.

3. The Project Proponent bears responsibility for providing transparent, accurate, and verifiable information relating to the timing of project implementation, operational milestones, and the commencement of emission reduction or removal activities.

3.2 Project Start Date

1. The project start date is a fundamental determinant of eligibility and affects baseline justification, additionality, and crediting period commencement.

2. The project start date shall be defined as the earliest date on which any of the following occurred:

• The initiation of physical implementation, including construction, installation, or commissioning of equipment or infrastructure that is central to the mitigation activity;

• The signing of binding financial agreements, contracts, or procurement arrangements that commit the Project Proponent to material implementation activities;

• The beginning of continuous operational activity generating emission reductions or removals;

• The point at which irreversible commitments toward implementation were made.

1. Feasibility studies, non-binding letters of intent, and preliminary design work do not constitute a project start date.

2. The project start date must be supported by documentary evidence, which may include contract signatures, invoices, commissioning logs, regulatory approvals, or other verifiable documentation.

3.3 Conditions Relating to the Project Start Date

1. To maintain eligibility, the following conditions shall apply:

• The project start date shall not precede the start-date limitations set by the applicable PCS methodology.

• Projects that began implementation significantly prior to registration must demonstrate robust additionality and consistency of baseline conditions.

• Projects that changed ownership or structure after the start date must provide documentation demonstrating continuity of project intent and authority.

• Any retrospective claims must be supported by evidence showing uninterrupted monitoring and compliance from the claimed start date onward.

1. In cases where the project start date is not clearly documented or is disputed, the PCS Secretariat shall determine the official date based on the preponderance of evidence.

3.4 Crediting Period Overview

1. The crediting period defines the length of time during which a project may generate PCS carbon credits (PCCs), subject to verification.

2. The crediting period must align with the applicable methodology and shall be declared at the time of registration.

3. Crediting periods are designed to:

• ensure baseline relevance,

• preserve additionality integrity,

• enable periodic reassessment of safeguard and SDG performance,

• and ensure that evolving regulatory or contextual conditions are taken into account.

1. PCS supports renewable crediting periods as well as fixed-duration periods, depending on the project type and methodology.

3.5 Crediting Period Length

1. Unless otherwise specified in the applicable methodology, the following crediting period durations apply:

• Emission reduction projects (non-AFOLU): 7 to 10 years, renewable once or more depending on methodology rules.

• AFOLU and nature-based removal projects: 20 to 30 years, with renewal requirements defined in land-use methodologies.

• Engineered removals (CCS, BECCS, DACCS): 10 to 15 years, renewable based on technology viability and storage permanence conditions.

• Distributed and household technologies: 5 to 7 years, with renewal subject to reassessment of technology lifetimes and continued performance.

1. The PCS Secretariat may shorten or extend crediting periods under special conditions defined in the applicable methodology.

3.6 Start of the Crediting Period

1. The crediting period begins on the date:

• the project is registered under PCS; or

• the project begins generating measurable and monitorable emission reductions or removals;

whichever is later, unless methodology rules specify alternative provisions.

1. Projects may request a delayed start of the crediting period, provided that:

• the request is made at registration,

• monitoring systems are not yet fully operational, and

• baseline conditions remain valid.

3.7 Renewal of the Crediting Period

1. A Project Proponent may renew a crediting period upon its expiration, subject to the following conditions:

• Revalidation: The project must undergo revalidation under PCS-STD-004, assessing continued eligibility, additionality, and compliance with safeguards and SDG criteria.

• Baseline Update: Baseline conditions must be reassessed in accordance with Annex C, reflecting technological, regulatory, and market developments.

• Safeguard & SDG Reassessment: Updated safeguards and SDG assessments are required to ensure ongoing compliance.

• Monitoring System Review: Monitoring plans must be reassessed for accuracy, feasibility, and alignment with current methodology requirements.

• Host Party Requirements: If the Host Party has updated policies relevant to the project, such updates must be taken into account.

1. Renewal may be denied if ongoing compliance or integrity risks are identified.

3.8 Limits on Renewal

1. PCS may impose limits on the number of allowable renewals based on:

• methodology provisions;

• technology obsolescence;

• carbon market integrity considerations;

• Host Party policy constraints;

• updates to PCS rules.

1. Projects showing diminishing additionality or weakened baseline justification may be approved for shortened renewal periods or denied renewal entirely.

3.9 Early Termination or Suspension of Crediting

1. The crediting period may be suspended or terminated prior to its scheduled end if:

• material non-compliance is identified and unresolved;

• monitoring fails or becomes insufficient to support verification;

• the project discontinues operation;

• safeguard failures occur that compromise project integrity;

• double counting risks arise and cannot be mitigated;

• the Host Party revokes necessary authorizations.

1. Upon termination, no further PCS credits may be issued for the project.

3.10 Table 3-A – Summary of Project Timing Requirements

Timing Element	Requirement	Determined By
Project Start Date	Earliest implementation commitment	Documented evidence
Credit Start Date	Registration or measurable mitigation	PCS Secretariat
Crediting Period Length	Methodology-based (5–30 years)	PCS Methodology
Credit Period Renewal	Requires full revalidation	PCS Secretariat + VVB
Early Termination	Triggered by non-compliance	PCS Secretariat

3.11 Transparency Requirements

1. All timing-related information, including:

• project start date,

• crediting period,

• renewal decisions,

• suspensions or terminations,

shall be disclosed in the PCS Registry.

1. Evidence supporting the project start date and any change in crediting timelines must be retained in accordance with Chapter 11 of this Standard.

3.12 Final Determination Authority

1. The PCS Secretariat shall make all final determinations relating to:

• the acceptability of the project start date,

• the commencement of the crediting period,

• the renewal of crediting periods,

• any suspension or termination decisions.

1. The Secretariat may request additional evidence or clarification at any time.

Chapter 4 - Project Boundaries

4.1 General Provisions

1. The determination of project boundaries is fundamental to establishing the scope of emissions sources, sinks, and reservoirs relevant to the quantification of emission reductions or removals under the Planetary Carbon Standard (PCS).

2. Boundaries define the spatial, operational, and organizational limits of a mitigation activity and ensure that all components influencing project performance are transparently identified and consistently monitored.

3. Project boundaries must be defined in accordance with this Standard and the applicable PCS methodology. They shall be sufficiently comprehensive to include all emission sources and sinks affected by the project and to exclude no material component that may influence the baseline or project scenario.

4.2 Boundary Components

1. A PCS project shall define and document the following boundary components:

2. Physical Boundary — The geographical location or area within which the project activity is implemented, including all facilities, land parcels, infrastructure, and equipment contributing to the mitigation activity.

3. Operational Boundary — The technological, procedural, and operational processes involved in generating emission reductions or removals, including ancillary activities where relevant.

4. Organizational Boundary — The entities, institutions, or individuals responsible for implementing and managing the project, including ownership structures, management arrangements, and implementing partners.

5. Emission Boundary — All emission sources, sinks, and reservoirs that are required to be included under the applicable methodology, including direct and indirect sources where relevant.

6. A project’s boundaries must transparently describe all interactions between these components to ensure traceable quantification of results.

4.3 Physical Boundary Requirements

1. The Project Proponent shall:

• map the project area using geospatial coordinates;

• provide clear descriptions of all land areas or facilities involved;

• identify any land-use classifications relevant to AFOLU or nature-based projects;

• ensure that physical boundaries are consistent with safeguard assessments, SDG evaluations, and Host Party designations.

1. Boundaries must remain consistent across monitoring periods unless a material change is approved through PCS post-registration change procedures.

4.4 Operational Boundary Requirements

1. Operational boundaries shall describe:

• technologies deployed,

• processes introduced or modified,

• energy systems involved,

• waste or material flows affected,

• storage or capture systems (for removals technologies).

1. The operational boundary must align with the project description in the Project Design Document and the methodology’s applicability conditions.

2. All operational elements relevant to emissions—either baseline or project—must be identified.

4.5 Organizational Boundary Requirements

1. The organizational boundary shall identify:

• the Project Proponent;

• implementing entities;

• technology suppliers;

• operation and maintenance partners;

• community- or household-level participants (where applicable);

• legal entities responsible for monitoring and reporting.

1. Where multiple organizations are involved, governance arrangements must be documented, including roles, responsibilities, and contractual agreements.

2. Any change in organizational structure after registration must be reported in accordance with post-registration change requirements.

4.6 Emission Boundary Requirements

1. The emission boundary defines all greenhouse gas emission sources and sinks relevant to baseline and project scenarios.

2. A project shall define and justify inclusion or exclusion of:

• direct emissions from project activities;

• upstream or downstream emissions, where required by methodology;

• emissions associated with fossil fuel use, electricity use, or biomass combustion;

• emissions displaced or avoided by project activities;

• carbon pools relevant to AFOLU activities;

• CO₂ storage systems, pipelines, or injection wells for CCS and removals projects.

1. The emission boundary must be consistent with:

• the methodology’s mandatory inclusions and allowable exclusions,

• sector-specific PCS annexes (e.g., AFOLU, engineered removals),

• leakage requirements described in Chapter 7.

1. Emission boundaries may not omit any source or sink required under the applicable methodology.

4.7 Boundary Consistency Between Baseline and Project Scenario

1. Boundaries applied to the baseline scenario must be consistent with those applied to the project scenario unless justified by:

• differences inherent to methodological requirements,

• technological or operational changes directly resulting from project implementation,

• specific emissions sources required only under one scenario.

1. Any difference between baseline and project boundaries must be clearly justified and documented.

4.8 Permanence Considerations for Removals Projects

1. For CCS, DACCS, BECCS, and AFOLU removal activities, boundaries must include all elements affecting permanence, including:

• storage sites and reservoirs;

• transportation corridors;

• monitoring wells, sensors, and subsurface structures;

• biological carbon pools (for AFOLU projects);

• areas vulnerable to reversal risks such as fire, pests, or land-use change.

1. Boundary definition must align with monitoring requirements for permanence in the applicable methodology.

4.9 Changes to Boundaries

1. A project’s boundaries must remain consistent throughout the crediting period unless:

• a material change occurs in project design;

• an expansion or reduction in scope is proposed;

• new facilities or areas are added;

• the baseline is updated at renewal.

1. Any change affecting boundaries must be submitted through a Post-Registration Change Request (PRC) and may require revalidation depending on the materiality of the change.

2. The PCS Secretariat shall determine whether any boundary-related change requires full revalidation or partial update.

4.10 Table 4-A – Required Boundary Components

Boundary Category	Description	Documentation Required
Physical Boundary	Geographical project extent	Maps, GPS coordinates, site plans
Operational Boundary	Activities and processes involved	Technology descriptions, process diagrams
Organizational Boundary	Entities responsible for implementation	Legal documents, roles, agreements
Emission Boundary	Sources and sinks included for accounting	Emissions diagrams, methodology references

4.11 Boundary Transparency in the PCS Registry

1. All boundary descriptions must be included in the Project Design Document and published in the PCS Registry.

2. Updates, clarifications, or revisions must be re-published following approval by the PCS Secretariat.

3. PCS reserves the right to request additional boundary documentation at any time, particularly where:

• verification findings indicate discrepancies;

• VVBs identify inconsistencies;

• stakeholder feedback suggests inadequacies;

• boundary scope affects safeguard assessments or leakage.

4.12 Authority for Boundary Determination

1. The Project Proponent shall define boundaries in accordance with PCS rules and methodologies. The VVB shall validate boundary determination during validation, and the PCS Secretariat shall issue the final determination on boundary acceptability.

2. Any unresolved ambiguity shall be clarified through written direction from the PCS Secretariat.

Chapter 5 - Additionality Requirements

5.1 General Provisions

1. Additionality is a foundational requirement of all mitigation activities registered under the Planetary Carbon Standard (PCS). It ensures that emission reductions or removals credited under PCS represent real climate benefits beyond what would have occurred in the absence of the project. This chapter establishes the mandatory principles, evidentiary requirements, and assessment procedures for demonstrating additionality.

2. Additionality shall be demonstrated at validation and shall remain credible throughout the crediting period. Material changes that influence additionality must be disclosed to the PCS Secretariat without delay.

3. No project may be registered, renewed, or issued PCS carbon credits unless additionality is demonstrated in accordance with this Standard and the applicable PCS methodology.

5.2 Additionality Assessment Framework

1. PCS applies a structured multi-layered additionality assessment framework, consisting of:

2. Regulatory Surplus Assessment

3. Investment or Financial Additionality Assessment

4. Barrier Assessment (technological, institutional, or operational)

5. Common Practice Assessment

6. PCS-Methodology-Specific Additionality Tests (if applicable)

7. A project shall demonstrate additionality using all tests required by the applicable methodology. The overall objective is to establish that the project would not have occurred without PCS incentives or equivalent carbon-finance support.

5.3 Regulatory Surplus Requirement

1. A project is additional if it is not mandated by law, regulation, or enforceable governmental requirement within the Host Party at the time of project implementation.

2. The Project Proponent shall demonstrate that:

• the mitigation activity is voluntary;

• no binding regulation requires implementation;

• no legally enforceable standard obliges the technology, practice, or activity;

• any relevant regulatory requirements have been met without eliminating the voluntary nature of the mitigation action.

1. If the project goes beyond a legal requirement (e.g., exceeds minimum performance standards), additionality may be demonstrated for the portion exceeding the regulatory baseline.

2. Regulatory requirements enacted after the project start date do not automatically negate additionality but may require re-assessment at crediting period renewal.

5.4 Investment / Financial Additionality Requirement

1. Where required by the applicable PCS methodology, investment or financial additionality shall be demonstrated. The Project Proponent must demonstrate that the project:

• is not financially attractive without revenue from PCS carbon credits; or

• faces higher costs or lower returns than comparable alternatives; or

• requires PCS-related finance to overcome investment risks or capital barriers.

1. Acceptable evidence may include:

• financial models;

• capital cost breakdowns;

• project internal rate of return (IRR) analyses;

• loan agreements or financing barriers;

• evidence of alternative investment benchmarks.

1. Financial documentation must be transparent, auditable, and consistent with reasonable industry practices. Manipulation or artificial inflation of costs constitutes grounds for rejection.

5.5 Barrier Assessment Requirement

1. A project may demonstrate additionality if significant barriers prevent implementation in the absence of PCS incentives. Barriers may include:

• technological barriers (limited access, complexity, immaturity of solutions);

• institutional or regulatory barriers (permitting difficulties, governance constraints);

• operational barriers (supply chain limitations, infrastructure deficiencies).

1. Barriers must be:

• credible,

• supported by evidence,

• clearly linked to project feasibility, and

• unresolved without PCS support.

5.6 Common Practice Assessment

1. The Project Proponent shall demonstrate that the mitigation activity is not common practice within the Host Party, sector, or region.

2. A project fails the common practice test if:

• the technology or practice is widely deployed under similar circumstances;

• comparable entities have adopted it without carbon-finance incentives;

• operating conditions do not differ materially from typical deployments.

1. The assessment must:

• define the geographic and sectoral scope;

• identify comparable technologies or practices;

• assess penetration rates;

• justify any adjustments for contextual differences.

1. Exceptions may be permitted where a project clearly surpasses the performance of common alternatives.

5.7 Combined Additionality Determination

1. A project must satisfy all additionality tests required under the applicable methodology. Failure to satisfy any required test results in ineligibility for registration.

2. PCS recognizes that some methodologies incorporate integrated or simplified additionality tests for small-scale, micro-scale, or household projects. Such methodologies shall prevail where explicitly permitted.

5.8 Evidence Requirements

1. Evidence supporting additionality claims must be:

• verifiable;

• traceable;

• free from contradiction;

• consistent with Host Party conditions;

• retained for the entire crediting period and validation cycles.

1. Examples of acceptable evidence include:

• government regulations;

• industry benchmarks;

• statistical datasets;

• procurement contracts;

• engineering analyses;

• feasibility studies.

1. Unsupported statements, assumptions, or hypothetical narratives are not acceptable.

5.9 Table 5-A – Summary of Additionality Tests & Evidence

Additionality Test	Objective	Required Evidence
Regulatory Surplus	Project is not legally required	Laws, permits, government circulars
Investment/Financial	Project is not viable without PCS	Financial models, IRR, payback analyses
Barrier Assessment	Project faces constraints	Technical, institutional, or market barriers
Common Practice	Project is uncommon in region	Market analyses, penetration data
Methodology Tests	Specialized tests per methodology	Sector-specific data, modeled comparisons

5.10 Re-Assessment at Crediting Period Renewal

1. Additionality must be reassessed at crediting period renewal. Reassessment shall evaluate:

• updated regulatory conditions;

• technological or market developments that affect common practice;

• financial circumstances that may alter viability;

• any changes in Host Party policies affecting additionality;

• any methodological updates affecting baseline or additionality.

1. Failure to demonstrate additionality at renewal may result in:

• shortened crediting period;

• revised baseline; or

• eligibility termination.

5.11 Impact of Material Changes on Additionality

1. Any material change affecting project economics, technology choices, or regulatory conditions must be disclosed to the PCS Secretariat.

2. Changes that may affect additionality include:

• receipt of new subsidies or incentives;

• changes in operational configuration;

• shifts in regulatory requirements;

• technology upgrades or expansions;

• changes in project boundary.

1. PCS may require revalidation or baseline update if additionality is materially affected.

5.12 VVB Responsibilities for Additionality

1. During validation, the VVB shall:

• assess completeness, transparency, and credibility of additionality evidence;

• evaluate whether applied tests comply with methodology requirements;

• confirm that baseline and additionality conditions are consistent;

• classify non-conformities affecting additionality;

• verify that assumptions are reasonable and conservative.

1. The VVB shall document all findings in the Validation Report.

5.13 PCS Secretariat Determination

1. Final determination of additionality rests with the PCS Secretariat after reviewing:

• the PVR;

• supporting documentation;

• clarifications provided by the Project Proponent;

• applicability of methodology rules;

• any contextual considerations relevant to the Host Party.

1. The Secretariat may approve, conditionally approve, or reject additionality claims.

5.14 Consequences of Failure to Demonstrate Additionality

1. If a project fails to demonstrate additionality:

• it cannot be registered under PCS;

• it may not receive PCS carbon credits;

• reinstatement is allowed only after re-submission and revalidation under materially changed project conditions.

1. No credits may be issued for periods during which additionality was not valid.

Chapter 6 - Baseline Requirements

6.1 General Provisions

1. The baseline represents the greenhouse gas (GHG) emissions, removals, or carbon stock changes that would occur in the absence of the project activity. Establishing a robust baseline is essential to ensuring that emission reductions or removals quantified under the Planetary Carbon Standard (PCS) are real, additional, and conservatively estimated.

2. All PCS projects must apply a baseline consistent with this Standard and the applicable methodology. Baselines shall be transparent, evidence-based, and conservatively determined using credible information available at the time of validation.

3. The baseline determined for a project must remain valid throughout the crediting period unless updated due to renewal, methodology revision, or material changes in circumstances.

6.2 Baseline Setting Principles

1. The following principles shall govern baseline development:

2. Plausibility — The baseline must reflect conditions reasonably expected to occur without the project.

3. Conservativeness — Baseline assumptions must avoid overestimation of emissions and ensure conservative quantification.

4. Completeness — All relevant emissions sources, sinks, and reservoirs required by the methodology must be included.

5. Consistency — Baseline boundaries must match project boundaries unless explicitly justified.

6. Transparency — All data sources, assumptions, and calculations must be documented and verifiable.

7. Alignment With Host Party Conditions — Baselines must reflect local policies, regulations, and technological conditions.

8. Stability and Reassessment — Baselines shall remain valid for the crediting period unless there is a trigger requiring reassessment.

6.3 Types of Baselines

1. PCS methodologies may prescribe one or more baseline types, including:

• Historical baselines (using historical data for emissions or activity levels)

• Performance standard baselines (using standardized emission factors or sector benchmarks)

• Model-based baselines (using models to estimate expected emissions)

• Default factors or grid emission factors

• Regional or jurisdictional baselines

• Hybrid or composite approaches combining the above

1. The Project Proponent shall apply the baseline type required by the applicable methodology. Deviations are not permitted unless explicitly allowed.

6.4 Baseline Data and Evidence Requirements

1. All baseline determinations must be supported by verifiable evidence. Evidence may include:

• historical monitoring data;

• engineering analyses and feasibility studies;

• utility records, metering logs, or operational data;

• scientific literature or government data;

• recognized databases (e.g., IPCC, national inventories);

• Host Party regulations, plans, and sector-specific policies;

• third-party technical reports.

1. Evidence must be:

• traceable to original sources;

• relevant to the baseline period;

• free from material inconsistencies;

• retained for the duration of the crediting period.

1. Subjective or unsupported assertions are unacceptable.

6.5 Emission Sources and Sinks in the Baseline

1. The baseline must include all emission sources and sinks required by the methodology. These may include, as applicable:

• direct emissions from stationary or mobile sources;

• fuel combustion and process emissions;

• methane and nitrous oxide emissions in agriculture or waste sectors;

• changes in land-use carbon stock or sequestration;

• fossil or grid electricity use;

• leakage-related emissions where methodologies require integrated accounting.

1. Emission sources excluded by the methodology must be identified and justified.

6.6 Influence of Host Party Policies and Regulations

1. The baseline must reflect the legal and regulatory environment in the Host Party. This includes:

• minimum performance standards;

• mandatory technology or fuel requirements;

• legally binding emissions limits;

• national and subnational climate policies;

• sectoral transition plans, where applicable.

1. Regulations enacted before the project start date must be reflected in the baseline. Regulations enacted after the project start date shall not retroactively alter the baseline, unless the methodology explicitly requires dynamic baseline adjustments.

6.7 Baseline Emission Calculation Requirements

1. The baseline shall be calculated in accordance with the applicable methodology, which may require:

• specified formulas;

• default factors (e.g., IPCC-compatible);

• activity data parameters;

• uncertainty adjustments;

• modelled estimates;

• sampling-based approaches.

1. Assumptions and modelling must be justified and conservative.

6.8 Baseline Period

1. PCS methodologies may define a baseline period or data window. The following apply:

• historical data must reflect representative conditions;

• anomalies must be identified and addressed;

• data gaps must be conservatively treated;

• temporal alignment between baseline data and monitoring years shall be ensured.

1. Longer historical periods may be required for AFOLU projects to ensure representativeness.

6.9 Dynamic and Updating Baselines

1. Some methodologies require updating baselines during the crediting period to reflect evolving conditions. These may include:

• grid emission factor updates;

• technology penetration changes;

• regulatory shifts;

• land-use change patterns;

• modelled projections.

1. Dynamic baselines must follow methodology rules and must be validated by the VVB.

6.10 Baseline Reassessment at Crediting Period Renewal

1. At crediting period renewal:

• the baseline must be reassessed;

• new data sources must be incorporated;

• regulatory updates must be reflected;

• common practice must be reconsidered;

• technological improvements must be accounted for.

1. Baseline reassessment ensures continued additionality and avoids perpetuation of outdated conditions.

6.11 Special Provisions for AFOLU and Removals Projects

1. Baselines for AFOLU, nature-based, and removals projects must:

• define carbon pools included and excluded;

• assess potential land-use change drivers;

• evaluate climatic, ecological, and management factors;

• reflect historical land-use and carbon-stock trends;

• incorporate risk assessments for reversals.

1. AFOLU-specific requirements are detailed in Annex E.

6.12 Table 6-A – Summary of Baseline Requirements

Baseline Component	Requirement	Supporting Evidence
Baseline type	Must follow methodology	Methodology reference
Data sources	Relevant and verifiable	Utility logs, historical records
Emission boundary	Must match project boundary	Boundary diagrams
Regulatory context	Pre-project regulations included	Laws, policies
Calculation methods	Per methodology	Calculation sheets
Conservativeness	Conservative assumptions	Justification statements
Updating	Dynamic updates if required	Updated datasets
Renewal	Full reassessment required	Renewal documentation

6.13 Baseline Transparency Requirements

1. The Project Proponent shall document:

• all data sources;

• all calculations;

• all assumptions;

• rationale for parameter choices;

• uncertainty assessments;

• any exclusions permitted by the methodology.

1. Baseline information must be included in the Project Design Document and published in the PCS Registry.

6.14 Validation of the Baseline

1. The VVB shall:

• independently verify baseline data and assumptions;

• recalculate baseline emissions where required;

• assess reasonableness and conservativeness;

• identify uncertainties and inconsistencies;

• classify any deviations as non-conformities.

1. The Validation Report must provide a detailed assessment of baseline integrity.

6.15 PCS Secretariat Determination

1. The PCS Secretariat shall make the final determination of baseline acceptability after reviewing:

• the Project Design Document;

• the VVB’s validation findings;

• any clarifications requested;

• relevant Host Party policy settings;

• methodology provisions.

1. Rejection of a baseline invalidates project eligibility until corrected.

6.16 Baseline Revisions Due to Material Change

1. Where a material change affects baseline assumptions, the Project Proponent must:

• notify PCS via a Post-Registration Change Request;

• submit updated baseline calculations;

• undergo revalidation if required.

1. Such changes include:

• significant shifts in operational context;

• structural changes in baseline facilities;

• regulatory or market shifts affecting baseline plausibility.

Chapter 7 - Leakage Assessment

7.1 General Provisions

1. Leakage refers to changes in greenhouse gas emissions that occur outside the project boundary, but which are attributable to the implementation of the project activity.

2. Leakage may increase or decrease emissions and must be assessed to ensure that PCS-issued mitigation outcomes represent the net climate impact of the project.

3. This chapter establishes the mandatory requirements for the identification, assessment, quantification, and deduction of leakage emissions under the Planetary Carbon Standard (PCS).

4. All PCS projects shall assess leakage in accordance with:

• this Standard;

• the applicable PCS methodology;

• sector-specific annexes (particularly Annex E for AFOLU);

• conservative principles outlined in PCS-STD-004;

• Host Party laws and relevant contextual information.

1. Leakage assessment is mandatory for all projects, unless the applicable methodology explicitly states that leakage is negligible or not applicable.

7.2 Leakage Types

1. PCS recognizes three primary categories of leakage:

2. Activity-Shifting Leakage: Occurs when project participants move emissions-generating activities outside the project boundary (e.g., shifting deforestation from one area to another).

3. Market Leakage: Occurs when supply-and-demand dynamics respond to project implementation, causing emissions to rise elsewhere (e.g., reduced timber production leading to increased logging elsewhere).

4. Emission Displacement Leakage: Occurs when emissions are relocated geographically due to the project’s interventions (e.g., displaced waste dumping, fuel switching leading to indirect emissions).

5. Additional sub-categories may exist depending on project type, and methodologies may define them explicitly.

7.3 Leakage Identification Requirements

1. The Project Proponent shall conduct a comprehensive leakage identification assessment that includes:

• identification of all potential leakage sources listed in the methodology;

• identification of project-specific leakage risks not explicitly listed;

• assessment of upstream and downstream supply-chain effects where relevant;

• examination of indirect impacts on land use, energy systems, waste flows, and market dynamics.

1. Leakage identification must be holistic, conservative, and grounded in evidence. Unsupported assertions that leakage is unlikely are not acceptable.

7.4 Leakage Boundaries

1. Leakage boundaries extend beyond the physical project boundary and shall encompass:

• areas where displaced activities may occur;

• markets or supply chains affected by project outputs;

• communities or individuals whose behavior may shift due to project interventions;

• regions affected by upstream or downstream impacts.

1. The leakage boundary may vary by project type and shall be defined in accordance with the applicable methodology.

7.5 Evidence Requirements for Leakage Identification

1. Leakage assessments must be supported by evidence such as:

• historical production or consumption trends;

• industry or sectoral analyses;

• land-use maps and geospatial data;

• household or community surveys (for distributed technologies);

• economic modeling outputs;

• market or commodity data;

• Host Party statistical datasets;

• peer-reviewed studies.

1. The VVB shall verify that all evidence is credible, relevant, and complete.

7.6 Leakage Quantification

1. Leakage emissions must be quantified using the calculation procedures established in the applicable PCS methodology.

2. Quantification may involve:

• direct measurement;

• emission factors;

• modelling tools;

• default leakage coefficients;

• sampling-based approaches;

• conservative scenario analyses.

1. Where multiple quantification options exist, the Project Proponent shall use the option that ensures conservativeness and consistency with methodology rules.

2. Uncertainty in leakage quantification shall be addressed conservatively.

7.7 Leakage Deduction

1. Leakage emissions quantified in accordance with the methodology shall be deducted from the project’s calculated emission reductions or removals. The deduction formula must follow methodology rules, but in general:

Net Emission Reductions = Project Emission Reductions − Leakage Emissions

1. If leakage emissions exceed project emission reductions, the project may report zero net reductions for the monitoring period but shall not report negative reductions.

2. PCS does not issue credits for periods where net reductions equal zero.

7.8 Temporal Considerations for Leakage

1. Leakage may be:

• Immediate: occurring at or near project start;

• Lagged: occurring months or years after project implementation;

• Persistent: continuing for the entire crediting period;

• Temporary: limited to initial implementation years.

1. The Project Proponent must track and reassess leakage risks throughout the crediting period, particularly for AFOLU and market-sensitive project types.

7.9 Special Requirements for AFOLU and Nature-Based Solutions

1. AFOLU projects are particularly sensitive to leakage risks, including:

• activity displacement to lands outside the boundary;

• fuelwood extraction displacement;

• livestock redistribution;

• agricultural intensification;

• market substitution effects.

1. AFOLU leakage rules are further detailed in Annex E, which includes:

• leakage belts;

• village or landscape-level assessments;

• community agreements;

• deforestation-risk modelling;

• risk mitigation strategies.

1. AFOLU projects must include a leakage mitigation plan at validation.

7.10 Leakage Mitigation Measures

1. The Project Proponent shall implement appropriate strategies to minimize leakage, such as:

• alternative livelihood support;

• community engagement and agreements;

• improved land-use planning;

• sustainable fuel or material substitution;

• integrated waste or supply-chain interventions;

• technology support programs to prevent activity shifting.

1. Mitigation measures shall be described in the Project Design Document and monitored during verification.

7.11 Table 7-A – Summary of Leakage Types and Assessment Requirements

Leakage Type	Description	Assessment Requirement
Activity-shifting	Displacement of emissions-causing activities	Spatial and behavioral analysis
Market leakage	Market-driven emissions outside boundary	Market/commodity data analysis
Emission displacement	Relocation of operational emissions	Supply-chain and operational mapping
AFOLU leakage	Displacement of land-use pressures	Annex E requirements

7.12 Monitoring Leakage

1. Monitoring requirements include:

• periodic reassessment of leakage risks;

• monitoring of displaced activities using surveys, satellite imagery, or market data;

• submission of leakage monitoring results in the Monitoring Report;

• corrective actions where leakage increases unexpectedly.

1. Leakage monitoring frequency shall follow methodological requirements.

7.13 Verification of Leakage

1. The VVB shall independently verify:

• leakage identification completeness;

• leakage boundary determination;

• evidence supporting leakage quantification;

• correct application of methodology formulas;

• deductibility and conservativeness;

• adequacy of leakage mitigation measures.

1. Leakage errors are often material. Any understatement of leakage is classified as a material non-conformity.

7.14 Leakage During Credit Period Renewal

1. At crediting period renewal, leakage shall be reassessed to account for:

• shifts in market conditions;

• migration of economic activities;

• changes in land-use drivers;

• technological or behavioral adaptation;

• updated scientific or Host Party data.

1. Reassessment ensures that leakage deductions remain relevant and conservative.

7.15 Residual Leakage After Mitigation

1. Residual leakage refers to leakage emissions remaining after mitigation measures. PCS requires that:

• residual leakage be quantified and deducted;

• mitigation strategies be adjusted if leakage increases;

• persistent leakage risks be addressed through updated project design.

1. Failure to address persistent leakage may lead to reduced credit issuance or project ineligibility.

7.16 PCS Secretariat Determination

1. The PCS Secretariat shall make the final determination of leakage acceptability, including:

• completeness of identification;

• transparency of evidence;

• appropriateness of quantification;

• sufficiency of mitigation strategies.

1. If leakage assessment is inadequate, the Secretariat may:

• require revalidation;

• suspend issuance;

• require project modification;

• reject leakage claims until corrected.

Chapter 8 - Monitoring Requirements

8.1 General Provisions

1. Monitoring is the systematic process of collecting, recording, and managing data required to quantify emission reductions, removals, safeguard performance, and sustainable development contributions under the Planetary Carbon Standard (PCS).

2. This chapter establishes the requirements for designing, implementing, documenting, and maintaining monitoring systems that ensure transparency, accuracy, traceability, and verifiability throughout the crediting period.

3. Monitoring must be conducted in accordance with:

• the applicable PCS methodology;

• this Project Standard;

• PCS-STD-004 (Validation & Verification Standard);

• PCS-STD-003 (Safeguards & SDG Integrity Standard);

• any applicable sectoral or technical annexes.

1. Only monitoring results that comply with these requirements may be used for verification and issuance of PCS credits.

8.2 Monitoring Plan Requirements

1. Every project must include a Monitoring Plan within the Project Design Document (PDD). The Monitoring Plan shall describe:

• parameters to be monitored;

• data collection and measurement procedures;

• monitoring frequency;

• monitoring equipment, instruments, or digital systems;

• data storage and management processes;

• QA/QC procedures;

• roles and responsibilities;

• calibration and maintenance requirements;

• sampling approaches, where relevant;

• uncertainty treatment.

1. The Monitoring Plan must be sufficiently detailed to allow a Verification & Validation Body (VVB) to replicate or independently verify all calculations.

8.3 Parameters to Be Monitored

1. Project Proponents shall monitor:

• Activity data required for emissions or removals quantification;

• Emission factors and other stochastic parameters;

• Baseline and project scenario parameters defined in the methodology;

• Leakage indicators, where applicable;

• Safeguard indicators required under PCS-STD-003;

• SDG indicators selected for monitoring;

• Operational and contextual data influencing performance;

• Metadata, including timestamps, device IDs, and calibration tags, for digital monitoring systems.

1. Only parameters defined in the methodology or required by PCS rules shall be included.

8.4 Measurement and Data Collection

1. Monitoring shall rely on measurements, observations, or data sources that are:

• accurate,

• traceable,

• representative,

• conservative,

• and suitable for independent verification.

1. Data may be collected through:

• direct measurement (e.g., meters, sensors);

• remote sensing and geospatial methods;

• laboratory analyses;

• digital or automated monitoring systems;

• validated models, where allowed;

• sampling surveys (structured and validated);

• operational logs and records.

1. Data collection methods must align with the applicable methodology and be justified where alternatives are used.

8.5 Calibration and Maintenance of Monitoring Equipment

1. Equipment used to monitor project parameters shall:

• be calibrated according to manufacturer or recognized standards;

• have calibration intervals consistent with methodology requirements;

• be maintained in functional condition throughout the monitoring period;

• have calibration records retained for verification.

1. Calibration lapses must be conservatively addressed, potentially requiring data discounting or correction factors.

8.6 Monitoring Frequency

1. Monitoring frequency for each parameter shall be:

• defined in the methodology;

• sufficient to capture temporal variation;

• consistent with equipment capabilities;

• appropriate for the risk profile of the parameter.

1. Where methodologies provide multiple frequency options, the more conservative or accurate option shall be selected unless justified otherwise.

8.7 Data Management and Storage

1. Project Proponents shall maintain a data management system that ensures:

• secure and tamper-resistant storage of monitoring data;

• retention of raw and processed data;

• clear data lineage and metadata;

• consistent version control;

• backup procedures;

• protection against unauthorized access or modification.

1. Where digital systems are used, blockchain anchoring or other cryptographic tools may be employed to ensure data integrity, as defined in Annex F.

8.8 QA/QC Procedures

1. Quality Assurance (QA) and Quality Control (QC) procedures shall be included in the Monitoring Plan and implemented throughout the crediting period. QA/QC procedures shall include:

• verification of data completeness;

• cross-checking of monitoring records;

• periodic review of calculations;

• error detection and correction processes;

• internal audits, where applicable.

1. Procedures must be designed to ensure that errors or inconsistencies are promptly identified and addressed.

8.9 Sampling Requirements

1. Sampling may be used for:

• household or distributed-energy projects;

• AFOLU community assessments;

• biomass or soil carbon sampling;

• monitoring of dispersed systems;

• surveys of technology usage.

1. Sampling plans must adhere to:

• PCS methodology rules;

• ISO 19011 and ISO 2859 principles;

• PCS-STD-004 (sampling validation requirements).

1. A sampling plan must describe:

• sampling method (random, stratified, cluster);

• sample size and justification;

• confidence and precision levels;

• replacement rules for non-response;

• treatment of outliers and missing data.

1. Sampling errors must be conservatively treated.

8.10 Monitoring of Safeguards

1. Projects must monitor safeguard indicators in accordance with PCS-STD-003. This includes:

• implementation of mitigation measures;

• reporting of safeguard incidents;

• monitoring of community impacts;

• tracking of environmental risks.

1. Safeguard monitoring must continue for the entire crediting period.

8.11 Monitoring of Sustainable Development Contributions

1. For projects seeking SDG labels or reporting voluntary SDG contributions:

• SDG indicators selected during registration must be monitored;

• data must be evidence-based and verifiable;

• surveys, where used, must follow sampling best practices;

• SDG monitoring outcomes must be included in the Monitoring Report.

1. Only monitored SDG outcomes may be verified.

8.12 Monitoring of Leakage

1. Leakage must be monitored as defined in Chapter 7 and applicable methodology rules. Monitoring may include:

• activity-shifting indicators;

• deforestation-risk factors for AFOLU projects;

• market data for market leakage;

• supply-chain or waste-displacement indicators.

1. Leakage monitoring results must be reported annually or per monitoring period.

8.13 Monitoring Period

1. The monitoring period is the time interval during which monitoring is conducted and for which emission reductions or removals are reported. Requirements include:

• start and end dates must be clearly defined;

• monitoring periods may differ from crediting periods;

• monitoring periods must be sequential and non-overlapping;

• at least one verification must occur for every monitoring period.

1. Shorter monitoring periods may be required if:

• safeguard incidents occur;

• monitoring equipment fails;

• material changes occur.

8.14 Monitoring Report Requirements

1. Each monitoring period requires a Monitoring Report (MR), containing:

• description of monitoring activities;

• data collected for all required parameters;

• calculations of emission reductions or removals;

• leakage assessment;

• safeguard updates;

• SDG indicator performance;

• explanation of deviations;

• data quality assessments;

• uncertainty treatment;

• raw data annexes or references.

1. The MR must enable full reconstruction of reported results.

8.15 Table 8-A – Components of the Monitoring Plan

Monitoring Element	Required Contents
Parameters	All required parameters with units and definitions
Data sources	Instruments, surveys, or records used
Frequency	Monitoring frequency per parameter
QA/QC	Data validation and verification procedures
Storage	Data storage and retention approach
Equipment	Monitoring devices and calibration requirements
Roles	Personnel responsible for each task

8.16 Monitoring Deviations

1. Any deviations from the Monitoring Plan or methodology must:

• be identified and documented in the MR;

• be justified with evidence;

• be conservatively addressed (corrections, adjustments);

• be classified by the VVB as minor or material non-conformities.

1. Material deviations require corrective actions before issuance.

8.17 Responsibilities

1. Project Proponent: Implements monitoring, manages data, prepares Monitoring Reports.

2. VVB: Validates the Monitoring Plan, verifies monitoring results, recalculates emission reductions.

3. PCS Secretariat: Approves the Monitoring Plan at registration and reviews monitoring results prior to issuance.

8.18 Monitoring Plan Revision

1. Monitoring Plans may only be revised if:

• allowed under methodology;

• requested via Post-Registration Change (PRC);

• approved by PCS Secretariat;

• revalidated by VVB if the revision affects emissions accounting.

1. Revisions must maintain integrity and transparency.

8.19 Final Determination

1. The PCS Secretariat shall make the final determination on:

• acceptability of the Monitoring Plan;

• completeness of Monitoring Reports;

• eligibility of data for credit issuance;

• any corrective actions required.

Chapter 9 - Project Revisions & Post-Registration Changes

9.1 General Provisions

1. This chapter establishes the requirements and procedures governing modifications to a project after registration under the Planetary Carbon Standard (PCS).

2. Post-registration changes may include adjustments to project design, boundaries, technology, organizational structure, monitoring methods, or any other element that may affect emission reductions, removals, safeguards, sustainable development outcomes, or ongoing eligibility.

3. The purpose of these requirements is to ensure that any change—whether administrative, operational, or technical—is transparently disclosed, appropriately assessed, and consistently reflected in subsequent validation, verification, and issuance cycles.

4. No project revision shall be implemented in a manner that compromises environmental integrity or undermines the principles of conservativeness, transparency, and traceability.

9.2 Requirement to Report Changes

1. The Project Proponent must report all project changes to the PCS Secretariat through the Post-Registration Change Request (PRC) procedure. A change must be reported regardless of whether it is expected to affect quantified results.

2. Failure to disclose changes constitutes a material non-conformity and may lead to suspension of credit issuance, revalidation, or revocation of project registration.

9.3 Classification of Post-Registration Changes

1. PCS classifies changes into three categories:

• Minor Changes

• Moderate Changes

• Material Changes

1. Each category has different procedural requirements. Changes must be classified by the Project Proponent and subsequently confirmed by the PCS Secretariat.

9.4 Minor Changes

1. Minor changes are administrative or clerical in nature and do not affect:

• baseline conditions,

• project boundaries,

• monitoring systems,

• additionality,

• safeguards, or

• emission reduction/removal calculations.

1. Examples include:

• correction of typographical errors;

• changes in contact information;

• updates to organizational names that do not affect ownership;

• updates to non-critical data fields in the Monitoring Plan.

1. Procedural Requirement: Minor changes must be reported but do not require revalidation or VVB assessment. PCS Secretariat approval is required before documentation is updated in the Registry.

9.5 Moderate Changes

1. Moderate changes may affect monitoring or documentation but do not alter the underlying baseline, boundaries, or technology of the project. They may influence quantification but do not fundamentally alter project design.

2. Examples include:

• replacement of monitoring equipment with a functionally equivalent system;

• adjustments to monitoring frequency where allowed by methodology;

• changes in data-collection procedures not affecting core parameters;

• updates to safeguard mitigation measures without altering risk classification.

1. Procedural Requirement: Moderate changes require:

• submission of PRC documentation;

• review by the PCS Secretariat for completeness;

• review by the VVB at the next verification; or

• immediate review by a VVB if the Secretariat considers the risk significant.

1. No revalidation is normally required unless specified by methodology.

9.6 Material Changes

1. Material changes are any modifications that may affect:

• baseline scenario;

• project boundaries;

• project technology or design;

• operational parameters underlying emission reductions;

• additionality;

• leakage risks;

• safeguard risk classification;

• SDG contribution claims;

• monitoring system integrity;

• the scale, scope, or nature of project activity.

1. Examples include:

• expansion or reduction of project area;

• adoption of new technology or replacement with a non-equivalent system;

• changes influencing baseline emissions or default factors;

• significant modifications affecting carbon pools in AFOLU projects;

• material shifts in project ownership affecting authority or control;

• identification of new risks requiring major safeguard intervention;

• material revisions to sampling design for household/distributed projects.

1. Procedural Requirement: Material changes require:

• Submission of PRC with supporting documentation;

• Evaluation by PCS Secretariat;

• Mandatory Revalidation by a VVB;

• Updated PDD, baseline assessment, monitoring plan, safeguards form, and SDG assessment where applicable;

• Approval by PCS Secretariat before the change is considered effective.

1. No credits shall be issued for periods affected by a material change until revalidation is concluded.

9.7 Table 9-A – Classification of Post-Registration Changes

Change Category	Description	VVB Review Required?	Revalidation Required?
Minor	Administrative, no impact on design or monitoring	No	No
Moderate	Affects monitoring but not core design	At next verification	Not usually
Material	Affects baseline, boundaries, technology, safeguards, or additionality	Yes	Yes

9.8 Impact of Changes on Crediting Period

1. Material changes may require:

• resetting the crediting period;

• shortening or extending crediting duration where permitted;

• updating baseline conditions or additionality evidence at renewal.

1. PCS retains discretion to adjust crediting timelines in cases where project integrity might otherwise be compromised.

9.9 Changes Affecting Monitoring Systems

1. If changes affect:

• data accuracy,

• measurement equipment,

• monitoring frequency,

• sampling design, or

• data sources,

1. the Project Proponent must demonstrate that the modified monitoring system:

• meets methodology requirements;

• maintains or improves data quality;

• preserves continuity and traceability of records.

1. Changes that degrade the monitoring system represent a material non-conformity.

9.10 Changes Affecting Safeguards and SDG Assessment

1. If project changes influence safeguard risk levels or SDG contribution pathways, the Project Proponent must:

• update the PCS Safeguards Form;

• revise the Environmental and Social Management Plan (ESMP) if required;

• reassess SDG indicators;

• report any new risks or incidents.

1. If safeguard classification increases to “substantial” or “high,” revalidation is mandatory.

9.11 Changes in Organizational Structure

1. Changes in:

• ownership,

• implementing partners,

• governance structure, or

• legal entity status

must be reported.

1. The Project Proponent must demonstrate that:

• rights to mitigation outcomes remain intact;

• project authority and responsibility are preserved;

• contracts, agreements, and land rights (where applicable) remain valid.

1. Organizational changes affecting legal ownership require PCS Secretariat review.

9.12 Changes Affecting Baseline Scenario

1. Modifications that influence baseline emissions or removals require:

• new baseline calculations;

• updated evidence;

• new justification and modeling;

• mandatory revalidation.

1. Such changes include regulatory updates, structural shifts, or methodological updates requiring baseline recalculation.

9.13 PCS Secretariat Review

1. The PCS Secretariat shall:

• classify the change as minor, moderate, or material;

• request supplementary documentation if needed;

• determine whether revalidation is required;

• approve or reject the change;

• update the PCS Registry accordingly.

1. The Secretariat may override the Project Proponent’s classification where integrity requires stricter treatment.

9.14 Impact on Verification and Issuance

1. Changes affecting:

• monitoring,

• quantification,

• safeguards,

• SDGs,

• or project boundaries

shall be assessed by the VVB in the next verification, unless the PCS Secretariat requires earlier review.

1. No issuance may occur for monitoring periods affected by unapproved material changes.

9.15 Transitional Provisions

1. If a material change is discovered after issuance has occurred:

• the PCS Secretariat may initiate a compliance review;

• the project may undergo partial or full revalidation;

• future issuance may be suspended;

• corrective actions may be mandated.

1. PCS does not retroactively revoke previously issued units unless fraud or intentional misrepresentation is proven.

9.16 Transparency Requirements

1. All approved changes shall be:

• published in the PCS Registry;

• reflected in updated PDDs and documents;

• clearly disclosed in relevant Monitoring Reports;

• referenced in VVB verification reports.

1. Stakeholders have the right to view non-confidential change records.

9.17 Final Determination

1. Final determination of post-registration changes rests exclusively with the PCS Secretariat, which may:

• accept,

• reject,

• require modifications,

• or require revalidation

based on the impact of the change on environmental integrity and PCS compliance.

Annex A - Additionality Assessment Framework

A.1 Purpose of This Annex

This Annex establishes the technical procedures, evidentiary requirements, assessment steps, and calculation or decision-making tools used to demonstrate additionality under the Planetary Carbon Standard (PCS).

It supplements Chapter 5 by providing the operational framework for applying additionality tests across all activity types and methodologies.

Unless a methodology explicitly provides an alternative, this Annex applies to all PCS project types.

A.2 Structure of Additionality Assessment

PCS additionality assessment consists of four integrated components:

1. Regulatory Surplus Test

2. Investment/Financial Additionality Test (where required)

3. Barrier Assessment

4. Common Practice Assessment

Methodologies may add further tests (e.g., penetration thresholds, risk-adjusted performance tests) but may not waive the core structure unless explicitly permitted.

A.3 Regulatory Surplus Test

A.3.1 Objective

To ensure that the project is not legally mandated or required under binding Host Party regulations.

A.3.2 Requirements

The Project Proponent must demonstrate that:

• No existing law requires the technology, practice, or process being implemented.

• No regulation requires activities equivalent to the project scenario.

• No enforceable standard would achieve the same emissions impacts as the project.

• Any plans, policies, or targets are non-binding unless enforceable through legal penalties or compliance obligations.

A.3.3 Evidence Requirements

Acceptable evidence may include:

• Copies of laws and regulations;

• Regulatory interpretations or clarifications from competent authorities;

• Sectoral compliance guidelines;

• Compliance audit records;

• Legal opinions where appropriate.

Assertions without documentary support are not acceptable.

A.3.4 Decision Outcome

If the project does not pass the Regulatory Surplus Test, additionality fails and the project is ineligible.

A.4 Investment / Financial Additionality Test

(Applicable where required by methodology or sectoral module)

A.4.1 Objective

To determine whether the project requires PCS-related revenue or carbon finance to become financially viable or attractive relative to alternatives.

A.4.2 Financial Indicators

Methodologies may require:

• IRR (Internal Rate of Return)

• NPV (Net Present Value)

• Payback period

• Marginal abatement cost

• Capital cost comparisons

• Revenue and operating cost projections

These indicators must be based on reasonable, transparent assumptions.

A.4.3 Evidence Requirements

Evidence may include:

• Feasibility studies;

• Cost-benefit analyses;

• Investment committee papers;

• Loan term sheets or rejection letters;

• Historical performance data;

• Sensitivity analyses.

Financial modelling spreadsheets must be provided in editable format.

A.4.4 Conservativeness

Financial assumptions must lean toward conservativeness:

• revenue projections should not be overstated;

• operating costs should not be inflated;

• unrealistic depreciation or discount rates are not acceptable;

• subsidies or incentives must be transparently included.

A.4.5 Decision Outcome

If PCS revenues are a decisive factor enabling implementation, the test is satisfied.

If the project is fully viable without PCS or other carbon revenues, the project fails financial additionality, unless allowable under methodology (e.g., simplified tests for microscale projects).

A.5 Barrier Assessment

A.5.1 Objective

To determine whether the project faces significant barriers—technical, institutional, operational, or market-related—that prevent implementation without PCS support.

A.5.2 Barrier Types

Barriers may include:

• Technological barriers (e.g., untested technology, inadequate supply chains)

• Financial or capital barriers (e.g., high upfront costs, lack of financing instruments)

• Institutional or regulatory barriers (e.g., weak governance, permitting challenges)

• Operational or capacity barriers (e.g., lack of skilled labor, implementation constraints)

• Social or behavioral barriers (e.g., low adoption rates in communities)

A.5.3 Evidence Requirements

Evidence may include:

• technology readiness level assessments;

• market studies;

• supply-chain analyses;

• operational audits;

• capacity assessments;

• letters from financial institutions;

• Host Party documentation.

Barriers must be real, significant, and supported by evidence.

A.5.4 Decision Outcome

If barriers materially impede implementation without PCS incentives, the test is satisfied. Subjective or generic barriers are insufficient.

A.6 Common Practice Assessment

A.6.1 Objective

To determine whether the technology or practice is widely adopted within the relevant sector or geography.

A.6.2 Assessment Steps

1. Define the geographic region (municipal, regional, national, or subnational).

2. Define the sector or activity type relevant to the project.

3. Identify comparable activities (technologies, processes, or practices).

4. Determine the penetration rate using objective data sources.

5. Apply methodology-specific thresholds (e.g., <20% penetration).

A.6.3 Evidence Requirements

• sectoral reports;

• Host Party statistics;

• industry publications;

• peer-reviewed studies;

• databases (e.g., for energy, forestry, waste, agriculture);

• government registries.

A.6.4 Exceptions

Some methodologies allow common practice despite high penetration if:

• the project exceeds minimum performance standards;

• the project demonstrates superior emissions performance relative to common alternatives;

• the methodology uses an additional performance benchmark.

A.7 Decision Matrix for Additionality

Table A-1 – Additionality Decision Matrix

Test	Required?	Outcome if Failed
Regulatory Surplus	Always	Project ineligible
Financial/Investment	As required by methodology	May still be eligible if other tests suffice
Barrier Assessment	Always	Project ineligible unless methodology allows simplified additionality
Common Practice	Always	Project ineligible unless performance benchmark applied
Methodology-Specific Test	If applicable	Project ineligible

A.8 Special Considerations for Microscale & Household Projects

PCS methodologies may include simplified additionality tests for:

• cookstoves,

• water purification,

• household renewable energy systems,

• distributed micro-technologies.

Simplified tests may include:

• default pre-approved additionality;

• deemed barrier demonstrations;

• standardized baselines.

These simplified procedures must be followed exactly and may not be combined with full-scale tests.

A.9 Special Considerations for AFOLU and Removals Projects

AFOLU and engineered removals project types may require:

• additional tests relating to permanence and reversals;

• detailed land-use or carbon model baselines;

• assessments of counterfactual land-use dynamics;

• storage permanence conditions for CCS or DACCS.

These requirements are defined in relevant Annexes (particularly Annex E).

A.10 Documentation Requirements

The Project Proponent must maintain and submit:

• all additionality evidence;

• underlying datasets;

• financial models;

• legal and regulatory references;

• market analyses;

• methodological justification.

All evidence must be retained for the full crediting period and for at least seven years thereafter.

A.11 VVB Responsibilities

The Verification & Validation Body must:

• independently review all additionality evidence;

• ensure compliance with methodology and this Annex;

• recalculate financial indicators where applicable;

• validate assumptions and data sources;

• classify non-conformities;

• document all decisions in the Validation Report.

Additionality errors are material non-conformities.

A.12 PCS Secretariat Determination

The PCS Secretariat shall:

• make the final determination on additionality;

• approve or reject additionality claims;

• require revision or revalidation as needed;

• apply highest-integrity interpretation where ambiguity exists.

Annex B - Project Start Date & Crediting Period Rules

B.1 Purpose of This Annex

This Annex specifies the technical rules governing the determination, documentation, validation, and reassessment of the Project Start Date and Crediting Period for all mitigation activities under the Planetary Carbon Standard (PCS).

It supplements Chapter 3 by providing detailed procedures for establishing timing parameters relevant to eligibility, baseline validity, additionality, and issuance.

These requirements apply uniformly across all PCS methodologies unless a methodology explicitly provides an alternative provision.

B.2 Project Start Date

B.2.1 Definition

The Project Start Date is defined as the earliest date on which the Project Proponent (or a predecessor entity under continuous authority) undertook irreversible actions committing to project implementation.

The earliest of the following may constitute the Project Start Date:

• commencement of physical implementation or installation;

• signing of binding implementation or procurement contracts;

• financial closure or execution of financing agreements;

• construction, commissioning, or mobilization of core project equipment;

• commencement of operational activities that generate mitigation outcomes.

Non-binding actions (e.g., feasibility studies, preliminary MOU, R&D, pilot installations) do not constitute a Project Start Date.

B.2.2 Evidence Required to Establish the Start Date

The Project Proponent shall submit documentary evidence supporting the declared start date, potentially including:

• dated invoices or purchase orders;

• signed contracts;

• bank transfer records for equipment procurement;

• regulatory permits with activation dates;

• construction or commissioning logs;

• photographs with metadata;

• official notifications or governmental documents.

All evidence must be clear, time-stamped, and verifiable.

B.2.3 Acceptability of the Start Date

A start date is acceptable only if:

• it is properly evidenced;

• the project meets additionality requirements despite the start date;

• no methodological start-date restrictions are violated;

• the baseline remains valid given the timing of implementation;

• safeguards and SDG assessments are consistent with project history.

PCS may reject a start date if documentation is insufficient or contradictory.

B.2.4 Start Date Clarifications and Disputes

Where uncertainty exists regarding the true Project Start Date:

• the PCS Secretariat may request additional evidence;

• the VVB may recommend a revised date;

• PCS may apply a conservative interpretation based on earliest plausible evidence.

The Secretariat’s determination is final.

B.3 Crediting Period Rules

B.3.1 Definition

The Crediting Period is the fixed duration during which a project is authorized to generate PCS Carbon Credits (PCCs), subject to monitoring and verification.

The crediting period begins on the later of:

• the date of PCS registration; or

• the date the project begins generating measurable emission reductions or removals.

Unless otherwise provided by a methodology, crediting during pre-registration periods is not permitted.

B.3.2 Crediting Period Length

Crediting period length is set by the methodology. Default ranges include:

Project Type	Crediting Period	Renewal Allowed?
Emission Reduction (non-AFOLU)	7–10 years	Yes
AFOLU / Nature-Based	20–30 years	Yes
CCS / BECCS / DACCS	10–15 years	Yes
Distributed/Household Technologies	5–7 years	Yes
Emerging Technologies	As per methodology	Yes

Where the methodology specifies a fixed duration, that duration applies without modification.

B.3.3 Conditions for Commencing the Crediting Period

The crediting period may commence only when:

• the project is fully registered under PCS;

• monitoring systems are operational;

• baseline conditions are established and validated;

• safeguards and SDG assessments are completed;

• no unresolved material non-conformities exist.

If monitoring begins after registration, the Project Proponent may request a delayed crediting start, subject to PCS approval.

B.3.4 Suspension or Delay in Crediting Start

Crediting cannot begin if:

• monitoring systems are incomplete;

• calibration procedures have not been completed;

• safeguard mitigation plans are not yet implemented;

• operational testing periods affect data integrity;

• the baseline cannot yet be applied.

PCS may delay the crediting start until compliance is achieved.

B.4 Crediting Period Renewal

B.4.1 Renewal Requirements

To renew a crediting period, the Project Proponent must:

• undergo full revalidation under PCS-STD-004;

• update baseline conditions in accordance with Annex C;

• update safeguard and SDG assessments per PCS-STD-003;

• update monitoring plans to reflect current conditions;

• demonstrate continued additionality;

• comply with any Host Party updates relevant to the activity.

Renewal may not be granted if any requirement is not met.

B.4.2 Renewal Frequency

Renewals occur at the end of each crediting period. PCS may limit the number of allowable renewals based on:

• methodology rules;

• technology category;

• permanence concerns;

• Host Party regulations.

B.4.3 Baseline Update at Renewal

A baseline update is mandatory, ensuring that:

• new regulations or market conditions are reflected;

• improved technologies or practices are evaluated;

• updated emission factors are applied;

• new Host Party or scientific data are incorporated.

B.4.4 Impact of Renewal on Additionality

Additionality must be re-demonstrated using:

• updated regulatory review;

• common practice assessment;

• financial or barrier tests where required;

• methodology-specific tools.

If additionality cannot be demonstrated, renewal is denied.

B.4.5 Consequences of Renewal Failure

If renewal is denied:

• the project becomes ineligible for further crediting;

• existing issued credits remain valid unless fraud or misrepresentation is found;

• the project may resubmit if circumstances materially change.

B.5 Material Changes Affecting Crediting Periods

B.5.1 Material Change Trigger

Material changes affecting:

• additionality,

• baseline conditions,

• project boundaries,

• technology,

• safeguards, or

• monitoring systems

may require revision of the crediting period or revalidation.

B.5.2 Suspension of Crediting Period

PCS may suspend crediting if:

• monitoring evidence is unreliable;

• unresolved material non-conformities exist;

• safeguard violations occur;

• double counting risks arise;

• Host Party revokes necessary permits.

Suspension remains in effect until corrective actions are verified.

B.6 Transparency And Documentation

B.6.1 Registry Disclosure

The PCS Registry shall disclose:

• Project Start Date;

• Crediting Period start and end dates;

• renewal decisions;

• suspensions or terminations;

• relevant documentation.

B.6.2 Data Retention

Project Proponents must retain all timing-relevant documents for:

• the entire crediting period, AND

• seven years after project termination.

B.7 Final Determination Authority

The PCS Secretariat shall make all final determinations regarding:

• the acceptability of Project Start Dates;

• the commencement of the crediting period;

• renewal approvals or denials;

• suspensions, delays, or terminations.

The Secretariat may impose additional requirements if necessary to preserve environmental integrity.

Annex C - Baseline Setting Framework

C.1 Purpose of This Annex

This Annex defines the mandatory technical framework for establishing baselines under the Planetary Carbon Standard (PCS).

It supplements Chapter 6 – Baseline Requirements by specifying baseline-setting procedures, data requirements, evidence standards, update rules, calculation approaches, and treatment of uncertainty.

Baseline determination must ensure that emission reductions or removals credited under PCS represent genuine climate benefits and reflect what would occur in the absence of the project.

This Annex applies to all projects unless superseded by specific methodology provisions.

C.2 Baseline Setting Principles

Baselines must be established in accordance with the following principles:

1. Plausibility — The baseline must reflect realistic conditions expected under business-as-usual (BAU) scenarios.

2. Conservativeness — Baseline assumptions shall err on the side of underestimating rather than overestimating baseline emissions.

3. Completeness — All relevant emission sources, sinks, and reservoirs required by the methodology must be included.

4. Transparency — All data sources, formulas, assumptions, and evidence must be documented in the Project Design Document (PDD).

5. Consistency — Baseline boundaries must align with project boundaries unless explicitly justified.

6. Relevance — Baseline parameters must reflect current or recent conditions and use the most relevant Host Party data.

7. Replicability — VVBs must be able to independently recalculate and confirm baseline values.

C.3 Baseline Types Under PCS

PCS methodologies may employ one or more baseline types:

C.3.1 Historical Baseline

Derived from actual historical data (e.g., average emissions over a defined period).

C.3.2 Performance Standard Baseline

Based on benchmarks, emission factors, or standardised values approved by PCS.

C.3.3 Model-Based Baseline

Based on modelling tools, simulations, or projected conditions.

C.3.4 Default Baseline

Uses pre-approved default factors from Host Party data, regional data, or international sources.

C.3.5 Hybrid Baseline

Combination of multiple approaches (e.g., historical + performance benchmark).

C.3.6 Jurisdictional or Grid-Based Baseline

Common for renewables, electricity displacement, and large-scale sector approaches.

A project must follow the type(s) required by the applicable methodology.

C.4 Required Baseline Components

The baseline must contain, at minimum:

• baseline scenario description;

• baseline boundary (aligned with project boundary);

• baseline emissions sources and sinks;

• baseline activity data;

• applicable emission factors;

• modelling or calculation approaches;

• data sources and evidence;

• uncertainty treatment;

• vintage and validity periods of data;

• demonstration of consistency with Host Party policies.

C.5 Baseline Data Requirements

C.5.1 Data Sources

Acceptable baseline data include:

• historical activity data (e.g., energy use, production records);

• national statistics or Host Party datasets;

• utility or grid operator data;

• satellite imagery or remote sensing outputs;

• scientific literature;

• recognized technical databases (IPCC, FAO, IEA, etc.);

• industrial performance benchmarks;

• monitoring records from similar installations.

C.5.2 Data Quality Criteria

Baseline data must be:

• recent (within defined time windows);

• relevant to the project context;

• consistent with internationally accepted sources;

• traceable to original publications or databases;

• complete and internally consistent.

C.5.3 Evidence Requirements

Evidence supporting baseline data may include:

• invoices, logs, utility bills;

• operating records;

• regulatory or permitting documents;

• peer-reviewed studies;

• expert reports;

• geospatial datasets.

Unsupported or anecdotal claims cannot be used.

C.6 Baseline Scenario Identification

The baseline scenario must represent the most plausible alternative scenario absent the project. The selection process shall:

1. Identify all credible alternatives;

2. Evaluate alternatives using criteria defined in the methodology;

3. Assess feasibility, regulatory requirements, and technological availability;

4. Select the most plausible alternative using conservative judgment;

5. Exclude alternatives that are clearly unrealistic or technically infeasible.

Each alternative must be clearly assessed and justified.

C.7 Calculation of Baseline Emissions or Removals

The Project Proponent shall apply:

• formulas prescribed in the methodology;

• approved emission factors;

• conversion factors consistent with IPCC standards;

• required default values and coefficients;

• uncertainty adjustments and discount factors.

All calculations must be:

• reproducible,

• transparent,

• traceable to raw inputs,

• validated by the VVB.

C.7.1 Table C-1 – Minimum Calculation Requirements

Category	Requirement
Activity data	Representative, complete, supported by evidence
Emission factors	Approved by methodology or Host Party
Conversion factors	IPCC or recognized scientific values
Equations	Exactly as per methodology
Units	Consistent, with conversions explicitly shown
Uncertainty	Addressed conservatively

C.8 Treatment of Uncertainty

Uncertainty in baseline parameters shall be treated using:

• methodology-defined uncertainty factors;

• conservative assumptions where uncertainty cannot be resolved;

• statistical analysis where required;

• sensitivity analyses for critical parameters.

Where uncertainty is significant, the Project Proponent must apply discounting or conservative substitution.

C.9 Baseline Validity and Vintage

Baseline parameters must reflect conditions within:

• the methodology-defined data vintage window;

• the specified historical time period;

• the applicable Host Party policy environment.

Where methodologies specify vintage limits (e.g., 3 years), older data may not be used unless accompanied by strong justification.

C.10 Baseline Updates During Crediting Period

Certain methodologies require dynamic baselines. When required:

• updates must follow the methodology schedule;

• evidence for updated parameters must be provided;

• VVB must validate updated values;

• updated calculations must be included in Monitoring Reports.

Dynamic adjustments may include:

• annual grid emission factor updates;

• market penetration adjustments;

• regulatory shifts;

• modelled projections.

C.11 Baseline Reassessment at Crediting Period Renewal

At renewal, the Project Proponent must:

• reassess baseline scenario;

• update baseline parameters;

• incorporate new regulatory requirements;

• update default factors;

• consider new market and technology developments;

• provide updated evidence.

Failure to provide updated baseline assessments leads to denial of renewal.

C.12 Baseline for AFOLU and Nature-Based Projects

AFOLU baselines must include:

• carbon pools (biomass, soil, deadwood, litter);

• land-use change drivers;

• historical land-use trends;

• reference region or leakage belt analyses;

• reversals and permanence considerations.

AFOLU-specific rules are detailed in Annex E.

C.13 Special Provisions for Engineered Removals (CCS, DACCS, BECCS)

Baselines must evaluate:

• fossil or industrial CO₂ streams;

• counterfactual emissions without capture;

• storage permanence and reservoir integrity;

• energy and operational emissions associated with removal facilities.

Methodologies may specify specialized modeling or engineering analyses.

C.14 Transparency Requirements

All baseline-related information must be disclosed in the PDD and include:

• data sources;

• references;

• calculation sheets;

• assumptions;

• model descriptions;

• QA/QC steps;

• justification for exclusions.

The PCS Registry publishes all relevant baseline information.

C.15 VVB Responsibilities

VVBs must:

• evaluate all baseline evidence;

• review alternative scenarios;

• recalculate baseline emissions;

• verify data sources and modeling;

• classify non-conformities;

• confirm conservativeness;

• document all findings in the Validation Report.

Any baseline deficiency is generally classified as a material non-conformity.

C.16 PCS Secretariat Final Determination

The PCS Secretariat shall:

• approve or reject baseline scenarios;

• require corrections or revalidation;

• request further evidence;

• consider Host Party policy updates;

• ensure consistency across projects and methodologies.

Baseline approval is a prerequisite for project registration.

Annex D - Leakage Assessment Framework

D.1 Purpose of This Annex

This Annex establishes the technical procedures and requirements for assessing leakage under the Planetary Carbon Standard (PCS). It supplements Chapter 7 – Leakage Assessment by providing:

• detailed identification procedures,

• leakage boundary rules,

• quantification methods,

• evidence requirements,

• monitoring rules,

• mitigation requirements,

• and deduction procedures.

Leakage must be assessed for every project unless the applicable methodology explicitly states that leakage is negligible or not applicable.

D.2 Leakage Principles

All leakage assessments shall adhere to the following principles:

1. Causality: Leakage must be assessed only to the extent that it is a direct or indirect result of the project.

2. Comprehensiveness: All plausible leakage pathways must be identified and evaluated.

3. Conservativeness: Where uncertainty exists, leakage estimates must err on the side of overestimating emissions.

4. Transparency: All assumptions, data sources, and calculations must be fully documented.

5. Consistency: Leakage estimation must be consistent with project boundaries and methodology requirements.

6. Traceability: Evidence supporting leakage analysis must be well-documented and verifiable.

D.3 Leakage Identification Framework

The Project Proponent must perform a structured assessment to identify all potential leakage pathways. This includes:

D.3.1 Activity-Shifting Leakage

Occurs when project participants relocate emissions-causing activities outside the project boundary. E.g., shifting deforestation, shifting cultivation, waste relocation, fuelwood collection displacement.

D.3.2 Market Leakage

Occurs when project-driven changes in production or supply cause emissions elsewhere. E.g., reduced timber supply leading to increased imports or logging elsewhere.

D.3.3 Emission Displacement Leakage

Occurs when operational emissions move geographically. E.g., relocating machinery, transport routings, or waste streams.

D.3.4 Upstream Leakage

Occurs when upstream activities increase emissions. E.g., transport or supply-chain emissions associated with new equipment.

D.3.5 Downstream Leakage

Occurs when downstream changes cause emissions. E.g., substitution effects or changes in consumption patterns.

D.4 Leakage Boundary Determination

The leakage boundary extends beyond the project boundary and must include:

• all zones where displaced activities may occur;

• markets or supply chains that may be indirectly affected;

• households or communities shifting behavior due to the project;

• landscapes or jurisdictions impacted by land-use changes;

• regions relevant for imported/exported goods or services.

Leakage boundaries may be geographic, sectoral, or market-based depending on project type.

D.5 Evidence Requirements

Leakage identification must be supported by credible and verifiable evidence, such as:

• historical production, consumption, or land-use patterns;

• market analyses for commodities (e.g., timber, charcoal, fuel, agricultural products);

• remote sensing data;

• socioeconomic surveys;

• government or statistical data;

• community consultations;

• supply-chain mapping;

• scientific or academic studies.

All evidence must be:

• traceable,

• time-relevant,

• complete,

• and appropriate for the leakage type being assessed.

Unsupported assumptions are not acceptable.

D.6 Leakage Quantification Requirements

Leakage emissions must be quantified following methodology requirements. Quantification may involve:

• emission factor-based calculations;

• leakage coefficients defined by the methodology;

• econometric or market modeling;

• geospatial analysis for AFOLU projects;

• survey-based estimation for household or distributed technologies;

• direct measurement, where applicable.

Leakage calculations must include:

• clear formulas;

• emission factors;

• activity data;

• conservative adjustments;

• uncertainty treatment.

Where multiple options exist, the most conservative approach must be selected.

D.7 Leakage Mitigation Requirements

Projects must include a Leakage Mitigation Plan that describes:

• expected leakage pathways;

• mitigation measures;

• community or stakeholder engagement;

• alternative livelihood or fuel programs;

• land-use planning;

• supply-chain interventions.

Mitigation measures should be proactive and context-specific.

Common mitigation strategies include:

• providing alternative biomass sources;

• supporting sustainable agriculture;

• involving communities in forest protection;

• income diversification programs;

• monitoring and enforcement in leakage belts.

D.8 Deduction of Leakage Emissions

Leakage emissions quantified under this Annex must be deducted from project emission reductions/removals as per the applicable methodology.

General formula:

Net Emission Reductions = Gross Emission Reductions − Leakage Emissions

If leakage exceeds gross reductions, the net value is zero. Negative values are permitted in reporting but do not reduce previously issued credits.

PCS does not issue credits for net negative periods.

D.9 Special Requirements for AFOLU Projects

AFOLU projects have higher leakage risks, including:

• deforestation displacement;

• agricultural activity shifting;

• grazing pressure relocation;

• fuelwood displacement;

• illegal logging displacement;

• community-level leakage.

AFOLU projects must:

• define a Leakage Belt (area outside boundary for monitoring leakage);

• conduct community-based assessments;

• assess land-use drivers;

• integrate socio-economic surveys;

• analyze historical land-use change and future trends;

• include leakage indicators in monitoring.

These requirements are mandatory and cannot be waived.

D.10 Special Requirements for Household / Distributed Technologies

Leakage for distributed technologies (e.g., cookstoves, water purifiers, SHS) may occur due to:

• stacking behavior

• non-displacement of baseline fuel

• use of multiple technologies simultaneously

• resale or relocation of units

Monitoring shall include:

• usage surveys;

• stacking analysis;

• technology retention assessments;

• fuel-use monitoring.

Sampling procedures under Annex G apply.

D.11 Monitoring Leakage Over Time

Leakage must be monitored for the entire crediting period. Monitoring shall include:

• surveys and interviews;

• geospatial analysis;

• market monitoring;

• biomass or fuel production assessments;

• periodic leakage belt assessments;

• supply-chain review.

Monitoring frequency is determined by the methodology but must be sufficient to detect changes.

D.12 Reporting Requirements

Monitoring Reports must include:

• leakage identification results;

• quantification calculations;

• mitigation measures implemented;

• monitoring data for leakage indicators;

• uncertainty treatment;

• supporting evidence;

• maps or geospatial outputs where applicable.

VVBs must review and validate all leakage-related documentation.

D.13 Verification Requirements

VVBs must confirm:

• completeness of leakage identification;

• appropriateness of leakage boundary;

• accuracy and conservativeness of leakage calculations;

• sufficiency of mitigation measures;

• implementation of leakage monitoring;

• classification of leakage-related non-conformities;

• consistency of reported leakage across monitoring periods.

Leakage errors are generally classified as material non-conformities.

D.14 Renewal Requirements

At crediting period renewal, the Project Proponent must:

• reassess leakage pathways;

• re-evaluate market and behavioral dynamics;

• update leakage modeling;

• adjust leakage mitigation strategies;

• update evidence.

Failure to update leakage assessments may result in denial of renewal.

D.15 PCS Secretariat Determination

The PCS Secretariat shall make the final determination on:

• adequacy of leakage identification;

• completeness and acceptability of evidence;

• validity of quantification;

• necessity of corrective measures;

• approval of leakage deductions.

The Secretariat may require revalidation if leakage risks materially change.

Annex E - AFOLU & Nature-Based Solutions (NBs) Sector Requirements

E.1 Purpose of This Annex

This Annex establishes the mandatory requirements for Agriculture, Forestry, and Other Land Use (AFOLU) and Nature-Based Solutions (NBS) mitigation activities under the Planetary Carbon Standard (PCS).

It supplements the core Project Standard and applies in addition to:

• PCS methodologies for AFOLU/NBS,

• PCS-STD-003 (Safeguards & SDG Integrity),

• PCS-STD-004 (Validation & Verification), and

• Annexes A–D (Additionality, Crediting Periods, Baselines, Leakage).

AFOLU/NBS projects present heightened risks and complexities, including land tenure, high uncertainty, multi-stakeholder dynamics, and permanence concerns.

This Annex therefore establishes a unified AFOLU/NBS framework based on IPCC guidance, jurisdictional best practice, and PCS integrity criteria.

E.2 AFOLU/NBS Activity Categories

PCS recognizes the following AFOLU/NBS categories:

E.2.1 Avoided Emissions

• Avoided deforestation (REDD)

• Avoided forest degradation

• Avoided conversion of natural ecosystems

• Avoided peatland degradation

• Avoided grassland conversion

E.2.2 Enhanced Carbon Stocks / Removals

• Afforestation and reforestation (A/R)

• Sustainable forest management (SFM)

• Improved forest restoration

• Regenerative agriculture

• Soil carbon enhancement

• Wetland restoration and conservation

• Blue carbon (mangroves, seagrasses, salt marshes)

E.2.3 Agricultural Mitigation

• Improved livestock management

• Methane-reducing feed strategies

• Rice water management

• Manure management

• Emissions-reducing cropping practices

E.2.4 Hybrid or Landscape Approaches

• Community forest management

• Landscape mosaic interventions

• Integrated land-use jurisdictional projects

Each project must apply the methodology corresponding to its AFOLU/NBS type.

E.3 Land Tenure and Rights Requirements

E.3.1 Mandatory Documentation

Projects must demonstrate:

• clear, legal, or customary land rights;

• documented free, prior, and informed consent (FPIC) where Indigenous communities are involved;

• community agreements for communal or customary lands;

• no unresolved land disputes in project areas.

E.3.2 Acceptable Land Tenure Evidence

• Land titles or deeds

• Government allotment records

• Customary tenure recognition documents

• Community land governance records

• Formal FPIC documentation

PCS will not register projects with unresolved tenure conflicts or ambiguous rights.

E.4 AFOLU Baseline Requirements

AFOLU baselines must reflect:

• historic land-use change;

• land-use drivers;

• carbon stock trends;

• ecosystem types;

• socio-economic conditions;

• legal and policy frameworks;

• remote sensing–supported analyses.

E.4.1 Minimum Baseline Components

A compliant AFOLU baseline must include:

• a Reference Region (RR) or Stratification Unit;

• land-use transition matrices;

• carbon pools included/excluded;

• historical satellite-based land-cover maps (minimum 5–10 years);

• deforestation/land-degradation risk models;

• carbon stock estimates for each stratum;

• uncertainty assessment.

E.4.2 Mandatory Carbon Pools

Unless methodology allows otherwise, the following pools must be included:

• Aboveground biomass (AGB)

• Belowground biomass (BGB)

• Deadwood

• Litter

• Soil organic carbon (SOC) (if significant)

• Harvested wood products (HWP), where relevant

Carbon pools may only be excluded with robust justification.

E.5 Monitoring Requirements for AFOLU/NBS

Monitoring for AFOLU projects shall include:

E.5.1 Land-Cover and Activity Monitoring

• annual or biennial remote sensing analysis;

• geospatial land-use change detection;

• forest canopy cover mapping;

• identification of degradation hot-spots;

• ground truthing surveys.

E.5.2 Carbon Stock Monitoring

• periodic field measurements using accepted forest inventory protocols;

• biomass allometric equations following IPCC standards;

• soil core sampling protocols for SOC projects;

• uncertainty analysis for all carbon pools.

E.5.3 Community and Agricultural Monitoring

• household surveys;

• livestock or grazing pressure monitoring;

• agricultural productivity and practice changes;

• leakage belt monitoring (see below).

E.6 Leakage Requirements (AFOLU Specific)

AFOLU projects must implement an expanded leakage framework beyond Annex D. This includes:

E.6.1 Leakage Belt Definition

A Leakage Belt is a mapped area outside the project boundary where leakage risks are assessed and monitored. It must reflect:

• socio-economic linkages;

• adjacency to project area;

• patterns of resource extraction or land conversion.

E.6.2 Monitoring Requirements

The Project Proponent must:

• use remote sensing (e.g., NDVI, forest loss mapping);

• monitor fuelwood and grazing displacement;

• conduct surveys in adjacent communities;

• track illegal logging or encroachment risks.

E.6.3 Leakage Quantification

Leakage may be quantified via:

• standardized coefficients;

• modeled land-use change;

• activity-based quantification;

• empirical remote sensing detection;

• conservative assumptions.

AFOLU leakage must be deducted from net emission reductions.

E.7 Permanence and Reversal Risk Management

AFOLU/NBS projects face inherent risks of carbon stock loss. PCS requires robust permanence measures.

E.7.1 Risk Assessment

Projects must prepare a Reversal Risk Assessment addressing:

• natural risks (fire, pests, drought, storms);

• anthropogenic risks (illegal logging, land conversion, conflict);

• socio-economic factors (community dependence on resources);

• governance risks (weak enforcement);

• project management risks.

E.7.2 Buffer Contribution

Projects must contribute a portion of verified reductions/removals to a PCS AFOLU Buffer Pool, based on their risk profile.

Risk tiers typically range:

Risk Tier	Buffer Contribution
Low	5–10%
Medium	10–20%
High	20–30%

Exact values are defined in the applicable methodology.

E.7.3 Reversal Events

If reversals occur:

• unintentional reversals are compensated using buffer units;

• intentional reversals require unit reversal and may lead to project suspension.

E.8 Safeguards and Social Requirements (AFOLU-Specific)

Projects must comply with PCS safeguards (STD-003) and additional AFOLU requirements:

Mandatory Social Provisions

• FPIC for Indigenous Peoples;

• meaningful stakeholder engagement;

• grievance mechanism accessible to local communities;

• community benefit-sharing plan for revenue distribution;

• mapping of vulnerable groups and mitigation measures.

Land-User Participation

• clear description of participating landowners/users;

• transparent benefit-sharing agreements;

• avoidance of elite capture or inequitable resource distribution.

E.9 Uncertainty Treatment

AFOLU projects must apply strict uncertainty treatment using:

• IPCC Tier 2 or Tier 3 approaches for key categories;

• Monte Carlo simulation where required;

• conservative default factors for uncertain parameters;

• transparent inventory of uncertainty sources.

If total uncertainty exceeds methodology thresholds, deductions must be applied.

E.10 Field Measurement and Plot Design

Plot design must follow:

• stratified random sampling;

• fixed or temporary sample plots;

• repeated measurements at fixed intervals;

• adequate sample size to ensure required confidence levels;

• standardized measurement protocols.

Biomass equations must be scientifically recognized and peer-reviewed.

E.11 Remote Sensing Requirements

Remote sensing must:

• use high-resolution imagery (minimum 10–30 m);

• apply consistent classification methods across periods;

• include accuracy assessments (confusion matrices, Kappa coefficient);

• use cloud-filtered, seasonally aligned imagery;

• incorporate ground-truth data.

E.12 Reporting Requirements

AFOLU Monitoring Reports must include:

• updated land-use maps;

• forest cover change assessments;

• carbon stock measurement reports;

• reversal monitoring;

• leakage belt analysis;

• community and safeguard monitoring results;

• metadata and geospatial files.

All geospatial datasets must be provided in GIS format.

E.13 Verification Requirements

The VVB must:

• conduct field inspections and plot re-measurement;

• verify remote sensing analysis;

• verify carbon calculations;

• interview communities where relevant;

• verify FPIC documentation;

• validate leakage belt results;

• classify non-conformities related to permanence or safeguards.

AFOLU verification requires personnel with demonstrated land-use and forestry expertise.

E.14 PCS Secretariat Oversight

PCS retains authority to:

• require third-party technical reviews;

• request additional geospatial data;

• increase buffer contributions;

• suspend issuance if reversal risk is high;

• impose corrective actions for safeguard non-compliance.

Annex F - Digital Monitoring & Blockchain Integration Requirements

F.1 Purpose of This Annex

This Annex establishes the mandatory requirements for the design, operation, verification, and integration of digital monitoring systems and blockchain-backed data integrity mechanisms under the Planetary Carbon Standard (PCS). It supplements Chapters 8 (Monitoring), 11 (Transparency & Record Keeping), and is applicable to all project types that:

• use automated monitoring devices (sensors, IoT units, meters);

• rely on digital MRV platforms or mobile applications;

• utilize remote sensing or geospatial data pipelines;

• store or anchor monitoring records using cryptographic or blockchain technologies.

PCS encourages digital monitoring as a means of improving accuracy, traceability, and transparency, but imposes strict integrity requirements to prevent manipulation or system-driven risk.

F.2 Definitions (Specific to This Annex)

For the purposes of this Annex:

1. Digital Monitoring Systems — Automated or semi-automated systems that collect, process, or transmit monitoring data (e.g., IoT devices, sensors, mobile data capture, remote sensing platforms).

2. Digital Ledger Anchoring — The process of storing cryptographic hashes or metadata on a blockchain to ensure immutability, timestamping, and tamper-evident record-keeping.

3. Primary Digital Evidence — Source-level data generated directly by a digital device (e.g., meter readings, temperature logs, GPS-tagged images).

4. System Metadata — Non-emissions data needed to validate digital records such as device IDs, timestamps, firmware versions, and calibration tags.

These terms apply only within the scope of this Annex.

F.3 Eligibility Requirements for Digital Monitoring Systems

A project may use digital monitoring systems only if the systems:

• Generate traceable, auditable records linked to specific devices or users;

• Store data in immutable or tamper-evident formats (via blockchain anchoring or equivalent safeguards);

• Have documented QA/QC processes, including device diagnostics;

• Enable VVB access to raw digital logs and metadata;

• Ensure secure transmission of data from device to storage;

• Include redundancy measures to prevent data loss.

If these conditions are not met, digital data may not be used as primary evidence.

F.4 Device Requirements for IoT and Sensor-Based Monitoring

All digital devices must meet the following requirements:

F.4.1 Device Identification

Every device must have:

• a unique hardware ID;

• immutable firmware or logged version changes;

• serial number traceable to procurement documentation.

F.4.2 Calibration

Devices must:

• be calibrated according to manufacturer or recognized standards;

• maintain a calibration log;

• undergo recalibration at defined intervals;

• store calibration metadata alongside monitoring data.

F.4.3 Anti-Tampering Measures

Devices must incorporate:

• tamper detection;

• secure communication protocols (e.g., SSL/TLS);

• encrypted firmware where applicable;

• physical security measures appropriate to context.

Tamper-evident seals or embedded audit logs may be required for high-risk technologies.

F.5 Blockchain Anchoring Requirements

Projects using blockchain-integrated monitoring must adhere to the following:

F.5.1 Minimum Anchoring Requirements

Blockchain anchoring must include:

• hash of original data files;

• timestamp;

• device ID or data source ID;

• monitoring period reference;

• versioning information.

Anchoring may be done:

• at the point of data generation (preferred), OR

• upon ingestion into the project’s monitoring platform.

F.5.2 Accepted Blockchain Types

PCS accepts:

• public blockchains,

• permissioned blockchains,

• consortium chains approved by PCS.

Private, centrally controlled ledgers without immutability guarantees are not acceptable.

F.5.3 Tamper-Evidence and Auditability

The blockchain record must allow PCS and VVBs to:

• verify data integrity;

• detect changes to original files;

• confirm submission timestamps;

• ensure transparent version histories.

F.6 Data Management Requirements

Projects must maintain a digital data management system that:

• securely stores raw and processed data;

• retains metadata for all records;

• ensures chronological sequencing;

• uses access controls to prevent unauthorized modification;

• maintains audit logs;

• uses backups and redundancy measures.

All data must be available to the VVB.

F.7 Remote Sensing and Geospatial Data Requirements

Where remote sensing is used for monitoring:

• raw satellite or drone imagery must be retained;

• geospatial files (e.g., shapefiles, GeoJSON) must be included;

• accuracy assessments must be provided (confusion matrices, Kappa scores);

• time-series consistency must be demonstrated;

• atmospheric and cloud filtering must be documented.

Ground truthing is mandatory unless a methodology explicitly waives it.

F.8 Mobile Data Capture Requirements

Mobile applications used for monitoring must:

• assign a unique user ID per enumerator;

• store GPS coordinates of data entries;

• store timestamps and device metadata;

• prevent post-submission editing or flag such edits in logs;

• include offline capturing capabilities with synchronization logs;

• maintain clear chain-of-custody for survey or household-level data.

F.9 Audit Trails

A complete audit trail must be maintained for:

• all device-generated data;

• any manual adjustments;

• any gaps in automated monitoring;

• all data processing steps;

• any recalculations or post-processing steps.

Audit trails must be immutable and accessible to VVBs.

F.10 Data Loss, Corruption, or System Failure

If digital monitoring data is:

• lost,

• corrupted,

• incomplete,

• unavailable due to device failure,

the Project Proponent must:

1. Notify PCS and the VVB;

2. Implement conservative substitutes as permitted by the methodology;

3. Document the reason for data gaps;

4. Provide correction factors or backup data sources;

5. Perform root-cause analysis.

Intentional manipulation or negligent data loss is treated as a material non-conformity.

F.11 Verification of Digital Monitoring Systems

During verification, the VVB must:

• inspect device procurement and calibration documents;

• confirm device identity and metadata;

• review blockchain or cryptographic anchors;

• test device outputs against manual measurements;

• validate geospatial datasets;

• review system architecture documentation;

• interview technicians or enumerators;

• test audit logs and error logs;

• perform sample-based testing of raw digital files.

Digital systems that fail verification may not be used as primary evidence.

F.12 Cybersecurity Requirements

Digital monitoring systems must incorporate cybersecurity measures including:

• encryption at rest and in transit;

• secure authentication mechanisms;

• anti-malware protection;

• access-control lists;

• secure storage of private keys for blockchain anchoring;

• documented incident response procedures.

PCS may require third-party cybersecurity audits for large-scale or high-risk digital MRV systems.

F.13 Transparency and Registry Integration

The PCS Registry shall store:

• cryptographic hashes of digital monitoring batches;

• metadata summaries;

• device lists;

• system architecture descriptions;

• audit logs where non-sensitive;

• references to blockchain records.

This ensures public auditability and transparency.

F.14 System Updates, Firmware Changes, and Replacements

Projects must report major updates to digital systems including:

• firmware upgrades;

• device replacements;

• software version changes;

• platform migrations;

• modifications to blockchain anchoring methods.

Any change affecting data integrity or comparability may require revalidation.

F.15 PCS Secretariat Determination

The PCS Secretariat shall:

• approve or reject digital monitoring systems;

• conduct targeted digital audits;

• require enhanced monitoring;

• impose corrective actions;

• revoke digital monitoring privileges where manipulation risks are detected.

PCS reserves the right to prohibit use of any digital tool that undermines environmental integrity.

Annex G - Household & Distributed Technology Sampling Guide

G.1 Purpose of This Annex

This Annex establishes the methodological and procedural requirements governing sampling design, implementation, and verification for household-level and distributed technology projects under the Planetary Carbon Standard (PCS).

It supplements the monitoring requirements in Chapter 8 and applies to mitigation activities involving:

• improved cookstoves (ICS),

• household water treatment/purification systems (HWTS),

• solar home systems (SHS),

• solar lighting,

• improved heating technologies,

• household biogas digesters,

• micro-scale renewable technologies,

• household energy efficiency interventions,

• community-level distributed solutions.

Sampling provides statistically robust evidence for estimating usage, adoption, technology performance, and emissions-related behaviors across large or dispersed populations.

This Annex ensures consistency, precision, and conservativeness in sampling approaches.

G.2 Sampling Principles

Sampling must follow the principles of:

1. Representativeness: The sample must accurately reflect the project population.

2. Randomization: Sample selection must avoid bias; random or stratified-random selection is required.

3. Statistical Validity: Samples must meet minimum confidence and precision levels defined in this Annex or the methodology.

4. Traceability: Sample selection and data collection must be transparent and reproducible.

5. Conservativeness: Statistical uncertainty must result in conservative deductions.

6. Replicability: Sampling steps must allow VVB replication.

G.3 Definitions

1. Project Population: All households or units eligible or participating in the project.

2. Sampling Frame: The complete list or database of households/units from which the sample is drawn.

3. Sample Unit: A household, technology unit, or end-user selected for monitoring.

4. Cluster: A grouping of sample units used to simplify sampling logistics.

5. Stratum / Strata: Subdivided groups of the population used in stratified sampling (e.g., urban/rural, region-based, technology variant).

6. Enumeration: The process of collecting data from sampled units via surveys, sensors, or observations.

G.4 Required Sampling Methods

PCS permits three sampling designs:

G.4.1 Simple Random Sampling (SRS)

Every unit in the population has an equal probability of being selected.

Used when the project population is homogeneous.

G.4.2 Stratified Random Sampling

Population is divided into strata, and samples are randomly drawn within each stratum.

Used when:

• usage patterns differ by region, culture, or socio-economic group;

• different technology models or versions are deployed;

• clustering of households may bias a simple random sample.

G.4.3 Cluster Sampling

Clustering of households is permitted for logistical efficiency but must still meet statistical requirements.

Used when:

• population is geographically dispersed,

• cost of simple random sampling is prohibitive,

• community-level grouping is necessary.

Cluster sampling may require increased sample sizes to maintain precision.

G.5 Confidence & Precision Requirements

Minimum statistical requirements for household/distributed sampling:

Parameter	Requirement
Confidence Level	90% (minimum); 95% preferred
Relative Precision	±10% (minimum); ±7.5% preferred
Design Effect (DEFF)	Must be accounted for in sample size calculations
Non-Response Rate Adjustment	Required and documented

Methodologies may prescribe stricter requirements.

G.6 Sample Size Determination

Sample size must be calculated using:

G.6.1 Standard Sample Size Formula

where:

• n = sample size

• Z = Z-score for confidence level

• p = expected proportion or usage parameter

• e = relative precision requirement

G.6.2 Design Effect Adjustment

For cluster or stratified sampling:

Adjust sample size by DEFF.

G.6.3 Non-Response Adjustment

Where NR = anticipated non-response rate.

The Project Proponent must justify all assumptions.

G.7 Sampling Frame Requirements

Sampling frames must:

• include all eligible population units;

• avoid duplication or omissions;

• be updated annually;

• include GPS coordinates or unique identifiers;

• be stored in digital format with audit trails;

• be accessible for VVB review.

Incomplete or biased sampling frames constitute a material non-conformity.

G.8 Household Surveys and Enumerator Requirements

Where manual surveys are used:

G.8.1 Enumerator Training

Enumerators must be trained in:

• survey protocols;

• technology functioning;

• ethical conduct and consent procedures;

• GPS capture;

• photo evidence capture;

• digital data entry methods.

G.8.2 Survey Tools

Surveys must:

• follow a pre-approved Monitoring Plan;

• include relevant usage and stacking questions;

• capture timestamps, GPS, and enumerator ID;

• include photographs where required.

G.8.3 Consent Requirements

Projects must:

• obtain informed consent from respondents;

• ensure confidentiality of personal data;

• comply with Host Party privacy laws.

G.9 Sampling for Usage Monitoring

Usage parameters may include:

• frequency of device use;

• usage hours;

• fuel consumption;

• stacking with baseline technologies;

• adoption or abandonment of units.

Monitoring must occur:

• at least once per monitoring period;

• more frequently where methodologies require.

Usage monitoring must rely on:

• surveys;

• sensors (temperature, motion, etc.);

• smart meters;

• mobile data capture.

Where sensors are used, Annex F also applies.

G.10 Sampling for Performance Parameters

Performance parameters (e.g., thermal efficiency of cookstoves) must be sampled using:

• laboratory testing for design performance;

• field testing for in-situ performance;

• sampling protocols aligned with methodology;

• representative device selection.

Performance sampling must meet the same confidence and precision criteria as usage sampling.

G.11 Stacking Behavior Assessment

Stacking assessments must:

• quantify the use of baseline devices alongside project devices;

• measure the proportion of baseline fuel displaced;

• identify multi-device households;

• evaluate seasonal and cultural variations.

If stacking is significant, deductions must be made conservatively.

G.12 Data Quality and Management

Sampling data must be:

• stored digitally;

• backed up securely;

• version-controlled;

• tracked through audit logs;

• anchored to the PCS Registry where digital tools apply;

• retained for verification.

Sampling errors must be identified and corrected before submission.

G.13 Verification Requirements

The VVB must:

• assess sampling methodology;

• verify sample size calculations;

• replicate sampling frame selection;

• conduct spot-check surveys;

• verify GPS and timestamp metadata;

• evaluate digital records and photographs;

• classify non-conformities relating to sampling bias or error;

• recalculate sample-based estimates.

Sampling deficiencies often constitute material non-conformities.

G.14 Treatment of Outliers, Missing Data, and Non-Response

G.14.1 Outliers

Outliers must be:

• evaluated for validity;

• excluded only with justification;

• treated conservatively.

G.14.2 Missing Data

Missing data must be:

• documented with cause;

• handled with conservative substitution;

• never fabricated or estimated without basis.

G.14.3 Non-Response

Non-response must be:

• monitored;

• incorporated into final sample size calculation;

• adjusted conservatively.

G.15 Documentation Requirements

The sampling report must include:

• sampling frame documentation;

• sample size calculations;

• sampling design description;

• enumerator training records;

• survey tools;

• data processing methods;

• evidence of randomization;

• raw datasets;

• quality-control steps.

The Monitoring Report must incorporate these results.

G.16 PCS Secretariat Determination

The PCS Secretariat shall:

• review sampling methods for compliance;

• require corrections for bias, error, or insufficient sample size;

• suspend issuance if sampling integrity is compromised;

• require re-sampling where results are unreliable;

• impose enhanced monitoring requirements for high-risk projects.

PCS may reject the use of sampling entirely for projects failing to maintain required integrity.