📦 Contents

Chapter 6: Integrating with the Global Ecosystem (PHASE 4)

Chapters 3 to 5 described what a WIA-ENE-057 implementation stores, how it is queried and how data moves across the wire. None of that is useful in isolation. A monitoring platform for drylands earns its keep when its records feed the processes that decide policy and money: national reporting on Land Degradation Neutrality, satellite archives that supply most of the observations, agricultural and soil databases, restoration programmes that coordinate thousands of planting sites, GIS desks, field survey apps and, increasingly, carbon markets. PHASE-4 of the standard, the Integration Specification, sketches connectors for each of these.

This chapter reads PHASE-4 as an engineer who has to build those connectors. Each section explains what the partner process actually needs, which WIA records supply it, what the specification's example object looks like, and where that example must not be taken literally. That last point matters more here than anywhere else in the book. PHASE-4 names real institutions — UNCCD, FAO, NASA, ECMWF, the Great Green Wall, Verra — next to endpoints and figures that are illustrative. The standard defines the shape of an exchange. It does not establish a partnership with any of these bodies, and none of the hostnames in its examples should be read as a live official API. Throughout, the running example is SAHEL-REGION-001 (latitude 14.5, longitude −4.0, 10,000 ha), and every number quoted from the specification is an illustrative example value, not a statistic about the Sahel or about Mali. Simulator panel 2 — the “3. Protocol” tab with its API and WebSocket demonstration, linked below this chapter — shows the request and response shapes that the adapters in this chapter consume.

6.1 LDN Reporting Integration

What the Convention asks for

Under the UNCCD, countries report on SDG indicator 15.3.1, the proportion of land that is degraded over total land area. The indicator is built from three sub-indicators: land cover, land productivity and soil organic carbon stocks. Each is compared between a baseline and a later reporting period, and the three are combined with the "one out, all out" rule: a land unit counts as degraded if any of the three shows significant negative change, even if the other two improve. Land Degradation Neutrality, in turn, is the state in which the amount and quality of land resources stays stable or increases within specified temporal and spatial scales — achieved by avoiding, reducing and reversing degradation so that losses are balanced by gains.

Three consequences follow for an implementer. First, the unit of assessment is a map, not a site average. Land cover change is evaluated as transitions between classes, pixel by pixel, and each transition is judged as degradation, improvement or stable. Productivity dynamics are classified from time series into trajectory classes (declining, early signs of decline, stable but stressed, stable, increasing are the categories commonly used in the UNCCD good practice guidance). Soil organic carbon is assessed as a stock for a reference topsoil depth. Second, official national reporting goes through the Convention's own reporting process and the country's designated focal institutions; a WIA platform prepares evidence and tables for that process but does not replace it. Third, the national reporting cycle spans several years. The quarterly frequency in the PHASE-4 configuration is an internal production cadence, not the Convention's schedule.

Mapping WIA records to the three sub-indicators

Each sub-indicator can be traced to specific WIA-ENE-057 records. The mapping below is what an LDN export adapter implements. It is the heart of the integration: if it is not written down, two platforms can report the same site with different results and neither can explain why.

Reading the unccdLdnReport example

PHASE-4 §1.1 defines an unccdLdnReport object with a reportingCountry (ISO 3166-1 alpha-3, MLI in the example), reportingYear and reportingPeriod, a locations[] array and a nationalSummary. Each location carries its coordinates, its area and an ldnIndicators block with landCover, landProductivity and carbonStocks, each split into baseline, current and sometimes change. The example values make a good teaching case precisely because they point in different directions.

Applied to these numbers, "one out, all out" says the site is degraded: productivity declined, and gains in cover and carbon do not offset that. An adapter that reports a weighted average, or that highlights the carbon gain, would misrepresent the site. Two further observations are worth making. The land-cover block reports net shares, and net shares can hide gross transitions — a site can lose 5 % of its cropland to bare soil in one corner and gain 5 % from fallow elsewhere, and the net table shows nothing. A conforming export therefore keeps the transition matrix, not just the totals. And the productivity decline and the woody-cover increase are hard to reconcile physically; in a real dataset that tension would trigger a check of sensor continuity, compositing and rainfall before anything is reported.

