PCS MN 002 Program Manual_v2.0

Document Control

Document identification

• Document code: PCS-MN-002

• Title: Program Manual

• Scope: Defines PCS operational procedures, roles and decision authority, project lifecycle stages (submission through issuance and post-registration), document hierarchy and precedence, versioning rules, and process controls for consistent administration.

• Program outcome: Establishes binding procedural rules for how PCS standards, methodologies, tools, templates, and governance procedures are applied in practice.

Version history and change log

Table DC-1. Revision history

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

Superseded versions

v1.0 — superseded upon approval of v2.0.

Governance note on versioning and archiving

Only the latest approved version of this Program Manual shall be used for administering PCS processes. Superseded versions shall be archived and retained for traceability and audit purposes. Unless PCS states otherwise through transition provisions, the applicable version is the version in force at the time of submission of the relevant project action (e.g., registration, monitoring period, post-registration change).

Acronyms and Abbreviations

Acronym	Full Term
CCS	Carbon Capture and Storage
DACCS	Direct Air Carbon Capture and Storage
ESS	Environmental and Social Safeguards
GHG	Greenhouse Gas
LOA	Letter of Authorization
MA	Methodology (PCS-MA / PCS-MT series)
MT	Methodology – Technology Track
NBS	Nature-Based Solutions
PCS	Planetary Carbon Standard
PCC	Planetary Carbon Credit
PMR	Project Monitoring Report
PRC	Post-Registration Change
PSF	Project Submission Form
SDG	Sustainable Development Goal
TA	Methodological Tool (PCS-TA series)
VVB	Validation and Verification Body

Chapter 1 - Introduction and Scope

1.1 Purpose of the Manual

1

Overview

The PCS Operational Process Manual establishes the operational procedures governing the implementation of the Planetary Carbon Standard (PCS) version 2.0. It defines the end-to-end processes, decision pathways, institutional roles, and document interactions that apply throughout the full lifecycle of PCS projects, from submission through issuance, post-registration changes, and closure.

2

Objectives

The purpose of this manual is to ensure consistency, transparency, and integrity in the administration of PCS by clearly describing how approved standards, methodologies, tools, and templates are applied in practice. It provides a single, authoritative reference for how PCS operates as a system.

3

Scope relative to other PCS documents

This manual does not replace or restate PCS standards, methodologies, or tools. Instead, it explains how those documents are operationalised, reviewed, and enforced within the PCS governance framework.

1.2 Scope of Application

1. This manual applies to all projects, methodologies, tools, and administrative processes governed under PCS version 2.0. It is binding on all participants involved in the PCS system, including:

• Project Developers submitting projects for registration under PCS

• Validation and Verification Bodies (VVBs) approved by PCS

• Host Country Authorities issuing Letters of Authorization where applicable

• The PCS Secretariat and decision-making bodies

• Other stakeholders engaged in review, oversight, or implementation roles

1. The procedures described herein apply across all PCS project types, including Nature-Based Solutions (NBS), carbon removal activities, carbon capture and storage (CCS), and technology-based emission reduction activities, unless explicitly stated otherwise in a relevant methodology or procedure.

1.3 Relationship to Other PCS Documents

1. The PCS documentation framework consists of multiple layers, each serving a distinct function. This manual operates at the system and process level and must be read in conjunction with the following categories of PCS documents:

• PCS Framework and Standards, which define eligibility, integrity principles, and high-level requirements

• PCS Methodologies (PCS-MA / PCS-MT series), which define activity-specific accounting rules and applicability conditions

• PCS Methodological Tools (PCS-TA series), which provide calculation procedures, risk assessment frameworks, and monitoring techniques

• PCS Templates and Forms, which standardise data submission, reporting, and verification

• PCS Governance Procedures, which define approval, grievance, appeal, and oversight mechanisms

1. Where inconsistencies arise between this manual and a PCS standard, methodology, or approved tool, the higher-order normative document shall prevail.

1.4 Binding Nature and Authority

1. Compliance with this manual is mandatory for all PCS participants. Failure to follow the procedures defined herein may result in delayed registration, suspension of project activities, revision requests, corrective actions, or other administrative measures in accordance with PCS governance procedures.

2. The PCS Secretariat is responsible for administering and enforcing the procedures described in this manual. Decisions taken in accordance with this manual are subject to the grievance and appeal mechanisms established under PCS.

1.5 Intended Audience

1. This manual is intended for a professional audience with responsibility for implementing, reviewing, or overseeing PCS projects. This includes, but is not limited to:

• Project Developers and project management teams

• Validation and Verification Bodies

• PCS Secretariat staff and committee members

• Host Country Authorities and designated focal points

• Institutional partners and stakeholders engaged in PCS governance

1. The manual is written to balance technical precision with operational clarity, enabling both executive-level oversight and detailed procedural understanding.

1.6 Version Control and Applicability

1. This manual applies to PCS version 2.0 and remains in force until formally amended or replaced. Revisions to this manual may be issued by PCS to reflect procedural refinements, governance updates, or clarifications, without altering the underlying integrity principles of PCS.

2. The applicable version of this manual is the version in force at the time of project submission, unless otherwise specified in transition or amendment provisions.

Chapter 2 - PCS System Architecture and Document Hierarchy

2.1 Overview of the PCS System Architecture

1. The Planetary Carbon Standard operates as an integrated system composed of interdependent normative documents, technical instruments, and administrative processes. Each component of the PCS architecture performs a specific function and is applied at a defined point within the project lifecycle. This chapter establishes a clear hierarchy among PCS documents and explains how standards, methodologies, tools, templates, and procedures interact to ensure consistency, transparency, and environmental integrity.

2. PCS is structured to separate policy intent, technical rules, operational procedures, and project-level implementation. This separation ensures that updates to one component, such as a methodological tool or reporting template, can occur without undermining the stability of the overall system.

