How we verify a carbon project.

Every carbon credit that reaches a buyer's portfolio has, somewhere behind it, a verification opinion - a document stating that an independent third party checked the project's claims and found them sound. Most people who rely on that opinion never see how it was made. This is a walkthrough of what actually happens between a project developer's first inquiry and the moment a registry issues a credit.

It starts with a question we ask before anything else

Before we accept an engagement, we check whether the project is even eligible for the standard and discipline it's asking to be verified under. This sounds like a formality. It isn't. A surprising number of inquiries arrive with the wrong methodology in mind, or a scope that doesn't match what the client actually needs verified - a developer asking for Carbon VVB validation when what they actually need is a GHG inventory verification for their own operations, for instance. Catching that mismatch in week one is a lot cheaper than catching it in month three.

Once scope is confirmed, we don't just assign whoever's available. Every auditor nominated to a project is checked against independence requirements first - no prior advisory relationship with the developer, no conflict through a parent company, nothing that would let anyone reasonably question whether the opinion is arm's length. This is where the assurance level or methodology version also gets fixed in writing, so there's no ambiguity later about what standard the opinion is actually being issued against.

The plan changes depending on what's being verified

A first-time verification of a small reforestation project gets a different audit plan than a repeat verification of an established wind farm in its eighth crediting period. Planning sets the sampling approach and the specific evidence we'll need to see - which matters because it means the client knows exactly what to prepare before execution starts, instead of discovering gaps mid-review.

For a bio carbon project specifically, this is where we decide which independent satellite imagery providers will corroborate the developer's own monitoring data. We deliberately don't rely on a single affiliated evidence source for this discipline. If the only account of what happened on a piece of land comes from one data supplier, the opinion is only as strong as that supplier's account - so geospatial inputs get cross-checked against field audits and a second, independent imagery provider before we trust them.

Execution is where the technical assessment actually happens

This is the stage most people picture when they think of an audit - document review, combined with a site visit or remote audit as appropriate to the project type and geography. But the standard we're checking against isn't a generic checklist. Additionality, baseline accuracy, boundary setting, and data quality are all assessed against what the applicable methodology specifically requires for this project type, not a one-size-fits-all template stretched across every asset class.

For an Article 6.2 or 6.4 project, execution includes something most other verifications don't: confirming host-country authorization and the correct application of corresponding adjustments. Get this wrong and a credit can end up double-counted - claimed both in a host country's own emissions inventory and in an international transfer. That's not a paperwork error. It's the kind of mistake that undermines trust in the entire mechanism, not just one project.

No single auditor's judgment is the last word

Before any opinion goes out, someone who was not part of the engagement team reviews the file independently. This step exists specifically so inconsistencies, incomplete evidence, or a misapplied methodology get caught before they become part of a formal, published opinion - not after a registry has already issued a credit against it.

The opinion itself is drafted and issued only once that independent review is complete. It states clearly what was assessed, against which standard, and at what assurance level - limited or reasonable, validation or verification. Where a credit results from this stage, it's tagged at issuance as either destined for trading or retained for the client's own reporting. Never both. That single tag is what keeps the same tonne of avoided or removed carbon from being counted twice.

The file doesn't close when the opinion is signed

An opinion isn't the end of the process. If a fact material to that opinion comes to light afterward - a data error, a change in project circumstances, a dispute raised by a third party - we track it, and where it's material, we act on it. This is what separates a one-time audit from ongoing verification infrastructure: the record stays open to correction, rather than being closed the moment the opinion is signed.

None of this happens on spreadsheets and email threads anymore. Every review, comment, and decision runs through one platform, logged against the record it relates to - which is a duller sentence than it deserves to be, given how much of verification's historical cost and delay came from exactly the opposite: paper trails that priced smaller developers, particularly across the Global South, out of independent assurance altogether. Making that verification affordable enough that cost stops being the reason to skip it was, honestly, the point of building the platform in the first place.