The example also contains an ldnStatus block with progress, neutralityGap and projectedAchievement. These are not UNCCD metrics. LDN is not expressed as a percentage of progress, and the Convention does not define a "neutrality gap" score. Implementations may keep such fields for internal dashboards, but they must not be labelled as LDN results in anything sent outward. The same caution applies to nationalSummary: its figures are placeholders for the shape of the object. Finally, the specification's baseline year 2015 is a single-year example; LDN baselines are normally derived from a multi-year period, and the adapter should store the baseline period explicitly rather than a single year.

The export workflow

PHASE-4 describes six steps: collect monitoring data, compute LDN indicators, generate the report, submit it, receive a validation response and store the confirmation. In practice the "submit" step points at whatever channel the national focal institution uses. The baseUrl https://api.unccd.int/ldn/v1 in the specification is illustrative; it is not a documented public UNCCD service, and the @wia/ene-057-integrations SDK shown in the example is not a published package. A robust design treats the export as a signed, versioned document: the adapter generates the tables and maps, records the input record IDs and their hashes, and hands the package to the people responsible for national reporting. The "validation response" then becomes a review record — who checked the package, when, and against which version — rather than an HTTP status code. Endpoint POST /reports/unccd-ldn from Chapter 4 is the natural trigger for this job.

6.2 Earth-Observation Pipelines

Most WIA-ENE-057 observations do not come from field teams. They come from satellite archives, which PHASE-4 §4 lists: MODIS (NDVI, EVI and land surface temperature), Landsat 8/9, Sentinel-2 and SMAP. The nasaEarthDataIntegration example configures three products — MOD13Q1 (NDVI and EVI, 250 m, 16-day), a Landsat 8 surface reflectance product (bands B4, B5, B6, 30 m; Table 2-2 also lists the blue band B2, which EVI needs) and SPL4SMGP (soil moisture, 9 km) — and declares an automated download feeding a processing pipeline. NASA Earthdata requires a user account and a token for downloads; credentials belong in a secret store, never in the configuration object, even though the example places a token field there.

The eight-step MODIS pipeline

 [1] Download granules (HDF)        tiles covering the location's bbox, new 16-day period
        |
 [2] Extract layers                 NDVI, EVI, VI quality, pixel reliability; apply scale 0.0001
        |
 [3] Reproject to WGS84             from the product's sinusoidal grid to EPSG:4326
        |
 [4] Clip to area of interest       location polygon from GET /locations/{locationId}
        |
 [5] Zonal statistics               mean, median, std, valid-pixel fraction per location
        |
 [6] Store as vegetationData        id VEG-YYYYMMDD-..., source, resolution, cloudCover, quality
        |
 [7] Trigger trend analysis         update trendAnalysis; emit data.created
        |
 [8] Evaluate alert rules           e.g. rapid-vegetation-decline -> webhook alert.triggered

The eight steps are simple to name and easy to get subtly wrong. At step 2, MOD13Q1 stores the indices as scaled integers, and a pipeline that forgets the 0.0001 factor, or applies it twice, produces values that either fail validation loudly or pass it silently near zero. The quality layers must be read at this step too; a composite pixel flagged as cloudy or snow-covered should be masked, not averaged in. At step 3, reprojection is where resampling choices enter. Nearest-neighbour keeps original pixel values, which is usually what is wanted for indices; bilinear interpolation blends pixels and can smear water or bare soil into vegetation. At step 4, the clip geometry must come from the location record, not from a hand-typed box. The bounding box in the §4.1 subscription example (south 14.0, north 15.0, west −4.0, east −3.0) places the location's own longitude on the western edge of the box, which is a reminder that such boxes are easily wrong.