2.2 Hierarchical Structure of PCS Documents

1. PCS documentation is organised into five principal tiers. Each tier has a distinct role and authority within the system.

2. At the highest level are the PCS Framework and Standards. These documents define the core principles, eligibility criteria, integrity safeguards, and governance requirements that apply across all project types. They establish what is permitted under PCS and the conditions under which credits may be issued.

3. Below the standards sit the PCS Methodologies. Methodologies define activity-specific rules for quantifying emission reductions or removals. They specify applicability conditions, baseline determination approaches, monitoring requirements, and calculation boundaries for specific project types such as forestry, mangroves, CCS, or technology-based mitigation activities. Methodologies do not operate independently; they must be applied in accordance with the overarching PCS standards.

4. Methodological Tools form the next layer of the system. Tools provide standardised calculation procedures, risk assessment frameworks, and measurement techniques that are referenced by one or more methodologies. Tools are modular by design and may be reused across multiple methodologies. Examples include non-permanence risk assessment tools, sampling tools, and carbon stock estimation tools. Tools do not establish eligibility; they operationalise technical requirements defined elsewhere.

5. Templates and Forms constitute the implementation layer of PCS. These documents standardise how information is submitted, reported, and reviewed. Templates translate methodological and procedural requirements into structured data formats that enable consistent assessment by Validation and Verification Bodies and the PCS Secretariat.

6. Operational Procedures and Manuals, including this document, define how all other components are applied in practice. They describe process sequencing, decision authority, review responsibilities, and escalation pathways. Procedural documents do not redefine technical rules but govern how those rules are administered.

2.3 Functional Separation of Documents

1. Each category of PCS documentation serves a distinct function and must be applied only within its intended scope. Standards establish requirements, methodologies explain how to meet those requirements for specific activities, tools provide calculation or assessment mechanisms, templates capture information in a consistent format, and procedures govern review and decision-making.

2. This functional separation is intentional. It prevents duplication, reduces regulatory ambiguity, and allows PCS to evolve over time without compromising system coherence. For example, a methodological tool may be updated to reflect improved scientific understanding without requiring amendments to unrelated methodologies or standards.

2.4 Relationship Between Methodologies and Tools

1. PCS methodologies reference methodological tools where standardised calculations or assessments are required. A methodology may require the application of one or more tools, such as a non-permanence risk assessment tool or a carbon stock estimation tool, depending on project characteristics.

2. Tools do not override methodological requirements. Instead, they operationalise specific components of those requirements. Where a tool is referenced by a methodology, its use is mandatory unless an approved deviation is granted in accordance with PCS procedures.

2.5 Role of Templates and Forms in the PCS Architecture

1. Templates and forms serve as the primary interface between project developers and the PCS system. They ensure that all required information is presented in a consistent, auditable, and reviewable format. Templates are designed to align directly with the requirements of methodologies, tools, and procedures.

2. The use of approved PCS templates is mandatory unless explicitly stated otherwise. Custom formats or alternative reporting structures are not permitted unless approved through the PCS deviation process.

2.6 Authority and Precedence of Documents

1. In the event of inconsistencies among PCS documents, the following order of precedence applies:

Order of Precedence	Document Category
1	PCS Framework and Standards
2	PCS Methodologies
3	PCS Methodological Tools
4	PCS Operational Procedures and Manuals
5	PCS Templates and Forms

1. This hierarchy ensures that technical and procedural interpretations remain anchored to formally approved standards and methodologies.

2.7 System Integrity and Controlled Evolution

1. The PCS architecture is designed to support controlled evolution. New methodologies, tools, or templates may be introduced, and existing documents may be revised, provided that such changes follow approved PCS governance procedures. Changes at lower tiers of the hierarchy must not conflict with higher-order requirements.

2. This approach allows PCS to respond to scientific advances, regulatory developments, and market needs while maintaining the stability and credibility of issued Planetary Carbon Credits.

Chapter 3 - Roles, Responsibilities, and Decision Authority

3.1 Overview

1. The Planetary Carbon Standard operates through a defined allocation of responsibilities among participating entities. Clear separation of roles is essential to preserve independence, avoid conflicts of interest, and ensure the integrity of decision-making throughout the PCS project lifecycle. This chapter defines the responsibilities and authority of each actor involved in the implementation and governance of PCS.

2. All roles described in this chapter are binding and must be exercised in accordance with PCS standards, methodologies, tools, and procedures. No entity may assume responsibilities outside those formally assigned.

3.2 Project Developer

1. The Project Developer is the entity responsible for designing, implementing, and maintaining a project in accordance with PCS requirements. The Project Developer bears full responsibility for the accuracy, completeness, and consistency of all information submitted to PCS throughout the project lifecycle.

2. This responsibility includes preparation and submission of the Project Submission Form, selection and application of an approved PCS methodology, implementation of monitoring systems, preparation of Monitoring Reports, completion of safeguard and SDG assessments, and submission of all supporting evidence. The Project Developer is also responsible for ensuring that all required methodological tools, including risk assessment tools, are correctly applied and updated.

3. The Project Developer remains accountable for the project after registration, including during monitoring periods, verification cycles, post-registration changes, and any events affecting permanence or eligibility.

3.3 Validation and Verification Bodies

1. Validation and Verification Bodies are independent third parties approved by PCS to conduct validation and verification activities. VVBs must operate in accordance with PCS approval procedures and applicable accreditation requirements.

2. During validation, the VVB assesses whether the project design complies with PCS standards, the selected methodology, and all applicable tools and procedures. This includes review of eligibility, baseline selection, monitoring plans, safeguard assessments, and risk assessment inputs.

3. During verification, the VVB assesses Monitoring Reports, verifies reported emission reductions or removals, reviews updates to risk assessments, and evaluates the implementation of mitigation measures. VVBs must exercise professional judgment, maintain independence from the Project Developer, and document all findings transparently.

