Carbon Credits

Grouped Projects: One Design Document, Many Project Instances

A grouped project covers many similar sites under one design document, with eligibility criteria for adding further instances.

Grouped project is a project design in which several similar activity instances are described under a single design document and methodology, with defined eligibility criteria that allow further instances to be added over the crediting period. It sits inside Carbon Credits and connects directly to how projects are documented, financed, and judged.

The design document sets out the activity type, baseline approach, and criteria a site must meet to join. Sites that qualify are listed as instances, with their own boundaries and start dates, and are monitored individually but reported together. New instances can be added if they satisfy the criteria and are disclosed to the verifier. The verifier's sampling plan therefore determines how much assurance the group actually carries.

Grouping keeps administrative cost low for replicated activities such as distributed biodigesters or small forest patches, while preserving site-level data. It also gives buyers a single counterparty and a single document set to review. For a buyer, grouping concentrates counterparty risk: one developer and one document set stand behind every instance, so a governance failure affects the whole batch at once. Clarity about Grouped project is what lets buyers, sellers, and regulators compare like with like instead of trading on assumption.

Practical experience with Grouped project tends to reward patience and discipline: the organisations that document their assumptions, keep an audit trail, and revisit their methods are the ones that keep credibility when questions are asked.

As carbon markets mature, Grouped project is shifting from a niche technical concern to a mainstream one, shaping diligence checklists, disclosure expectations, and the way one credit or claim is weighed against another.

Instance-level data can be thin, and eligibility criteria are sometimes written loosely enough that ineligible sites join. If the group grows beyond the verifier's sampling capacity, individual problems go undetected. Because instances share a baseline approach, a single flawed assumption about what would have happened without the project propagates across every site in the group.

CarbonFi stores each instance as a geo-referenced record beneath the group, letting Athlas Verity check satellite evidence per site and attach it to the credits issued for that instance. CarbonFi also lets a buyer filter a group by instance, so they can avoid sites with unresolved tenure or safeguard issues while still buying from the wider portfolio. For teams working across CarbonFi, Grouped project is not abstract: it maps onto concrete steps in verification, issuance, trading, or retirement, each of which can be recorded and checked on-chain.

Key takeaways

  • One design document covers many instances.
  • Eligibility criteria govern which sites can join.
  • New instances can be added during the crediting period.
  • Sampling capacity limits how large a group can grow safely.

Frequently asked questions

Is a grouped project the same as a programme of activities?

They are similar in spirit but differ in registration mechanics; grouping sits under one design document, while a programme adds components under a registered programme framework.

How many instances can a group contain?

There is no universal cap, but verifiers must be able to sample and audit them credibly.

What happens if an instance is added late?

It must meet the eligibility criteria and its start date and baseline are assessed before it can generate credits.

Related guides

Put this into practice with CarbonFi

CarbonFi combines AI-driven verification (Athlas Verity), an on-chain carbon registry, the marketplace and CarbonDEX, CAFI staking, and on-chain retirement certificates — so carbon stays traceable from project to retirement.