CarbonScope Carbon readiness and land recovery
Registry and evidence system Mapped land Auditable records

About Carbonscope

Carbonscope is a structured system for land based carbon projects that connects mapped land boundaries to evidence, monitoring, independent review, and a registry ledger for issuance, transfer, and retirement.

The platform does not ask anyone to trust a claim because it sounds good. It requires the claim to be anchored to a place, tied to authority, measured under a declared methodology, and reviewable through a documented decision trail.

Quick navigation
What it is and what it is not
End to end lifecycle
Credit unit definitions
Evidence hierarchy
Verification and independence
Anti fraud and integrity controls
Transparency and privacy
Roles and timeline
Questions and answers
If you are a project team member, use the Workspace to create projects, map sites, upload evidence, and run monitoring cycles. If you are a buyer, use the Market and Retirement tools to manage holdings and claims.
Anchor every claim to mapped land
A boundary is not a screenshot or a story. It is a versioned polygon that becomes the scope for monitoring, calculations, and credit issuance.
Make evidence first class
Documents, measurements, photos, logs, and exports are treated as linked artifacts with authorship, timestamps, and integrity metadata.
Separate recording from approval
Project teams can record data, but they cannot verify or mint credits. Approval is a role gated review process that creates the decision trail.

What Carbonscope is and what it is not

Carbonscope is a registry and evidence workflow platform for land based carbon. It helps teams produce claims that can be reviewed, compared, and audited. It also provides a ledger for issuance, ownership transfers, and retirement.

What it does
  • Forces mapping, authority proof, monitoring, and declared methodology into one chain.
  • Versions boundaries, records changes, and preserves what was relied on for each issuance decision.
  • Links every checklist decision to the underlying artifacts, so approvals are reviewable.
  • Maintains a registry ledger for issuance, transfers, and retirement with irreversible state transitions.
What it does not claim
  • It does not claim that fraud is impossible.
  • It does not replace fieldwork, scientific judgement, or independent review.
  • It does not magically turn weak baselines into strong baselines.
  • It does not claim that retirement equals climate neutrality.
A simple rule of thumb
If you cannot show where the claim applies, who has authority, what changed, how it was measured, and which rules were applied, then the claim is not credit ready and it should not be issued.
Core system objects
Project
The legal and operational container, with declared intent and responsible parties.
Site
A manageable land unit inside a project, used for measurement, governance, and reporting.
Boundary
A versioned polygon that anchors scope and prevents internal double counting.
Evidence
Documents, photos, logs, lab results, datasets, and exports linked to scope and time.
MRV record
Repeated monitoring events over time that store raw measurements and summaries.
Credit batch
A uniquely identified set of issued units tied to a vintage and an evidence snapshot.

How the system works from start to finish

The lifecycle below is the operational spine of the platform. Each stage has clear requirements, expected artifacts, and a defined handoff to the next stage.

1
Create the project

The project records identity, accountable parties, and declared intent. It is also where you declare which methodology and baseline approach you will follow.

Example A cooperative agroforestry project declares a conservative baseline, defines eligible pools, and sets its monitoring schedule.
2
Create sites and link communities

Sites define how land is organized for monitoring and reporting. Communities and cooperatives are linked so benefits and evidence have clear ownership.

Example A project creates Site 17 and assigns it to a farmer group that can provide consent artifacts and participation evidence.
3
Map boundaries and version them

Boundaries are drawn or uploaded, validated, and saved as versions. A primary footprint can be designated per scope using enforced uniqueness rules.

Example A footprint polygon is updated after a GPS walk. The old version remains available and the new version becomes current.
4
Upload evidence continuously

Documents are not an afterthought. You attach supporting artifacts as you work, including authority proof, training records, invoices, photos, lab reports, and datasets.

Example A project uploads land tenure evidence, benefit sharing minutes, and baseline justification documents before any issuance request.
5
Run MRV cycles and store raw data

Monitoring is repeated over time. Each MRV record stores raw field measurements and the summarized numbers needed by the declared methodology.

Example Survival sampling and plot measurements produce biomass estimates, with uncertainty documented and tracked across cycles.
6
Verification, then issuance

A verifier reviews readiness and evidence against declared rules. If approved, issuance creates a uniquely identified batch tied to a frozen evidence snapshot.