4. VVBs do not approve projects or issue credits. Their role is to provide an independent opinion that informs PCS decision-making.

3.4 PCS Secretariat

1. The PCS Secretariat is responsible for the day-to-day administration of the PCS system. The Secretariat manages project intake, conducts completeness and procedural reviews, coordinates public consultation processes, assigns VVBs, and prepares decisions for formal approval.

2. The Secretariat ensures that submissions comply with PCS procedures and that all required documentation is present before advancing projects through each stage of the lifecycle. It also manages communications with Project Developers and VVBs, maintains official records, and administers the PCS Registry.

3. The Secretariat does not replace independent validation or verification. Its role is administrative, coordinative, and procedural, ensuring that all PCS processes are applied consistently.

3.5 PCS Decision-Making Bodies

1. PCS decision-making bodies, as defined in PCS governance documents, are responsible for formal approvals, rejections, suspensions, and other regulatory determinations. These bodies review recommendations prepared by the Secretariat and consider validation or verification opinions provided by VVBs.

2. Decision-making bodies may request additional information, impose conditions, or require corrective actions before approving a project or issuance. Their authority extends to post-registration changes, handling of reversals, application of buffer mechanisms, and enforcement actions.

3. Decisions taken by PCS decision-making bodies are binding, subject only to grievance and appeal procedures.

3.6 Host Country Authorities

1. Where applicable, Host Country Authorities play a role in confirming national authorization and alignment with national policies. This may include issuance of Letters of Authorization, confirmation of ownership, or acknowledgement of participation in international mechanisms.

2. Host Country Authorities do not validate project design or verify emission reductions. Their role is limited to sovereign confirmation functions as defined in applicable PCS procedures and international requirements.

3.7 Separation of Roles and Conflict Management

1. PCS enforces strict separation between project development, validation, verification, and decision-making functions. No entity may simultaneously perform conflicting roles within the same project. This includes prohibitions on VVBs providing consultancy services to projects they validate or verify.

2. Any actual or potential conflicts of interest must be disclosed and managed in accordance with PCS procedures. Failure to disclose conflicts may result in disqualification, suspension, or other enforcement measures.

3.8 Accountability and Enforcement

1. All entities operating under PCS are accountable for their actions and decisions. Non-compliance with PCS requirements may result in corrective actions, suspension of activities, revision requests, or other measures as defined in PCS governance procedures.

2. Enforcement actions are proportionate to the severity and nature of the non-compliance and are applied consistently across all project types.

Chapter 4 - PCS Project Lifecycle and Process Flow

4.1 Overview of the PCS Project Lifecycle

1. The PCS project lifecycle defines the sequence of procedural steps through which a project progresses, from initial submission to issuance of Planetary Carbon Credits and subsequent post-registration administration. Each stage of the lifecycle is governed by defined procedural controls, document requirements, and decision points designed to ensure transparency, consistency, and environmental integrity.

2. Projects must progress through the lifecycle in the order defined in this chapter. Advancement to a subsequent stage is permitted only after completion of all requirements applicable to the preceding stage.

4.2 Project Submission and Intake

1

Submission

The lifecycle begins when a Project Developer submits a Project Submission Form and all required supporting documentation through the PCS Registry. Submissions must identify the applicable PCS methodology, relevant methodological tools, proposed monitoring approach, safeguard assessments, and any required host country authorizations.

2

Completeness review

Upon receipt, the PCS Secretariat conducts a completeness review to confirm that all mandatory documents have been submitted and that the submission is internally consistent. This review does not assess technical validity or methodological correctness. Its sole purpose is to ensure readiness for eligibility assessment.

3

Corrections

Submissions that fail the completeness review are returned to the Project Developer with a request for correction. Only complete submissions proceed to eligibility review.

4.3 Eligibility Review

1. Following confirmation of completeness, the PCS Secretariat conducts an eligibility review to assess whether the proposed project falls within the scope of PCS Framework version 2.0 and the selected methodology. This review confirms methodological applicability, sectoral eligibility, exclusion criteria, and alignment with PCS integrity requirements.

2. The eligibility review does not constitute validation. It establishes whether the project is eligible to proceed through the PCS process. Projects deemed ineligible are rejected with documented justification.

4.4 Public Consultation

1. Projects that pass eligibility review enter a public consultation period. During this stage, project information is made publicly available through the PCS Registry for stakeholder review and comment.

2. The Project Developer is required to address all substantive comments received during the consultation. Responses must be documented and submitted prior to validation. The PCS Secretariat reviews consultation responses to confirm that issues have been adequately addressed before validation proceeds.

4.5 Validation

1. Upon completion of public consultation, the PCS Secretariat assigns an approved Validation and Verification Body to conduct validation. The VVB performs an independent assessment of the project design against PCS standards, the applicable methodology, and all referenced tools.

2. Validation includes review of baseline selection, monitoring plans, safeguard assessments, risk assessments, and consistency across submitted documentation. Any identified non-conformities must be addressed through corrective actions before a positive validation opinion may be issued.

3. The validation outcome is documented in a Validation Report submitted to the PCS Secretariat.

4.6 Registration Decision

1. Following receipt of a positive validation opinion, the PCS Secretariat prepares a registration recommendation for formal decision. The decision-making body reviews the recommendation and supporting documentation and issues a registration decision.

2. If approved, the project is registered in the PCS Registry and assigned a unique project identifier. Registration authorises the project to commence monitored implementation under PCS but does not guarantee issuance.

4.7 Project Implementation and Monitoring

1. After registration, the Project Developer implements the project in accordance with the registered project design and monitoring plan. Monitoring activities must follow the requirements defined in the applicable methodology and tools.

2. At the end of each monitoring period, the Project Developer prepares a Monitoring Report documenting implemented activities, monitored data, safeguard performance, and updates to risk assessments. Monitoring Reports must be submitted through the PCS Registry for review.

4.8 Verification

