How to pick a baseline year for a mangrove extent report

Every blue carbon methodology asks for a baseline, and most project developers inherit the question late, usually when a validator asks why the extent polygon from year zero looks the way it does. Picking a baseline year badly doesn't just cost you a redo. It can undercut the additionality argument for the whole project.

What the baseline year is for

The baseline year sets the "before" condition against which every later extent measurement gets compared. Loss since baseline, regrowth since baseline, net carbon stock change since baseline. If the baseline overstates how much mangrove was standing before the project started, your reported gains shrink. If it understates it, a reviewer will ask what happened to the difference and whether the project is claiming credit for forest that was already there.

Most registries (Verra's VM0033 and VM0007 lineage, Plan Vivo's technical specifications) want the baseline tied to a real pre-project condition, not to whichever year happens to have the best imagery. That distinction trips up more project teams than anything else in the extent-mapping process.

The mistake: choosing the year with the cleanest scene

It's tempting to dig through an imagery archive, find the one cloud-free, low-tide, no-haze scene from 2015, and declare that the baseline. The scene quality argument makes sense from a GIS desk, but validators care about the condition of the site immediately before project activities began, not which year gave you the best pixels.

Say your project start date is 2021 but the cleanest available scene sits in 2015: that is a six-year gap you will have to explain. Did clearing happen in that window? Did a storm take out a fringe stand in 2018 that your 2015 baseline never captured? A validator working through VCS or Plan Vivo requirements will ask for the intervening years anyway, so skipping straight to the pretty scene usually just adds a round of resubmission.

How to choose it instead

Start from the project start date and work backward through the archive to find the nearest usable pre-project scene. A few things that hold up under review:

• Match the baseline to the methodology's defined window. Some methodologies set a fixed lookback period, often one to a few years before project start. Check the specific version you're applying under before you lock in a year.
• Use the most recent pre-project year with usable imagery, even if it's not the cleanest scene available. A slightly hazy, correctly dated scene beats a pristine one from the wrong year.
• Document what you did when the ideal year had no usable scene. Tidal stage, cloud cover and sensor gaps genuinely block some years, especially in the wet tropics where mangroves are most common. A short note on why you substituted the nearest available date is far more defensible than silence.
• Keep the source and acquisition date on the record, not just the resulting polygon. Registries increasingly want to see the provenance trail, not just the shapefile.

Where this connects to annual reporting

Once the baseline is set, every subsequent monitoring report measures against it. The baseline year's extent polygon needs to be drawn the same way, at the same resolution, with the same edge-detection logic as the years that follow. A baseline digitised by hand at a coarse scale, then compared against a sharper, more consistent extent layer in year three, will show apparent loss or gain that actually comes from the change in drawing method rather than any real change on the ground. This is one of the quieter reasons annual mangrove extent mapping benefits from consistent processing from the baseline year onward, so the registry sees a comparable time series rather than a year-zero map that was built differently from everything after it. Mangrove Monitor delivers that as an annual extent layer you can drop straight into the monitoring report, dated and sourced the same way each year.

A short checklist before you lock it in

Before submitting the baseline year to a registry or validator, confirm: the year falls within the methodology's allowed lookback window, the imagery source and acquisition date are documented, the digitising method matches what you'll use going forward, and you have a written reason for the year if it wasn't the first option you tried.

Get the baseline year wrong and you'll be re-explaining it at every verification cycle. Get it right once, and the rest of the reporting gets a lot quieter.

If your project is heading into its next monitoring cycle, it may be worth comparing your current baseline approach against an annual extent layer built the same way every year.