Step 5 decides what a "site value" means. For a 10,000 ha location, MOD13Q1 yields on the order of 1,600 pixels (each 250 m pixel covers about 6.25 ha). The adapter should store not only the mean but also the number and fraction of valid pixels. A mean computed from 40 % of the area after cloud masking is a different measurement from one computed from 95 %, and metadata.quality should reflect that. Step 6 writes a vegetationData record whose source and resolution fields name the product and whose ID follows the PHASE-1 pattern; the upsert must be idempotent on the record ID so that reprocessing a period after a product reissue replaces rather than duplicates. Steps 7 and 8 connect the pipeline to the event model of Chapter 5: a new record triggers a trend update and the alert rules, and an alert leaves as an alert.triggered webhook.

Landsat, Sentinel-2 and SMAP

The same pipeline applies with different details. Landsat surface reflectance products carry their own scale and offset per collection, and bands B4 (red) and B5 (near infrared) of Landsat 8 are used to compute NDVI at 30 m, with B6 (shortwave infrared) useful for moisture-sensitive indices. Sentinel-2 provides 10 m red and near-infrared bands and a scene classification layer for cloud masking. Landsat and Sentinel-2 resolve individual restoration plots and half-moon fields that MODIS cannot, at the cost of more cloud gaps. SMAP SPL4SMGP is a model-assimilated Level-4 product on a 9 km grid issued in sub-daily time steps; the specification's "daily" cadence is best implemented as a documented daily aggregate. A 9 km cell is larger than many project areas, so SMAP values belong in the regional context of a soilData record, clearly separated from in-situ probe readings in moisture.depthProfile[].

Climate sources

PHASE-4 §7 lists NOAA Climate Data Online, ECMWF, the World Meteorological Organization and local stations as climate sources. ECMWF's ERA5 reanalysis provides hourly fields on a 0.25-degree grid, including precipitation, soil moisture and evaporation, from which potential evapotranspiration and aridity context can be derived. NOAA's Climate Data Online serves mainly station records; the "1km, global" description in the spec's example should be treated as illustrative. For rainfallData, the adapter should prefer local gauges where they exist, fill with gridded products where they do not, and record the source per value — mixing gauge and reanalysis totals in one series without a flag produces artificial trends. The processingPipeline block in the example (standardise to WIA format, store in a time-series database, expose through API and WebSocket) is a sound summary of the target architecture that Chapter 7 develops.

6.3 Agriculture, Soil and Water Partners

Agricultural statistics

Land use and grazing pressure are often explained better by agricultural statistics than by imagery. PHASE-4 §2.1 proposes a two-way exchange with FAO: pulling indicators such as crop production and livestock density, and pushing soil-health summaries. The pull side in the specification uses an API key and an SDK; in reality FAOSTAT publishes its data openly, and an adapter would download the relevant domains and store them as reference tables with their version and download date. These statistics are national or sub-national; they give context to landUseData.pressure but cannot replace a site-level stocking-rate estimate.

The push side, faoDataSubmission, carries a dataType, country and region, a list of measurements per locationId (soil type, organic matter, pH, erosion risk, degradation level) and a methodology statement. Two cautions. The qualityAssurance value "ISO-19115-compliant" describes metadata conformance; ISO 19115 is a geographic metadata standard and says nothing about the accuracy of soil measurements, so the claim should be phrased as "metadata aligned with ISO 19115". And the region name in the example ("Kayes") is free text. Administrative names should be produced by a spatial join of the location geometry against a maintained boundary dataset, never typed, because free-text regions are the most common cause of mis-assigned records in aggregated statistics.

Soil data sharing

The Global Soil Partnership example is a data-sharing agreement rather than an API: soil moisture, soil chemistry and erosion assessments, shared monthly, in a soil markup format, under the CC-BY-4.0 licence. The licence is the part engineers overlook. CC-BY-4.0 permits reuse with attribution, which is compatible with public reporting but must be checked against any restrictions in the original field data — land-holder consent, for example. The WIA record should carry a licence and an attribution string so that downstream copies preserve them. For the exchange format, ISO 28258 (digital exchange of soil-related data) is the relevant international reference; a WIA adapter maps soilData fields to it rather than inventing a private schema. Units are the critical detail: Chapter 3 recommended per-field units, and here that recommendation pays off, because a partner cannot guess whether organic matter is a percentage or a concentration.