1. Monitoring Reports are subject to verification by an approved VVB. Verification assesses the accuracy of reported data, the application of methodologies and tools, and the implementation of mitigation and management measures.

2. Verification includes review of updated non-permanence risk inputs, monitoring evidence, safeguard performance, and consistency with previously approved project documentation. Any discrepancies must be resolved before verification is concluded.

3. The verification outcome is documented in a Verification Report submitted to the PCS Secretariat.

4.9 Issuance of Planetary Carbon Credits

1. Upon receipt of a positive verification opinion, the PCS Secretariat proceeds with issuance. Verified emission reductions or removals are converted into Planetary Carbon Credits and recorded in the PCS Registry.

2. Each issued unit is assigned a unique serial number and permanently recorded. Issuance may be subject to buffer deductions, limitations, or conditions arising from risk assessments or other PCS requirements.

4.10 Post-Registration Changes

1. Projects may undergo changes after registration that affect project design, implementation, or eligibility. Such changes must be reported through the Post-Registration Change process and approved before implementation where required.

2. Post-registration changes may trigger reassessment, validation, or verification depending on their materiality. Unauthorized changes may result in suspension or corrective action.

4.11 Project Continuation, Suspension, or Closure

1. Projects may continue through successive monitoring periods for the duration of their approved crediting period. Projects may also be suspended or withdrawn due to non-compliance, unresolved risks, or voluntary termination by the Project Developer.

2. Closure occurs when a project reaches the end of its crediting period, is permanently withdrawn, or is terminated by PCS in accordance with governance procedures.

4.12 Summary of Lifecycle Stages

Lifecycle Stage	Primary Output
Submission	Project Submission Form
Eligibility Review	Eligibility determination
Public Consultation	Consultation record
Validation	Validation Report
Registration	Registered project status
Monitoring	Monitoring Report
Verification	Verification Report
Issuance	Planetary Carbon Credits
Post-Registration Changes	Approved change decision
Closure	Project closure record

Chapter 5 - Governance of Methodologies and Methodological Tools

5.1 Purpose and Scope

1. This chapter defines how methodologies and methodological tools are governed, applied, and maintained within the Planetary Carbon Standard. It establishes the rules for their development, approval, use, revision, and interaction with project-level processes. The objective is to ensure that all technical instruments applied under PCS are scientifically robust, consistently applied, and subject to controlled evolution.

2. The provisions of this chapter apply to all PCS-approved methodologies and methodological tools, regardless of project type or sector.

5.2 Role of Methodologies within PCS

1. PCS methodologies define the activity-specific rules for quantifying emission reductions or removals. Each methodology specifies eligibility conditions, system boundaries, baseline determination approaches, monitoring requirements, calculation procedures, and applicability of methodological tools.

2. A methodology establishes the technical logic under which a project may claim mitigation outcomes. It does not, by itself, govern procedural steps such as submission, validation, or issuance. Those processes are governed by this Operational Process Manual and related procedures.

3. Only methodologies formally approved under PCS may be used for project registration. Project Developers must select a methodology that is fully applicable to the proposed activity and must demonstrate compliance with all methodological requirements throughout the project lifecycle.

5.3 Role of Methodological Tools within PCS

1. Methodological tools provide standardised procedures for calculations, measurements, and assessments that are required by one or more methodologies. Tools are designed to be modular and reusable, enabling consistent application of technical rules across multiple methodologies.

2. Within PCS, methodological tools support functions such as estimation of carbon stocks, quantification of emissions, sampling design, assessment of non-permanence risk, and evaluation of mitigation effectiveness. Tools do not establish eligibility or crediting rules. Their role is to operationalise specific technical elements referenced by methodologies.

3. Where a methodology references a specific methodological tool, use of that tool is mandatory unless an approved deviation has been granted in accordance with PCS procedures.

5.4 Relationship Between Methodologies and Tools

1. Methodologies and tools operate in a defined and hierarchical relationship. A methodology may reference one or more tools to perform specific calculations or assessments. Tools may be referenced by multiple methodologies, but they cannot contradict methodological requirements.

2. If an inconsistency arises between a methodology and a referenced tool, the methodology prevails unless the tool has been explicitly updated and approved to supersede the earlier requirement. Any such updates must follow PCS governance procedures.

3. This relationship ensures methodological clarity while allowing technical components to be updated independently when justified by scientific or operational advancements.

5.5 Application of Methodologies and Tools at Project Level

1. At the project level, the selected methodology defines which tools must be applied and at what stage of the project lifecycle. Project Developers are responsible for correctly applying all required tools and for maintaining consistency between tool outputs and project documentation.

2. Methodological tools may be applied at multiple stages, including project design, validation, monitoring, verification, and post-registration change assessment. Outputs from tools form part of the evidentiary basis for validation and verification opinions.

3. Failure to apply a required tool correctly, or failure to update tool outputs when project conditions change, constitutes non-compliance with PCS requirements.

5.6 Approval and Revision of Methodologies and Tools

1. All methodologies and methodological tools must be approved through formal PCS governance procedures before use. Approval decisions are based on technical soundness, consistency with PCS standards, and operational feasibility.

2. Revisions to methodologies or tools may be initiated to reflect scientific advances, regulatory changes, or implementation experience. Revisions must follow approved PCS procedures for development, review, and approval. Until a revised version enters into force, the previously approved version remains applicable.

3. PCS may also issue clarifications to methodologies or tools where interpretation issues arise, without altering substantive requirements.

5.7 Controlled Evolution and Version Management

1. PCS maintains strict version control for methodologies and tools. Each approved document carries a version identifier and effective date. Project Developers must apply the version in force at the time of project submission unless transition provisions apply.

2. Changes to methodologies or tools do not automatically apply retroactively. Transition rules may be defined to manage the application of revised documents to registered projects in a manner that preserves regulatory certainty and environmental integrity.