Example A verifier approves issuance for Vintage 2026 based on MRV cycle data and the current boundary version at the time of approval.
7
Listing, transfer, and retirement

Issued credits can be listed, transferred between accounts, and retired. Retirement is irreversible and produces a certificate that proves removal from supply and registry state.

Example A buyer purchases 100 credits, then retires them against a defined claim reference. The certificate references the batch identifiers and retirement timestamp.
Why versioning matters
Projects evolve. Boundaries change. Methods improve. Data corrections happen. Carbonscope keeps those changes explicit and time bound. Issued batches remain tied to the evidence snapshot used at issuance, so later changes do not silently rewrite history.
Readiness and risk concepts
These are platform concepts that help teams and reviewers understand whether a project is ready for verification and what risks remain.
Concept Meaning in practice
Readiness Minimum required artifacts exist for review, such as valid boundaries, authority proof, declared methodology, baseline evidence, and at least the required MRV cycle.
Risk Factors that raise overcrediting or reversal probability, such as unclear tenure, inconsistent evidence, high fire risk, sparse monitoring, or leakage potential.
Conservatism Issuable quantity is not the optimistic estimate. It is reduced by uncertainty, leakage deductions, and buffer rules with explicit recorded deductions.
Typical evidence set before issuance
  • Current boundary version and prior versions available
  • Authority and consent artifacts
  • Baseline justification documents
  • Declared methodology rule set and parameters
  • At least one MRV cycle with raw measurement artifacts
  • Supporting documents that corroborate field activities

Credit unit definitions in Carbonscope

Buyers care about exact semantics. The definitions below describe what a credit means inside Carbonscope, how time is represented, and how buffers and reversals are treated at a system level.

Core unit

A Carbonscope credit is a registry unit representing one metric tonne of carbon dioxide equivalent, expressed as one tCO2e, issued for a specific project scope and vintage under a declared methodology and verification decision.

Key definitions
Vintage
The defined time period that the issuance batch claims to represent, typically a year or monitoring period, tied to MRV records and the evidence snapshot used for approval.
Evidence snapshot
A frozen reference to the boundary version, documents, and MRV records that were used to justify issuance. This protects integrity when projects evolve later.
Buffer
A conservative reserve deduction applied to issuable quantity to manage non permanence risk. Buffer rules must be declared and the deducted quantity is recorded explicitly.
Leakage deduction
A conservative reduction that reflects displaced emissions or displaced activities. The deduction method must be declared and linked to evidence.
Uncertainty deduction
A conservative reduction derived from sampling uncertainty or measurement error. The rules used must be declared and reproducible.
Reversal
A loss event such as fire, harvest, drought, or land conversion. Reversal handling is governed by declared rules, typically through buffer drawdown, corrective issuance limits, or freezes while disputes are resolved.
Important scope boundary
A registry unit proves issuance, ownership history, and retirement inside the registry. It does not automatically prove that an entity is climate neutral. Any public claim must follow the buyer’s own reporting framework and must reference the retirement record.
Conservative issuance logic concept
Carbonscope stores the final issuable quantity and the recorded deductions. The exact equations depend on the methodology, but the structure is consistent.
Issuable quantity
Issuable equals measured effect minus baseline, then reduced by leakage, uncertainty, and buffer deductions, according to declared rules.
Example in plain terms
If a site measures 1,000 tCO2e above baseline, and the methodology requires 10 percent uncertainty deduction, 5 percent leakage deduction, and a 15 percent buffer, then issuable quantity becomes 1,000 times (1 minus 0.10 minus 0.05 minus 0.15) equals 700 tCO2e, with each deduction recorded.
This is not presented as a universal formula. It is an example of how conservative structure works. Carbonscope requires the project to declare the exact rules and to link them to evidence.

Evidence hierarchy and MRV philosophy

Carbonscope is community anchored, but it does not confuse community documentation with carbon quantification. Governance evidence protects legitimacy. Measurement evidence supports carbon claims. Supporting evidence helps detect inconsistencies and reduces fraud risk.

Primary evidence
  • Plot measurements and sampling datasets
  • Survival counts and biomass estimates
  • Soil sampling and lab results
  • Georeferenced monitoring photos
  • Any dataset required by the methodology
Supporting evidence
  • Invoices and procurement records
  • Attendance sheets and training minutes
  • GPS tracks and boundary walk logs
  • Remote sensing summaries used for corroboration
  • Field notes and activity logs
