N1 The LandCoverChange contract

The third of the three platform contracts, and the same discipline as HazardFootprint and FieldObservation. A mining alert, a mangrove loss and a REDD+ activity-data update are all one object: a polygon, a from-class, a to-class, a date range and a confidence.

authorised: unknown is the honest default, and it should be the value most of the time until concession data is sourced. A pipeline that defaults to no is producing allegations.

N2 One change-detection pipeline, two consumption modes

Protect Nature and Nature-Based Solutions are not two systems. An illegal-mining alert and a REDD+ activity-data update are the same kind of signal — a change in land cover — read for two different purposes. Building them separately duplicates the expensive part (detection) to avoid duplicating the cheap part (routing).

N3 The rights-and-accounting join

Structurally the same service as §04's E3 and §05's F3 — a footprint goes in, an annotated bundle comes out with provenance attached. What differs is the stacks: territory, enforcement coverage, protected-area status, carbon stock and concession status. It is also where the authorised field of N1 is actually resolved, which is why the concession gap above is an engineering blocker and not just a data wish.

N4 The agent contract, and the one architecturally different agent

Five of the six agents follow the standard pattern. The Wildlife Trafficking Signal Agent does not, and it is worth being explicit about why: remote sensing cannot meaningfully detect the trade or movement of wildlife products. That module is a data-integration layer over ground-based systems — MegaDetector inference on camera-trap imagery, SMART for case management — providing aggregation and decision support rather than new detection technology. Scoping it as if it were another EO detector is the mistake to avoid (Decision #4 sequences it behind mining and logging for exactly this reason).

N5 The MRV evidentiary envelope

The counterpart to Food Security's EUDR channel. An MRV report is submitted to a registry or under a UNFCCC commitment, which makes it an evidentiary record with a defined methodology, a stated uncertainty and a reproducible chain back to reference samples. SEPAL and the FAO Open Foris methodology are the standard; Open Foris Arena's schema and the GFOI/OpenMRV methodology library are what the decision-support report should be built against, since no finished tool for that last step exists.

N6 The credibility guardrail

A 2023 investigation (The Guardian, Die Zeit, SourceMaterial) found more than 90% of Verra's rainforest REDD+ offset credits likely did not represent genuine emissions reductions, largely due to inflated deforestation baselines. Verra disputed the findings but substantially overhauled its methodology afterwards, and its CEO resigned shortly after. That history is the direct reason for the boundary drawn in Fig. 7: the platform supplies rigorous MRV data into a contested downstream market, and does not issue, register or guarantee credits. The guardrail is architectural, not editorial — the MRV output path terminates at a report, and no agent in the system has a tool that mints a credit.

N7The layer this plan does not have — intervention prioritisation

Every capability specified across §04–06 answers a monitoring question: what is happening now, what the annualised baseline is, how that baseline shifts under climate. That is the three-clock grammar, and it is deliberate. But it stops one step short of the question a land manager actually arrives with — given a fixed budget, where do we intervene, and what do we get for it? No element in this plan answers that, and the omission is easy to miss because it is hidden in plain sight: three of the use cases below already imply it. Where rangers patrol in Prey Lang. Which degraded mining sites in Ghana get remediated first. Which stretches of Vietnamese coast get mangrove protection against shrimp aquaculture. Each is the same constrained-optimisation problem, currently answered ad hoc, per use case, by hand.

The reference implementation already exists and is SIG's own. github.com/OurPlanscape/Planscape — a wildfire-resilience treatment planner built by SIG for the US Forest Service, ~7,200 commits, Angular + Django + PostGIS, wrapping ForSys (Ager, Day and Evers, USFS) for the optimisation itself alongside FVS, GridFire, TreeMap and PROMOTe. Its licence is CC0 — public domain, no attribution obligation, strictly more permissive than anything else in this plan's dependency set.

And it carries the same constraint as pyretechnics, which is now a pattern rather than a coincidence. Planscape runs on California Regional Resource Kits — ten resilience pillars at 30 m, California-only, with custom dataset upload still unbuilt. pyretechnics runs on LANDFIRE fuel models, US-only. In both cases the method transfers and the data pipeline does not. SIG's fire and land-treatment stack is portable in code and locked in data, and the recurring cost of adopting any of it into SERVIR is the same line item every time: build the regional input layer. That is one procurement question, not two, and it should be scoped as one.

What to do with this is a scoping decision, not an engineering one, so it is logged as Decision #23 rather than specified here. The architectural point stands regardless of that outcome: if the platform only ever tells governments what is happening, it stops exactly where their actual decision begins.