5.8 Deviations and Exceptional Cases

1. Where strict application of a methodology or tool is not feasible due to project-specific circumstances, a Project Developer may request a deviation in accordance with PCS deviation procedures. Deviations are exceptional and must be justified with clear technical rationale.

2. Approval of a deviation does not establish precedent and does not alter the approved methodology or tool. Deviations apply only to the specific project and circumstances approved.

5.9 Integrity and Consistency Across PCS

1. The governance framework described in this chapter ensures that methodologies and tools are applied consistently across all PCS projects. This consistency underpins the credibility of issued Planetary Carbon Credits and supports transparency, comparability, and trust among stakeholders.

Chapter 6 - Safeguards, SDG Integration, and Integrity Controls

6.1 Purpose and Scope

1. Safeguards and sustainable development considerations are integral components of the Planetary Carbon Standard. This chapter defines how environmental and social safeguards, as well as Sustainable Development Goal contributions, are assessed, monitored, and enforced throughout the PCS project lifecycle. The objective is to ensure that mitigation activities do not result in environmental or social harm and that claimed co-benefits are credible, transparent, and verifiable.

2. The provisions of this chapter apply to all PCS projects unless explicitly exempted by an approved methodology.

6.2 Environmental and Social Safeguards Framework

1. PCS applies a structured environmental and social safeguards framework to identify, assess, and manage potential adverse impacts associated with project activities. Safeguard assessment begins at the project design stage and continues throughout implementation and monitoring.

2. Project Developers are required to complete the PCS Environmental and Social Safeguards Form as part of project submission. This assessment identifies potential risks related to land use, biodiversity, water resources, community rights, labour conditions, and stakeholder engagement. The safeguards assessment must reflect project-specific conditions and must be supported by appropriate evidence.

3. Safeguards are not treated as a one-time screening exercise. Projects are required to monitor safeguard performance during each monitoring period and to report any material changes, incidents, or emerging risks.

6.3 Integration of Safeguards into Validation and Verification

1. Safeguard assessments are reviewed during validation to confirm that risks have been adequately identified and that mitigation measures are appropriate and feasible. Validation focuses on the completeness and credibility of the safeguards assessment and on the adequacy of proposed management measures.

2. During verification, VVBs assess safeguard performance based on monitoring data, evidence of implementation, and any reported incidents. Verification includes confirmation that mitigation measures remain effective and that no unreported adverse impacts have occurred.

3. Failure to adequately manage safeguard risks may result in corrective actions, suspension of issuance, or other enforcement measures.

6.4 Sustainable Development Goal Assessment

1. PCS supports the transparent reporting of sustainable development contributions associated with project activities. Project Developers are required to complete the PCS SDG Impact Assessment Form, which identifies expected and achieved contributions to relevant Sustainable Development Goals.

2. SDG assessment under PCS is based on measurable indicators and qualitative evidence. Claims must be proportionate, realistic, and supported by documentation. The SDG assessment does not influence eligibility or credit quantity but serves as an integrity and transparency mechanism.

3. SDG information is reviewed during validation for plausibility and during verification for consistency with monitored outcomes.

6.5 Management of Adverse Impacts and Corrective Actions

1. Where safeguard risks materialise or adverse impacts occur, Project Developers are required to implement corrective actions promptly. Such actions may include additional mitigation measures, remediation activities, or changes to project operations.

2. Material safeguard incidents must be reported to the PCS Secretariat without delay. Depending on severity, incidents may trigger additional review, targeted verification, or temporary suspension of issuance.

3. PCS decision-making bodies retain authority to impose conditions, require remedial actions, or suspend projects where safeguard breaches are not adequately addressed.

6.6 Relationship to Methodologies and Tools

1. Safeguard and SDG assessments operate alongside, but independently from, emission quantification methodologies and tools. While safeguard outcomes do not alter emission calculations directly, they influence the eligibility of issuance and the continued acceptance of project outcomes under PCS.

2. Where methodological tools identify risks that overlap with safeguard considerations, such as non-permanence or governance risk, information may be cross-referenced to ensure consistency.

6.7 Transparency and Disclosure

1. Safeguard and SDG information submitted under PCS forms part of the project record. Summary information may be disclosed through the PCS Registry to support transparency and stakeholder confidence, subject to confidentiality and data protection requirements.

2. Transparency does not replace due process. Public disclosure complements formal validation, verification, and enforcement mechanisms.

6.8 Enforcement and Integrity Assurance

1. The safeguards and SDG framework contributes to the overall integrity of PCS by ensuring that mitigation outcomes are not achieved at the expense of environmental or social harm. Enforcement actions related to safeguard non-compliance are governed by PCS procedures and may include corrective actions, issuance restrictions, or project suspension.

Chapter 7 - Validation, Verification, and Issuance Controls

7.1 Purpose and Scope

1. This chapter defines the controls governing validation, verification, and issuance under the Planetary Carbon Standard. These controls ensure that emission reductions or removals are independently assessed, accurately quantified, and issued only after all technical, procedural, and integrity requirements have been satisfied. Validation and verification are central to PCS credibility and operate as independent assurance mechanisms within the PCS governance framework.

7.2 Validation Process and Scope

1. Validation is the independent assessment of a project’s design prior to registration. The purpose of validation is to confirm that the project complies with PCS standards, the selected methodology, and all applicable methodological tools and procedures.

2. During validation, the Validation and Verification Body evaluates eligibility, methodological applicability, baseline determination, monitoring arrangements, safeguard assessments, and initial risk assessments. Validation includes confirmation that all required tools, including non-permanence risk tools where applicable, have been correctly applied and that assumptions are transparent and justified.

3. Validation does not assess monitored outcomes or issue credits. Its role is to establish whether the project is eligible to be registered and implemented under PCS.

7.3 Verification Process and Scope