Governance evidence
  • Land authority documents and tenure proof
  • Community consent artifacts
  • Benefit sharing arrangements
  • Grievance and complaint mechanism artifacts
  • Role assignments and steward confirmations
MRV hierarchy rule
The declared methodology defines what evidence is required and what evidence is supportive. Remote sensing can be used as primary only when the methodology explicitly permits it and the required parameters and limitations are declared. Otherwise it is treated as corroboration, not replacement.
What reviewers expect to see
A strong file set is not about volume. It is about traceability and cross check value.
  • Every boundary change has a reason and a new version.
  • Monitoring evidence is georeferenced and time bound.
  • Uploads have authorship and integrity metadata.
  • Approvals cite the exact artifacts they relied on.
  • Numbers can be reproduced from stored raw data.

Verification and independence

Independence is not created by branding. It is created by structural rules that reduce conflicts, create auditability, and allow sanctions when process integrity fails.

Separation of powers
  • Project teams can record and submit evidence, but they cannot verify or issue credits.
  • Verifiers can annotate, request corrective actions, approve or reject, but they cannot edit core project records.
  • Issuance is a controlled registry action that is role gated and tied to an approval decision and evidence snapshot.
Conflict management
  • Verifiers must declare conflicts of interest before accepting assignment.
  • Projects should not directly select the verifier for their own issuance request.
  • High risk approvals should trigger secondary procedural review when thresholds are exceeded.
What a verification decision includes
  • Which methodology and parameters were reviewed.
  • Which boundary version and MRV cycle were relied on.
  • Which deductions were applied and why.
  • Which exceptions were allowed and how they were justified.
Enforcement principle
A registry without enforcement becomes a database of claims. Carbonscope is designed to support freezes, flags, corrective actions, and audited reversals when errors, fraud, or disputes are substantiated under published rules.
What a buyer can verify
A buyer should be able to confirm, without private farmer data, that a retirement occurred and which batch identifiers were retired.
  • Batch identifiers and vintage
  • Project scope summary and methodology label
  • Verifier decision reference and date
  • Ledger history of transfers
  • Retirement timestamp and certificate reference

Anti fraud and integrity controls

Fraud in real projects is rarely a lack of documents. It is fabricated documents, coerced signatures, reused photos, biased samples, and insider tampering. Carbonscope reduces risk by requiring cross checks, preserving immutable trails, and making critical actions reviewable and reversible under governance rules.

Document integrity controls
  • Store original filenames plus stored random names.
  • Store file hashes such as sha256 when enabled.
  • Prevent silent replacement by versioning critical artifacts.
  • Encourage georeferenced photos and time bound logs.
Measurement integrity controls
  • Require raw data storage, not only summary numbers.
  • Record sampling design, plot selection method, and field team identity.
  • Run consistency checks across cycles to detect anomalies.
  • Use corroboration evidence to detect fabricated series.
Registry integrity controls
  • Prevent internal double counting with scope and overlap rules.
  • Allow external registry references to flag cross registry risk.
  • Use immutable ledger events for transfers and retirement.
  • Block transfers when credits are retired, frozen, or in dispute.
Insider and collusion controls
  • Role based permissions with audit logs.
  • Verifier cannot edit project evidence, only annotate and decide.
  • Secondary review triggers for high risk decisions.
  • Sanctions and removal mechanisms for verifiers under governance rules.
Hard attack vectors and how they are handled
Double counting, tenure disputes, elite capture, reversals, leakage, sampling bias, and verifier collusion are addressed by combining mapping constraints, authority documentation requirements, versioning, risk flags, independent review, and the ability to freeze or correct batches under defined governance rules.
Change control and corrections
When something changes, the change must be explicit, time bound, and reviewable.
  • Boundaries are versioned. Old versions remain available.
  • Methodology updates apply forward and require declared change notes.
  • Baselines can be corrected, but the correction is logged and reviewable.
  • Issued batches tie to evidence snapshots to prevent silent rewrites.
  • Material errors can trigger freezes or formal correction workflows.

Transparency and privacy

Transparency builds trust, but privacy protects communities. Carbonscope separates publishable registry facts from sensitive personal data, and it supports redaction where disclosure could harm participants.

Public by design
  • Project level summaries that do not reveal private identities.
  • Boundary scope summaries and identifiers where safe to disclose.
  • Issued batch identifiers, vintage, and retirement confirmations.
  • Verification decision references and decision dates.