Water resources

PHASE-4 §5 describes a waterResourceData exchange: surface water, groundwater (depth to water, quality, withdrawal rate), rainfall reliability, rainwater-harvesting structures, irrigation (type, area, efficiency, source) and drought indicators. It is the input restoration planners need to decide whether a planting design can survive the dry season. The example also illustrates why each index needs its own classification. It gives SPI −1.8 and PDSI −2.5 with a single category, "moderate-drought". On the Palmer scale, −2.5 falls in the moderate drought band (−2.0 to −2.99); under the McKee SPI classes, −1.8 is severely dry. One label cannot describe both. The adapter should store a category per index, with the index's time scale and reference period. The example's harvesting capacity also lacks a unit — a small omission that becomes a large error when volumes in litres and cubic metres are summed across projects.

The coordination workflow in §5 (needs assessment, resource availability check, joint planning, implementation, feedback) is a management process, not an API call. The specification names the World Water Council as the counterpart; the standard does not establish any such partnership, and in most deployments the counterpart is a national water agency or a basin authority.

6.4 Restoration Programme Networks

Connector roles

Restoration projects rarely report to one programme. A Sahel planting site may be part of a national Great Green Wall component, count toward a country's AFR100 or Bonn Challenge pledge, and receive seedlings through a tree-planting organisation. PHASE-4 §3 and §6 model this with connector roles rather than bespoke integrations.

These roles describe what kind of data would flow; they do not mean that any of these organisations has agreed to receive WIA data. In a real deployment each connector is configured per agreement.

The Great Green Wall object and dashboard

The greatGreenWallIntegration object ties a programme project ID to a corridor, a segment and a WIA locationId, and carries progress metrics, a monitoring frequency and method, and coordination flags. The dashboard endpoint GET /api/v1/integrations/great-green-wall/dashboard returns an overview, regional progress and recent updates. The aggregates in the example response are placeholders and must not be read as Great Green Wall statistics; the initiative publishes its own figures.

The more instructive detail is an inconsistency. The tree count in the integration object does not match the sum of species quantities in the restorationProject record for the same site. In a specification that is an editorial slip; in production it is exactly the double-counting problem that makes restoration claims hard to trust. The rule for adapters is that programme-facing numbers are always derived from the canonical WIA records — never entered separately — and every export carries the record IDs it was derived from. When a site reports to three programmes, it reports one set of planted trees, tagged with all three programme IDs, not three independently maintained counts.

Tree-level registries

PHASE-4 §6.2 sketches a tree registry with records containing treeId, species, planting date, coordinates, the linked projectId (REST-2025-SAHEL-001), verification status and date, survival status and a certificate URL. That structure is useful for monitoring survival and for audit sampling: an auditor can draw a random sample of tree IDs and check them in the field or in very-high-resolution imagery.

The specification places this registry on a distributed ledger with a smart contract and token IDs. That is one possible design, and it is optional. WIA-ENE-057 does not require a blockchain; its own integrity mechanism is the signed manifest and the Sigstore/Rekor transparency log described in Chapter 8. Before choosing a ledger, weigh the practical questions: per-tree geolocation of planting on community or private land can be sensitive; survival status changes over time, which suits an append-only log of observations better than a token; and immutability does not make a false entry true. A signed, append-only table with periodic anchoring provides tamper evidence without those costs.

6.5 GIS Platforms and Field Apps

Desktop and web GIS

Analysts consume WIA data mostly through GIS software. PHASE-4 §8.1 shows an ArcGIS Online feature service with two layers: a polygon layer "Desertification Risk" (fields locationId, riskScore, category, graduated colours, weekly update) and a point layer "Vegetation Monitoring Points" (ndvi, evi, timestamp, daily update). The organisation URL in the example is illustrative. Publishing to a commercial platform is a convenience; the vendor-neutral path is the OGC WMS, WFS and WCS endpoints described in Chapter 5, which any desktop GIS, including QGIS and ArcGIS Pro, can read.