1. Verification is the independent assessment of monitored data and reported outcomes for a defined monitoring period. Verification confirms that emission reductions or removals have occurred as reported and that they have been quantified in accordance with PCS methodologies and tools.

2. Verification includes review of Monitoring Reports, assessment of data quality, confirmation of calculation accuracy, evaluation of safeguard performance, and review of updates to risk assessments. Verification also assesses whether mitigation and management measures have been implemented as described.

3. Verification is conducted for each monitoring period for which issuance is requested. A positive verification opinion is a prerequisite for issuance.

7.4 Integration of Risk Assessment into Validation and Verification

1. Risk assessment is an integral component of both validation and verification for applicable project types. During validation, risk assessment establishes the baseline risk profile and informs initial buffer requirements. During verification, updated risk inputs reflect changes in project conditions, management practices, or external factors.

2. Validation and Verification Bodies must confirm that risk tools have been applied correctly, that supporting evidence is credible, and that updates are consistent with observed conditions. Where risk profiles change materially, issuance outcomes may be adjusted in accordance with PCS requirements.

7.5 Issuance Decision Controls

1. Issuance of Planetary Carbon Credits occurs only after receipt of a positive verification opinion. Issuance decisions are taken by the PCS Secretariat or designated decision-making body based on verified outcomes, compliance status, and applicable integrity controls.

2. Issuance may be subject to deductions, buffers, or limitations arising from risk assessments, safeguard considerations, or procedural requirements. Issuance does not occur automatically upon verification; it remains subject to final administrative confirmation.

3. Each issued unit is uniquely serialised and permanently recorded in the PCS Registry.

7.6 Conditional Issuance and Restrictions

1. In certain circumstances, issuance may be subject to conditions. These may include partial issuance, delayed issuance, or issuance subject to corrective actions. Conditions may be applied where minor non-conformities exist, provided they do not undermine the validity of verified outcomes.

2. Material non-conformities must be resolved prior to issuance. Where unresolved issues remain, issuance may be withheld or denied.

7.7 Independence and Quality Assurance

1. Validation and verification activities must be conducted independently and without conflict of interest. PCS approval procedures for VVBs establish eligibility, competence requirements, and quality assurance expectations.

2. PCS may conduct oversight reviews of validation and verification activities to ensure consistency, competence, and adherence to PCS procedures. Persistent quality issues may result in corrective actions or suspension of VVB approval.

7.8 Recordkeeping and Transparency

1. All validation and verification reports form part of the official project record and are retained in the PCS Registry. Summary information may be disclosed to support transparency and market confidence, subject to confidentiality requirements.

2. Recordkeeping ensures that all issuance decisions are traceable, auditable, and defensible over time.

Chapter 8 - Post-Registration Changes, Reversals, and Exceptional Events

8.1 Purpose and Scope

1. Projects registered under the Planetary Carbon Standard may experience changes or events after registration that affect project design, implementation, or the permanence of credited outcomes. This chapter defines the procedures governing post-registration changes, reversal events, and other exceptional circumstances that arise during the crediting period. The objective is to ensure that such events are managed transparently, consistently, and in a manner that preserves the integrity of issued and future Planetary Carbon Credits.

2. The provisions of this chapter apply to all PCS projects throughout their operational life, including during monitoring periods, issuance cycles, and post-issuance oversight.

8.2 Definition of Post-Registration Changes

1. A post-registration change is any modification to a registered project that may affect its eligibility, quantified outcomes, risk profile, safeguards performance, or compliance status. Such changes may arise intentionally, for example through project expansion or operational adjustments, or unintentionally due to external developments.

2. Post-registration changes are categorised based on their materiality. Material changes are those that may affect emission reduction or removal calculations, baseline assumptions, risk assessments, safeguard outcomes, or methodological applicability. Non-material changes are administrative or operational adjustments that do not influence these core elements.

3. The classification of a change determines the level of review required prior to implementation.

8.3 Post-Registration Change Request Process

1. All material post-registration changes must be submitted to PCS through the Post-Registration Change Request process. The Project Developer is required to document the nature of the change, provide justification, and submit any updated documentation necessary to assess its implications.

2. Upon submission, the PCS Secretariat conducts a procedural review to determine whether the proposed change requires validation, verification, or both. Where technical reassessment is required, an approved Validation and Verification Body is assigned to evaluate the change.

3. No material change may be implemented until approval has been granted. Implementation of unapproved changes constitutes non-compliance and may result in corrective actions or suspension.

8.4 Review and Approval of Post-Registration Changes

1. The review of post-registration changes focuses on assessing whether the project remains compliant with PCS standards, methodologies, and tools following the proposed modification. This includes reassessment of baseline conditions, monitoring approaches, safeguard implications, and risk profiles.

2. Approval decisions are taken by PCS decision-making bodies based on recommendations prepared by the Secretariat and supported by validation or verification opinions where required. Approved changes are recorded in the PCS Registry and become part of the project’s official record.

8.5 Reversal Events and Carbon Loss

1. A reversal event is any event that results in the unintentional or unavoidable loss of credited carbon stocks or mitigation outcomes. Reversals may occur due to natural disturbances, anthropogenic actions, governance failures, or unforeseen external factors.

2. Project Developers are required to identify, document, and report reversal events promptly. Reporting must include a description of the event, the affected area or component, the estimated magnitude of carbon loss, and supporting evidence.

3. Reversal events trigger reassessment of project risk profiles and may affect buffer requirements, future issuance, or crediting eligibility.

8.6 Treatment of Reversals and Buffer Application

1. PCS applies buffer mechanisms to manage the risk of non-permanence. Where a reversal occurs, the magnitude of the carbon loss is assessed through verification and applied against the project’s buffer contribution or other applicable integrity mechanisms.

2. The application of buffers does not absolve the Project Developer of responsibility. Projects must still implement corrective measures, strengthen mitigation strategies, and update risk assessments to prevent recurrence.