Protected by default
  • Personal data of farmers, staff, and community members.
  • Detailed household data and sensitive governance documents.
  • Evidence that could expose vulnerable participants to harm.
  • Private drafts and internal corrective action notes.
Consent principle
Evidence can be required for verification without being published. When public disclosure is necessary, disclosure should be consented, minimal, and purpose bound.
What a retirement certificate proves
A certificate is a proof of registry state, not a blanket climate claim.
  • It proves a specific batch and quantity were retired on a timestamp.
  • It proves the credits are removed from trade in this registry.
  • It links to a public verification reference for confirmation.
  • It does not claim climate neutrality or eliminate uncertainty.

Roles, purpose, and where each role fits in the timeline

Roles exist to create the chain of trust. Each role has a defined responsibility and a defined boundary. The timeline below shows how roles interact without collapsing independence.

Role overview
Role Primary purpose Where it appears in the lifecycle
Project developer Build the evidence chain and run implementation From setup through MRV cycles, submits for verification, cannot verify or issue
Community steward Protect legitimacy and consent During setup and throughout operations, confirms participation, raises concerns, supports grievance records
Field monitor Collect and submit monitoring data During MRV cycles, uploads raw measurement artifacts and summaries, supports repeatability
Verifier Independent evaluation of readiness and evidence Before issuance, completes checklist, requests corrections, approves or rejects, cannot edit evidence
Registry admin Operate governance, issuance, and enforcement Manages verifier eligibility, performs issuance actions after approvals, freezes or resolves disputes
Buyer Acquire, hold, and retire credits After issuance, purchases, transfers, and retires credits to substantiate claims with proper scope
Practical example of separation
A developer uploads a monitoring dataset. A verifier reviews it and requests clarification. The developer responds by uploading additional evidence, not by editing the verifier record. If approved, the registry admin issues a batch tied to that evidence snapshot.
Where buyers enter
Buyers interact with the system after issuance, when units exist as registry assets with identifiers and histories.
  • Review listings and risk summaries
  • Purchase issued credits
  • Track holdings and transfer history
  • Retire credits and obtain certificate
  • Reference retirement in reporting with proper claim language

Questions and answers

These answers are written to be clear even if you are new to carbon markets. They also include the practical constraints that prevent misuse.

The main promise is clarity. Carbonscope makes the chain of proof explicit by linking land scope, authority, evidence, monitoring, review decisions, issuance batches, and retirement records. It does not promise perfection. It promises that claims are structured, reviewable, and auditable.

Credits are issued only after a verification decision approves the evidence set and confirms that the declared methodology rules are satisfied. Issuance creates a batch with unique identifiers, a defined vintage, and a frozen reference to the evidence snapshot used for approval. Issuable quantity is conservative and reflects recorded deductions such as uncertainty, leakage, and buffer rules.

Yes, issued credits can be transferred between accounts while they remain active and not retired. Once a credit is retired, it is permanently removed from trade. The ledger records transfers as immutable events so ownership history is reviewable.

Inside the platform, mapped boundaries and scope rules help prevent issuing overlapping claims within the same registry. For cross registry risk, projects can disclose external registry references and reviewers can assess whether an area appears elsewhere. Preventing cross registry double counting is partly governance and disclosure, not only software.

A reversal is treated as a monitored event and it triggers governance actions defined by the declared rules. Typical responses include buffer drawdown, corrective restrictions on future issuance, and where necessary a temporary freeze while evidence is collected and disputes are resolved. The key principle is that reversals are not ignored and do not silently disappear.

Carbonscope is a registry and evidence platform. If financial compliance features such as KYC and transaction monitoring are enabled for a deployment, those controls must be stated explicitly in the applicable policies. The platform should not claim bank grade compliance unless those controls are actually operated and audited.
Next steps for readers
If you are evaluating a project, focus on scope, evidence quality, MRV maturity, and decision trail.
  • Ask for the declared methodology and parameters
  • Review boundary scope and version history
  • Inspect MRV cycles and raw evidence completeness
  • Check recorded deductions and conservatism
  • Confirm issuance identifiers and retirement references
Contact and participation
Organizations, cooperatives, and buyers can engage through the platform workflow. Participation should be structured around clear scope, declared rules, and a documented evidence chain.