Two design points apply to either route. The risk layer should carry the version of the scoring method and the date of the assessment, because a map of risk categories without the thresholds behind them — which, as Chapter 4 noted, the specification does not define — cannot be interpreted. And point layers of vegetation indices should include the product and quality flags; a map mixing 250 m MODIS values with 10 m Sentinel-2 values looks continuous and is not.

The §8.2 QGIS plugin metadata is presented as XML. Actual QGIS plugins declare their metadata in a metadata.txt file, so the example should be read as a feature list — load current vegetation indices, compute risk, generate restoration plans, export LDN reports — rather than as a file format. A plugin is a thin client of the PHASE-2 API and inherits its authentication; it must not embed a shared API key in distributed code.

Field survey forms

Ground observations remain essential for calibrating imagery and for verifying restoration. PHASE-4 §10.1 shows an ODK form, wia-ene-057-field-survey version 1.0.0, with a required geopoint, a locationId, a decimal vegetation cover, a select1 soil type (sandy, loam, clay) and a site photo, submitted by POST to /v1/mobile/submission. The XML is a simplified sketch; ODK forms are usually authored as XLSForm and delivered as XForms, and submissions normally land on an ODK server from which an adapter pulls them. Whichever route is chosen, the adapter has three mapping jobs.

• Coordinates. An ODK geopoint is a space-separated string of latitude, longitude, altitude and accuracy. The adapter must split it into the WIA coordinates object with WGS84 datum and keep the accuracy value, because a point recorded with 30 m accuracy near a plot boundary may belong to the neighbouring plot.
• Vocabularies. The form's three soil choices do not match the textures used in soilData.soilType (the running example uses sandy-loam). A mapping table must say how a field choice becomes a WIA value, or the form should be extended to use the WIA vocabulary directly.
• Provenance. Each submission becomes a record with the form ID and version, the device, the collector's pseudonymous ID and the submission time, so that a later form revision can be distinguished from a change on the ground.

Community monitoring

The §10.2 mobile SDK example records observations such as vegetationHealth: 'fair' and soilMoisture: 'low', with photos and notes, in offline mode with a syncInterval of 3,600,000 ms (one hour). Offline-first operation is right for drylands, where connectivity is intermittent. The data-quality issues are predictable: phone GPS error, subjective categories that differ between observers, duplicate uploads after a failed sync, and clock drift on devices that have been offline for days. Store community observations as a distinct observation type with the observer's training level and the category definitions shown to them, and use them to flag places for expert checks rather than as direct inputs to indicators. Photos raise a privacy issue discussed in section 6.7: EXIF metadata can carry precise location and device details, and a photo of a homestead can identify its owners.

6.6 Carbon Accounting and Credits

A worked conversion

Restoration projects increasingly look to carbon finance, and PHASE-4 §9 includes a carbonCreditProject example for REST-2025-SAHEL-001. Its carbon-stock figures (the same ones used in the LDN example, which is itself a sign that they are placeholders) allow a clean arithmetic walk-through. The numbers below are illustrative example values.

Illustrative example (PHASE-4 §9 values, not measurements)

Carbon stock per hectare (t C/ha)      baseline   monitoring
  above-ground biomass (AGB)             2.8        3.5
  below-ground biomass (BGB)             1.2        1.6
  soil organic carbon (SOC)             18.5       19.8
  total                                 22.5       24.9

Change per hectare      24.9 - 22.5 = 2.4 t C/ha
Area                    450 ha (reforestation intervention)
Total carbon            2.4 x 450  = 1,080 t C
Convert C to CO2        x 44/12    (molar mass CO2 / molar mass C, about 3.667)
CO2 equivalent          1,080 x 44/12 = 3,960 t CO2e

