Mangrove degradation vs. loss: what your registry report actually needs

If you've sat through a verification call where the auditor circles a patch of canopy and asks "is this degraded or is this gone," you already know the two words aren't interchangeable, even though half the project documents you inherited use them like they are.

The distinction a registry is actually checking

Loss, in most blue carbon methodologies (VM0033 and its relatives lean on this same logic), means the mangrove area has converted to something else: open water, mudflat, aquaculture pond, cleared land. The canopy boundary moved. You can draw a polygon around where the trees used to be and the polygon is now outside your extent layer.

Degradation is different. The stand is still there, still mapped as mangrove, but it's thinner, sparser, or carrying more standing dead wood than it did at the last monitoring date. Canopy cover might drop from a closed stand to something gappy enough that you can see mud between crowns in imagery. The footprint hasn't shrunk. The condition has.

The two sit in different carbon pools, and that changes which number you report where. A converted hectare drops out of your extent entirely, and its carbon stock calculation follows the deforestation pathway. A degraded hectare stays in extent but gets a reduced biomass or canopy-cover input, a separate line in most monitoring reports, not a subtraction from total mangrove area.

Auditors have seen enough reports where a project team, under deadline, folds a thinning event into the "loss" column because it's easier to explain in one paragraph. It isn't wrong exactly, it's just not what the methodology is asking for, and it tends to surface as a query in verification rather than a straightforward pass.

Where canopy thinning sits, and why your extent polygon can't carry it

Canopy thinning, the usual proxy for early-stage degradation, shows up as reduced density within a stand that's still structurally mangrove: still rooted, still tidal, still there on the ground. A boundary layer built to trace the canopy edge, where mangrove becomes not-mangrove, isn't built to grade what's happening inside that edge. That's a separate measurement, usually canopy cover percentage or a spectral index read against a baseline scene, and it belongs in a different part of the monitoring report than your extent polygon.

This is the gap that trips up a lot of annual reports: the extent layer answers "how much mangrove is there," and that's the number a registry wants reconciled year over year, dated and sourced, with loss and regrowth areas called out separately from the stable core. Degradation is a parallel question your MRV plan should be asking with its own method, not something you back into by eyeballing a cloud-free scene and guessing.

What this means when you're drafting the report

Keep the two claims apart on the page. State extent, with loss and regrowth polygons each dated to the imagery they came from, as one section. If your project is also tracking degradation or canopy thinning, that's a second section with its own baseline and its own input, not a footnote inside the extent numbers.

If your current workflow is a team redrawing boundaries by hand from whatever scene wasn't cloud-covered that quarter, the boundary itself is often the weaker link, not the degradation call. A layer that traces the canopy edge the same way every reporting cycle gives you a consistent extent polygon to anchor the rest of the report to, loss and regrowth areas included, so the degradation question doesn't have to do double duty as a stand-in for boundary change.

Get in touch if an annual extent layer, matched to your project's reporting cycle, would make that section of the report easier to defend.