3. Repeated or unmanaged reversals may result in suspension of issuance or other enforcement actions.

8.7 Exceptional Events and Force Majeure

1. Exceptional events include circumstances beyond the reasonable control of the Project Developer that materially affect project performance or viability. These may include major natural disasters, armed conflict, or systemic governance failures.

2. PCS evaluates exceptional events on a case-by-case basis. The existence of an exceptional event does not automatically excuse non-compliance. Instead, PCS assesses the extent to which impacts were unavoidable and whether reasonable mitigation measures were in place.

3. Decisions related to exceptional events may include temporary suspension, revised monitoring requirements, adjusted issuance schedules, or, in extreme cases, project termination.

8.8 Impact on Issuance and Monitoring

1. Post-registration changes, reversals, and exceptional events may affect issuance eligibility for the affected monitoring period. Issuance may be reduced, delayed, or denied depending on the nature and severity of the event and the adequacy of the project’s response.

2. Monitoring requirements may be strengthened following significant events to improve detection, prevention, or mitigation of future risks.

8.9 Documentation and Recordkeeping

1. All post-registration changes, reversal events, and exceptional events must be documented and recorded in the PCS Registry. Documentation includes submissions, review outcomes, decisions, and any associated validation or verification reports.

2. This record ensures transparency, auditability, and traceability across the full project lifecycle.

8.10 Summary of Post-Registration Event Handling

Event Type	Approval Required	Verification Required	Impact on Issuance
Non-material change	No	No	None
Material change	Yes	Possibly	Conditional
Reversal event	Yes	Yes	Adjustment or deduction
Exceptional event	Case-specific	Case-specific	Suspension or adjustment

Chapter 9 - Registry, Recordkeeping, and Transparency

9.1 Purpose and Role of the PCS Registry

1. The PCS Registry functions as the authoritative system of record for all projects, documents, decisions, and units administered under the Planetary Carbon Standard. Its primary purpose is to ensure traceability, transparency, and integrity across the full lifecycle of PCS projects and Planetary Carbon Credits.

2. The Registry does not replace validation, verification, or governance processes. Instead, it records their outcomes and provides a secure, auditable environment in which PCS activities are documented and tracked over time.

9.2 Project Records and Documentation

1. For each registered project, the PCS Registry maintains a comprehensive project record. This record includes, at a minimum, the Project Submission Form, validation and verification reports, monitoring reports, safeguard and SDG assessments, post-registration change requests, and all related decisions.

2. Each document is linked to a specific project identifier and retained for the duration of the project’s crediting period and any additional retention period required by PCS governance procedures. Version history is preserved to ensure that prior submissions and decisions remain traceable.

3. The Registry serves as the single reference point for determining the official status of a project at any point in time.

9.3 Recording of Decisions and Administrative Actions

1. All formal PCS decisions are recorded in the Registry. These include eligibility determinations, registration decisions, issuance approvals, post-registration change approvals, suspensions, and closures.

2. Decision records identify the decision-making body, the date of the decision, any conditions applied, and references to supporting documentation. This ensures accountability and supports audit and review processes.

9.4 Unit Issuance and Serialisation

1. Planetary Carbon Credits issued under PCS are recorded in the Registry with unique serial identifiers. Serialisation enables each unit to be traced back to the originating project, monitoring period, verification report, and issuance decision.

2. The Registry records issuance quantities, buffer deductions where applicable, and the current status of each unit. Once issued, units remain permanently recorded and cannot be altered retroactively.

9.5 Status Tracking and Lifecycle Visibility

1. The Registry provides visibility into the lifecycle status of each project, including stages such as submitted, under validation, registered, under monitoring, verified, suspended, or closed.

2. This visibility supports procedural transparency and allows stakeholders to understand where a project sits within the PCS process without accessing confidential documentation.

9.6 Public Transparency and Disclosure

1. PCS supports transparency by making selected project information publicly accessible through the Registry. Publicly disclosed information may include project summaries, registration status, validation and verification outcomes, issuance quantities, and high-level safeguard and SDG information.

2. Disclosure is balanced against confidentiality obligations. Sensitive commercial information, personal data, and proprietary technical details are protected in accordance with PCS policies.

9.7 Data Integrity and Access Control

1. The PCS Registry applies access controls to ensure that users can only submit, modify, or view information consistent with their role. Project Developers, VVBs, and PCS administrators have defined permissions aligned with their responsibilities.

2. Data integrity is preserved through controlled submission processes, version control, and audit trails. Any corrections or updates to records must follow PCS procedures and are logged to maintain traceability.

9.8 Retention and Auditability

1. All records maintained in the Registry are retained in a manner that supports auditability and regulatory review. Historical records remain accessible for verification, dispute resolution, and retrospective analysis.

2. Retention practices ensure that PCS can reconstruct project histories, issuance decisions, and compliance actions if required.

9.9 Relationship to External Systems

1. Where PCS information is referenced externally, such as in public reporting or interoperability contexts, the PCS Registry remains the authoritative source. External representations do not supersede Registry records.

Chapter 10 - Grievance, Appeals, and Enforcement

10.1 Purpose and Scope

1. This chapter establishes the mechanisms through which grievances, appeals, and enforcement actions are managed under the Planetary Carbon Standard. These mechanisms ensure procedural fairness, accountability, and integrity by providing structured pathways to raise concerns, challenge decisions, and address non-compliance.

2. The provisions of this chapter apply to all PCS participants, including Project Developers, Validation and Verification Bodies, Host Country Authorities, and PCS administrative bodies.

10.2 Grievance Mechanism

1. PCS maintains a formal grievance mechanism through which stakeholders may raise concerns related to project activities, procedural conduct, safeguard impacts, or administrative decisions. Grievances may be submitted by affected communities, project participants, VVBs, or other stakeholders with a legitimate interest.