The factor 44/12 converts a mass of carbon to the mass of carbon dioxide that contains it: one tonne of carbon corresponds to about 3.67 tonnes of CO₂. That part is physics. Everything around it is assumption. Applying a per-hectare change measured for the whole location to the 450 ha intervention area assumes the change occurred on exactly that area. More than half of the gain in this example comes from SOC (1.3 of 2.4 t C/ha), and SOC changes of that size over a few years are small relative to spatial variability; detecting them needs a sampling design with enough cores, fixed depths and bulk density measured each time. Within the specification the carbon figures are not consistent either: the restorationProject outcome and the LDN summary give a different sequestration total from this 3,960 t CO₂e. An implementation should compute carbon from records, show the computation, and never copy such totals between objects.

From tonnes to credits

The example sets creditsPotential equal to co2Equivalent. That equality is the error to avoid. A carbon credit is issued by a registry under an approved methodology, and the methodology determines how much of a stock change is creditable. Among the adjustments that typically apply:

• Baseline scenario. Credits count the difference from what would have happened without the project, not the difference from a past year. If vegetation would have recovered anyway after good rains, that recovery is not creditable.
• Additionality. The project must show that the activity would not have occurred without carbon finance.
• Leakage. If grazing excluded from the project area moves to neighbouring land and degrades it, the emissions caused there are deducted.
• Permanence. Removals in trees and soil can be reversed by fire, drought or clearing; registries require a share of credits to be held in a buffer pool against reversal risk.
• Uncertainty. Measurement and model uncertainty lead to conservative deductions.
• Validation and verification. An independent validation/verification body checks the project design and each monitoring report before issuance.

The stock-change figure is therefore an upper bound on what a methodology might credit, and often a loose one. WIA adapters should label it as "gross stock change" and leave creditsPotential empty unless it comes from a methodology calculation with its version recorded. The specification's example names a specific Verra methodology code; that code does not correspond to a reforestation methodology, which is one more reason this book does not cite methodology codes. The registries listed in PHASE-4 — Verra (VCS), Gold Standard, American Carbon Registry and Climate Action Reserve — each maintain their own methodologies and procedures, and the choice among them is a project decision. The role of WIA-ENE-057 is to supply well-documented monitoring records that a methodology can use; it does not by itself make a project creditable. Note also that the LDN carbon sub-indicator and a carbon credit answer different questions — whether land is degrading versus how much additional removal a project caused — and one number should not be relabelled as the other.

6.7 Integration Security and Service Levels

Credentials and keys

Every connector in this chapter holds credentials to an external system or exposes data to one. PHASE-4 §11.1 sets a key-management policy: rotate keys every 90 days, warn 7 days before expiry, store keys in an encrypted vault and control access by role. Two practices follow. Each partner gets its own credential with the narrowest scopes it needs — an LDN export job needs to read assessments and write reports, not to modify restoration plans — so that revoking one partner does not break the others. And rotation must be rehearsed: the 7-day warning is useful only if an alert reaches a person who can act, and an adapter should support two valid keys at once during the changeover.

Data classification and personal data

Encryption follows the rest of the standard: TLS 1.3 in transit and AES-256-GCM at rest. The personal data in a desertification platform is easy to underestimate. Field collectors, community monitors and land holders appear in submissions through names, phone numbers, GPS tracks and photos. Where the GDPR applies, the specification lists the relevant rights and principles — data minimisation, access, erasure, portability and consent management; in Korea, the Personal Information Protection Act (K-PIPA) imposes comparable duties on Korean operators, including those that run ODA field projects. Practically: pseudonymise collector IDs in every record that leaves the platform, strip location and device EXIF fields from photos before they are shared (keeping the original in restricted storage if needed for verification), and generalise precise coordinates of homesteads in public layers. Erasure requests must be reconcilable with audit retention; the usual approach is to delete or pseudonymise the personal fields while keeping the non-personal measurement and its hash chain.

Service levels and integration health

These are targets the specification sets for design, not guarantees. Integrations need their own health view, which PHASE-4 §12.2 sketches as an integrationHealth object: per partner, a status, the time of the last successful sync or retrieval, success and failure counts and a data-quality score. The most useful field is the timestamp of the last success, because integrations usually fail quietly — a revoked token, a renamed product collection, a changed download path — and a status that says "healthy" based on the absence of errors can hide weeks without new data. Alert on staleness, not only on errors. Satellite latency is the other variable: a 16-day composite becomes available some days after its period ends, so the five-minute latency target applies to sensor streams, not to imagery.

One configuration, all connectors

Bringing the chapter together, the following configuration shows how an implementation might declare its connectors in one place. Hostnames use example.org on purpose: the real endpoints depend on agreements with each partner. Secrets are references to a vault, never values.

{
  "integrations": [
    {
      "id": "ldn-export",
      "kind": "report-export",
      "trigger": "POST /api/v1/reports/unccd-ldn",
      "reportingCountry": "MLI",
      "locations": ["SAHEL-REGION-001"],
      "baselinePeriod": { "start": "2000-01-01", "end": "2015-12-31" },
      "ruleSet": "one-out-all-out",
      "deliver": { "method": "signed-package", "recipient": "national-ldn-focal-point" },
      "cadence": "P3M"
    },
    {
      "id": "modis-ndvi",
      "kind": "eo-ingest",
      "product": "MOD13Q1",
      "collection": "061",
      "variables": ["NDVI", "EVI", "pixel_reliability"],
      "scaleFactor": 0.0001,
      "resampling": "nearest",
      "clipTo": "location-geometry",
      "credentialsRef": "vault://integrations/earthdata",
      "writes": "vegetationData"
    },
    {
      "id": "soil-share",
      "kind": "data-sharing",
      "dataTypes": ["soil-moisture", "soil-chemistry", "erosion-assessment"],
      "cadence": "P1M",
      "license": "CC-BY-4.0",
      "endpoint": "https://soil-partner.example.org/upload"
    },
    {
      "id": "field-survey",
      "kind": "field-form",
      "formId": "wia-ene-057-field-survey",
      "formVersion": "1.0.0",
      "vocabularyMap": { "soilType": "maps/odk-soil-to-wia.json" },
      "privacy": { "pseudonymiseCollector": true, "stripPhotoExif": true }
    }
  ],
  "security": { "keyRotationDays": 90, "expiryWarningDays": 7 },
  "health": { "alertIfNoSuccessFor": "PT48H" }
}

The baseline period and the 48-hour staleness threshold here are example choices, not values set by the standard.

Chapter Summary

• PHASE-4 defines the shape of exchanges with external programmes; it does not create partnerships, and the hostnames, SDK packages and aggregate figures in its examples are illustrative.
• LDN reporting maps landUseData, vegetationData and soilData to land cover, productivity and SOC, combined by "one out, all out". In the example, declining productivity makes the site degraded despite gains in cover and carbon. Fields such as progress and neutralityGap are not UNCCD metrics.
• Earth-observation pipelines succeed or fail on scale factors, quality masks, resampling, clip geometry and valid-pixel fractions. Record the product, collection and processing for every value.
• Agricultural, soil and water exchanges need explicit units, licences, spatially derived region names and a separate category per drought index.
• Programme-facing numbers must be derived from canonical records to avoid double counting; a ledger-based tree registry is an optional design, not a WIA requirement.
• GIS and field-app connectors must preserve product and quality metadata, map vocabularies and coordinates carefully, and protect collector privacy.
• Carbon arithmetic (2.4 t C/ha × 450 ha × 44/12 = 3,960 t CO₂e) gives a gross stock change, an upper bound; credits require a methodology, baseline, additionality, leakage, permanence buffers and verification.
• Integration security relies on per-partner keys, 90-day rotation, classification, personal-data minimisation and health monitoring that alerts on stale data.

Chapter 7 turns these connectors into a running system: a reference architecture, deployment profiles, field connectivity and a season-long walkthrough of SAHEL-REGION-001.