2. Grievances must be submitted in writing and must clearly describe the issue, the parties involved, and the relief sought. Upon receipt, the PCS Secretariat conducts an initial screening to confirm that the grievance falls within the scope of PCS and that sufficient information has been provided to enable review.

3. Where a grievance is admissible, it is recorded in the PCS Registry and assigned for review in accordance with applicable PCS procedures. The Secretariat may request additional information from the complainant or relevant parties as needed.

10.3 Review and Resolution of Grievances

1. Grievances are reviewed impartially and in accordance with defined timelines. The review process focuses on assessing whether PCS procedures, standards, or safeguards have been breached and whether corrective action is required.

2. Depending on the nature of the grievance, review may involve consultation with the Project Developer, the relevant VVB, Host Country Authorities, or other stakeholders. Findings and recommendations are documented and communicated to the parties involved.

3. Where a grievance is upheld, PCS may require corrective actions, impose conditions, or take other measures to address the identified issue. Where a grievance is not upheld, the decision and rationale are documented and communicated transparently.

10.4 Appeals Process

1. Appeals provide a formal mechanism to challenge PCS decisions, including registration decisions, issuance determinations, suspension actions, or other regulatory outcomes. Appeals may be submitted by Project Developers or other parties directly affected by a PCS decision.

2. An appeal must specify the decision being challenged, the grounds for appeal, and the relief sought. Appeals are limited to procedural or substantive errors and do not constitute a re-evaluation of project design or data unless such errors are demonstrated.

3. Appeals are reviewed by the designated PCS appeals body in accordance with PCS governance procedures. The appeals body operates independently from the original decision-making process to ensure impartiality.

10.5 Appeal Review and Outcomes

1. During appeal review, the appeals body assesses whether PCS procedures were correctly applied and whether the challenged decision was reasonable and supported by evidence. The review may result in confirmation of the original decision, modification of conditions, or remand for reconsideration.

2. Appeal outcomes are final within the PCS system and are recorded in the PCS Registry. Decisions and rationales are communicated to all relevant parties.

10.6 Enforcement Measures

1. PCS applies enforcement measures where non-compliance with PCS requirements is identified. Enforcement actions are proportionate to the nature and severity of the non-compliance and aim to restore compliance while protecting the integrity of the standard.

2. Enforcement measures may include requests for corrective action, issuance restrictions, suspension of project activities, suspension of VVB approval, or project termination in severe cases. Enforcement decisions are documented and subject to grievance and appeal mechanisms.

10.7 Relationship Between Grievance, Appeals, and Enforcement

1. Grievance and appeal mechanisms operate independently of enforcement actions, although findings from grievance or appeal reviews may inform enforcement decisions. Enforcement actions do not preclude the submission of grievances or appeals, and vice versa.

2. This separation ensures procedural fairness while maintaining the ability of PCS to act decisively to protect integrity.

10.8 Recordkeeping and Transparency

1. All grievances, appeals, and enforcement actions are documented and recorded in the PCS Registry. Records include submissions, review findings, decisions, and any corrective actions imposed.

2. Summary information may be disclosed to support transparency, subject to confidentiality and data protection requirements.

Chapter 11 - Versioning, Amendments, and Transition Provisions

11.1 Purpose and Principles

1. This chapter establishes how the Planetary Carbon Standard manages changes to its standards, methodologies, tools, templates, and procedures over time. The objective is to enable continuous improvement while preserving regulatory certainty, environmental integrity, and fairness for projects operating under PCS.

2. PCS applies a principle of controlled evolution. Changes are implemented through formal processes, are clearly versioned, and are accompanied by transition provisions where necessary. Retroactive application is avoided unless explicitly justified and approved.

11.2 Version Identification and Control

1. All PCS documents are issued with a version identifier and effective date. Version identifiers are used to distinguish between substantive revisions, clarifications, and administrative updates. The version in force at the time of project submission governs the applicable requirements, unless transition provisions specify otherwise.

2. The PCS Secretariat is responsible for maintaining the official register of document versions and for ensuring that only approved versions are applied within the PCS system.

11.3 Amendments to PCS Documents

1. Amendments to PCS documents may be initiated to reflect scientific advances, regulatory developments, implementation experience, or integrity considerations. Amendments follow formal PCS procedures for development, consultation, review, and approval.

2. Amendments may apply to standards, methodologies, tools, templates, or procedures. The scope and implications of each amendment are documented, including any impact on registered projects.

3. Amendments do not take effect until formally approved and published by PCS.

11.4 Clarifications and Interpretative Guidance

1. PCS may issue clarifications or interpretative guidance to address questions of application or interpretation. Clarifications do not change substantive requirements but provide additional explanation to support consistent implementation.

2. Clarifications apply from the date of issuance and do not alter previously approved decisions unless explicitly stated.

11.5 Transition Provisions

1. Where amendments introduce substantive changes, PCS may establish transition provisions to manage their application to existing projects. Transition provisions define whether and how revised requirements apply to projects already registered or under development.

2. Transition provisions are designed to balance integrity objectives with regulatory certainty. Projects are not required to retroactively apply revised requirements unless such application is essential to protect environmental integrity.

11.6 Applicability to Registered Projects

1. Registered projects continue to operate under the version of PCS documents in force at the time of registration unless transition provisions specify otherwise. Where projects elect to adopt revised methodologies or tools voluntarily, such adoption must be approved and documented in accordance with PCS procedures.

11.7 Communication and Publication of Changes

1. All approved amendments, clarifications, and transition provisions are published by PCS and communicated through official channels. The PCS Registry reflects current versions and identifies superseded documents to prevent inadvertent use of outdated materials.

2. Transparency in communication ensures that all PCS participants are aware of applicable requirements.

11.8 Final Provisions

1. This Operational Process Manual enters into force upon publication and applies to PCS version 2.0. It remains valid until amended or replaced in accordance with PCS procedures.

2. Compliance with this manual is mandatory for all PCS participants.