Chapter 8: Conformance Testing, Certification and the Road Ahead

The previous seven chapters described what a WIA-ENE-057 implementation does: it accepts vegetation, soil, rainfall and land-use records for a location such as SAHEL-REGION-001, scores desertification risk, tracks restoration projects, streams alerts and exchanges data with GIS tools and reporting frameworks. This final chapter asks a different question: how does anyone outside the implementation come to believe that it does those things correctly? A land-monitoring platform is only useful to a ministry, a donor or an auditor if its outputs can be checked without taking the vendor's word for it.

The standard answers with three conformance tiers, a test-vector discipline, a signed evidence package and a small command-line tool. It also leaves several gaps that an honest implementer has to fill, because some of the artefacts the specification refers to are not shipped in the repository. The chapter covers both: what the text requires, and what you will have to build yourself. It closes with a look at where desertification monitoring is heading and at the risks that a well-engineered data standard can reduce but not remove. The matching simulator tab is the fifth one, QR & VC, which issues an illustrative restoration certificate; it is a useful prop for the discussion of verifiable credentials in Section 8.7.

8.1 Conformance Tiers

Three levels of assurance

The README and PHASE-2 API-INTERFACE §3 define the same three tiers in a single sentence each: Surface means "data formats accepted; self-attested", Verified means "annual third-party audit", and Anchored means "continuous evidence package per Annex G". The tiers are cumulative in practice. An Anchored claim that could not pass a Surface check would be meaningless, so auditors should treat each tier as including the obligations of the one below it. Note also that Annex E of every PHASE document tells auditors to score a deployment "against the correct conformance tier in Annex A"; no Annex A exists in the repository, so the README table and API-INTERFACE §3 are the only definitions.

The tiers do not describe how good the monitoring is. A Surface implementation can hold excellent data and a Verified implementation can hold poor data. What the tiers grade is the strength of the evidence that the implementation behaves as the standard says: whether anyone other than the implementer has looked, and whether the evidence is refreshed often enough to notice when behaviour drifts.

Table 8-1. Conformance tiers: evidence, cadence and signatories
Tier	Evidence expected	Cadence	Who signs
Surface	Manifest declaring the tier; OpenAPI document with `x-wia-conformance-tier`; discovery document; self-run test-vector matrix for the PHASE-1 data formats	With each release that changes a declared requirement	The implementer alone
Verified	Everything in Surface, plus an audit report in which an independent party re-runs or witnesses the vectors, inspects the deployment policy, and samples production records	Annual audit, with the manifest re-signed after each audit	Implementer signs the manifest; the auditor signs the audit report
Anchored	Everything in Verified, plus the Annex G evidence package (SBOM, OpenAPI, vector matrix, signed manifest) produced by CI and recorded in the Rekor transparency log	Every release, and at least quarterly even without code change	Implementer's Sigstore identity; the log entry supplies an independent timestamp

Two cells in this table go beyond the literal text and should be read as recommendations. The specification does not say who qualifies as a "third party" for the Verified tier, and it does not say what cadence Surface requires. The choices above follow the logic of the other two tiers; an implementer who adopts different ones should state them in the deployment policy so that an auditor knows what was promised.

Declaring the tier

§3 requires the tier to be declared in the OpenAPI document through the x-wia-conformance-tier extension field. OpenAPI 3.1 allows x- extensions on most objects; the natural place is the info object, next to the API version. Annex E adds that the operational scope (single-tenant, multi-tenant, federated) SHOULD also be declared there, so that auditors score the deployment against the right expectations.

openapi: 3.1.0
info:
  title: Sahel land-monitoring API (example deployment)
  version: 1.0.0
  x-wia-conformance-tier: Verified
  x-wia-operational-scope: single-tenant
servers:
  - url: https://monitoring.example.org/api
paths: {}   # the real document lists every operation the deployment exposes

The second extension name, x-wia-operational-scope, is not fixed by the standard; it is used here as an example. The repository's own api/openapi.yaml is a seven-line stub describing a generic /resource path, so it cannot serve as the conformance document. Each implementation has to publish its own complete OpenAPI description of the monitoring, assessment, restoration, location, alert and report operations it actually offers.

What an auditor checks

At the Surface tier an auditor, or a careful customer, checks consistency: the tier in the OpenAPI document matches the tier in the manifest and in the discovery document at /.well-known/wia/desertification-prevention; the discovery response is signed with the same key as the manifest (§4); and the vector matrix covers every requirement the manifest marks as supported.

At the Verified tier the auditor re-executes the vectors or watches them run against the production build identified by the manifest's implementation.build digest, not against a demonstration environment. The auditor also reads the deployment policy for the items the standard leaves to it: the regulatory regime for personal data (§7), key-rotation cadence, clock synchronisation (§5 asks for NTPv4 at stratum 2 or better), audit-log retention, and the Rekor anchoring cadence. Sampling production records matters here. A platform can pass every negative vector and still hold records that should never have been accepted, for example a batch loaded directly into the database before validation existed.

At the Anchored tier the auditor's job shifts from inspection to verification of a chain: the evidence package's signature verifies, its log entry exists, its SBOM matches the deployed image, and consecutive quarterly packages show no unexplained change. The auditor still visits, but most of the evidence is continuously available to anyone.

8.2 Test Vectors and Test Design

One positive, one negative, for every requirement

Annex G in each PHASE document states that every normative requirement has at least one positive vector and one negative vector, stored under a directory such as tests/phase-vectors/phase-1-data-format/, and that implementations claiming conformance MUST run all vectors in CI and publish the pass/fail matrix. In the current repository that directory does not exist. The same is true of api/typescript/, which the README lists as a reference SDK. Until the working group publishes official vectors, every implementer has to write their own. That is less wasteful than it sounds: writing a negative vector forces you to decide what "reject" means for your system (an HTTP status, a Problem Details body per RFC 9457, a quarantine flag), and those decisions belong in your manifest anyway.

A positive vector is an input the implementation must accept, together with the expected stored or returned result. A negative vector is an input it must reject or flag, together with the expected rejection. The distinction between reject and flag comes from PHASE-1 §7.2, which assigns different error handling to different fields: an NDVI outside −1 to 1 or an invalid coordinate is rejected, while soil moisture above 60 % or a negative rainfall value is flagged for review. A vector that only checks "some error occurred" would pass an implementation that rejects plausible wet-season soil readings, which the standard explicitly says to keep and review.

Table 8-2. A starter set of vectors (identifiers are examples, not official)
Vector ID	Input	Expected result	Basis
`P1-NDVI-001-NEG`	`vegetationData` with NDVI 1.5	Rejected; error names the field and value	PHASE-1 §7.2 (NDVI in −1..1)
`P1-NDVI-001-POS`	Same record with NDVI −0.05 (open water or bare, wet surface)	Accepted unchanged	PHASE-1 §7.2
`P1-COORD-001-NEG`	Location with latitude 95	Rejected	PHASE-1 §7.2 (valid lat/long)
`P1-SOILM-001-FLAG`	`soilData` with soil moisture 70 %	Accepted and marked for review, not rejected	PHASE-1 §7.2 (flag if > 60 %)
`P1-RAIN-001-FLAG`	`rainfallData` with a daily total of −3 mm	Flagged; value not used in aggregates until reviewed	PHASE-1 §7.2 (flag negative values)
`P1-COVER-001-NEG`	Land-cover percentages summing to 112	Rejected or flagged, as the manifest declares	Implementer-derived: shares of one area cannot exceed 100
`P1-LOCID-001-NEG`	Any record without `locationId`	Rejected	Records are joined by `locationId`; an orphan cannot be reported
`P3-HOOK-001-NEG`	Webhook body with an altered `X-WIA-Signature`	Receiver discards; no event processed	PHASE-3 webhook HMAC-SHA256
`P2-AUTH-001-NEG`	Request with an expired bearer token	HTTP 401, no data in the body	PHASE-2 status codes; §5 time-bound tokens
`P2-TLS-001-NEG`	Client offering TLS 1.2 only	Handshake refused	API-INTERFACE §7 (TLS 1.3 MUST)

The last row needs a comment. API-INTERFACE §7 requires TLS 1.3, while PHASE-3 §5.1 accepts TLS 1.2 or later. This book treats TLS 1.3 as the requirement because it is the stricter statement and the one expressed with MUST. An implementation that must still accept TLS 1.2 from older field gateways should record that as a partial requirement in its profile manifest, with a reason, rather than quietly passing a weakened vector.

Vectors that carry exact expected values

Where an output is deterministic, the vector should contain the exact expected value rather than a description. Webhook signing is the clearest case. PHASE-3 specifies an HMAC-SHA256 over the raw request body, sent as X-WIA-Signature: sha256=<hex>. The following vector was computed for this book with a throwaway secret; any correct sender must produce the same string for the same bytes.

{
  "vectorId": "P3-HOOK-001-POS",
  "secret": "test-secret-do-not-use",
  "body": "{\"eventId\":\"evt-20251225-001\",\"eventType\":\"alert.triggered\"}",
  "bodyLength": 60,
  "expectedHeader": "sha256=ce4ae670bcfc61f9965a25941f90b73d920f3f3e8e973d86d3600abda86a0996"
}

The body is 60 bytes with no whitespace and no trailing newline. That detail is the point of the vector: a receiver that parses the JSON and re-serialises it before verifying will compute a different digest as soon as a sender adds a space. The negative twin, P3-HOOK-001-NEG, flips one hexadecimal digit of the header and expects the event to be discarded. A third vector worth adding sends a header of the wrong length; the reference verification code in PHASE-3 passes both buffers to crypto.timingSafeEqual, which throws when lengths differ, so an implementation copied from it needs a length check first or the "rejection" becomes an unhandled exception.

Layers of tests

It helps to organise vectors by the layer they exercise, because each layer fails differently.

Schema layer — types, required fields, enumerations. Mostly automatic with JSON Schema 2020-12, but only if the schema is actually wired into the ingest path and not just published beside it.
Semantic layer — rules a schema cannot express well: coverage shares that sum to 100, a startDate before an endDate, a soil-moisture reading flagged rather than rejected. These are where most real defects live.
API behaviour — status codes, Problem Details bodies, pagination, idempotent retries, rate-limit headers. Note that the rate-limit tiers and the availability and latency figures in the specification (for example 99.9 % availability or p95 below 200 ms) are design targets; a vector can check that the headers exist, not that a promise has been kept.
Protocol layer — WebSocket subscription semantics, MQTT topic names and QoS, webhook signatures and retries.
Security layer — token expiry, scope enforcement, TLS version, access to another tenant's locationId.

Negative results and skipped tests

Annex G is unusually direct on two points, and both deserve to be built into the CI pipeline rather than left to reviewers. Vendors MUST report negative results with the same fidelity as positive ones, and a test skipped without recorded justification is treated as a failure. In practice that means the published matrix contains every vector, with one of three outcomes, and a skip is only acceptable when it points to an excluded or partial entry in the profile manifest.

{
  "matrixFor": "sha256:4f1c...e09a",
  "generatedAt": "2026-01-15T03:10:00Z",
  "results": [
    { "vectorId": "P1-NDVI-001-NEG",  "outcome": "pass" },
    { "vectorId": "P1-SOILM-001-FLAG", "outcome": "fail",
      "observed": "HTTP 400 (record rejected)", "expected": "accepted + review flag" },
    { "vectorId": "P2-TLS-001-NEG",   "outcome": "skip",
      "justification": "requirement marked partial in profile manifest: legacy field gateways" }
  ]
}

The matrix above is an example. Its field names are not defined by the standard, and the digest is truncated for readability. The failing row is realistic: rejecting high soil-moisture readings is a common shortcut, and publishing the failure is exactly what the annex asks for.

8.3 The Evidence Package

Annex G describes the compliance package as a tarball containing four things: a software bill of materials (CycloneDX 1.5 or SPDX 2.3), the OpenAPI document, the test-vector matrix, and a signed manifest. Signatures use Sigstore: a DSSE (Dead Simple Signing Envelope) around the signed payload and an entry in the Rekor transparency log, so that anyone can verify provenance without trusting a private certificate authority. The CLI help also lists the in-toto Attestation Framework 1.0, which supplies a standard wrapper for saying "this statement is about these exact files".

evidence-2026Q1.tar.gz
├── manifest.json                 signed manifest (§2)
├── manifest.dsse.json            DSSE envelope over manifest.json
├── profile-manifest.json         per-requirement status (Annex I)
├── openapi.yaml                  full API description with x-wia-conformance-tier
├── discovery.json                copy of /.well-known/wia/desertification-prevention
├── sbom/
│   └── sbom.cdx.json             CycloneDX 1.5 (or sbom.spdx.json, SPDX 2.3)
├── vectors/
│   ├── matrix.json               pass / fail / skip for every vector
│   └── logs/                     raw CI output per PHASE
├── attestations/
│   └── evidence.intoto.jsonl     in-toto statement(s) naming every file above by digest
└── transparency/
    └── rekor-entry.json          log index and inclusion proof for the signature

Figure 8-1. One possible layout of an evidence package. Annex G fixes the four core contents; the directory names and the extra files are suggestions.

Why each piece is there

The SBOM lets a consumer see which libraries process their data and match them against published vulnerabilities; for a land-monitoring platform that means the raster and projection libraries as much as the web framework. The OpenAPI document fixes what the vectors were run against. The matrix is the result. The manifest ties them to one build digest and one profile. None of the four is persuasive alone; together, and signed, they let a consumer ask a precise question — was this build, described by this SBOM and this API, tested against these vectors with these results — and get a verifiable answer.

An in-toto statement makes the binding explicit. Its subject lists the files by digest and its predicate carries whatever claim is being made about them. The predicate type below is invented for this example, because the standard does not define one.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    { "name": "manifest.json",       "digest": { "sha256": "9b2e...71c4" } },
    { "name": "sbom/sbom.cdx.json",  "digest": { "sha256": "c03a...5d18" } },
    { "name": "vectors/matrix.json", "digest": { "sha256": "e6f0...02ab" } }
  ],
  "predicateType": "https://example.org/wia-ene-057/evidence/v1",
  "predicate": {
    "standardSlug": "desertification-prevention",
    "tier": "Anchored",
    "period": "2026-Q1"
  }
}

With the cosign tool from the Sigstore project, signing and verifying a blob can look like the following. The identity and issuer values are placeholders; in keyless signing they come from the CI system's OpenID Connect token, and the verifier must pin them, otherwise any valid Sigstore identity would pass.

$ cosign sign-blob --bundle evidence-2026Q1.sigstore.json evidence-2026Q1.tar.gz
$ cosign verify-blob --bundle evidence-2026Q1.sigstore.json \
    --certificate-identity "https://ci.example.org/release@refs/heads/main" \
    --certificate-oidc-issuer "https://issuer.example.org" \
    evidence-2026Q1.tar.gz
Verified OK

Quarterly re-publication

Annex G asks implementations to re-publish the package every quarter even when the source has not changed. The reason is environmental drift: a base image picks up new system libraries, a dependency resolves to a newer minor version, a projection database is updated and coordinate transforms shift slightly. None of these appears in the implementer's own commit history, yet each can change behaviour. A fresh SBOM and a fresh vector run make the drift visible. Comparing two consecutive packages is easy to automate: list the SBOM components that changed and the vectors whose outcome changed, and publish that difference alongside the new package. An unchanged SBOM with a changed outcome is the most interesting case, and usually points to data or configuration rather than code.

Annex G also mentions a cross-vendor crosswalk that maps each vector to equivalent assertions in adjacent programmes, maintained by the working group. It is not in the repository at the time of writing. Implementers should not claim credit under it until it is published.

8.4 Manifest, Profiles and the CLI

The manifest

API-INTERFACE §2 lists what a signed manifest contains: standardSlug with the constant value "desertification-prevention", version in Semantic Versioning, implementation (name, build digest and SBOM URL), profile (name and version), per-requirement support status, and a Sigstore DSSE signature anchored in Rekor at the cadence the deployment policy declares. The CLI's manifest-template command prints a skeleton that covers the first four items. It leaves out the per-requirement status and the signature, which the implementer has to add; the signature normally lives in the DSSE envelope next to the manifest rather than inside it.

A CLI session

The CLI is a short shell script, cli/desertification-prevention.sh. The transcript below was produced by running it (colour codes removed). It shows both what the tool does and where it stops.

$ ./desertification-prevention.sh info
WIA desertification-prevention
Version: 1.0.0

Conformance tiers (see README.md): Surface / Verified / Anchored.
Conformance package follows CycloneDX 1.5 + Sigstore (DSSE + Rekor).

弘益人間 (Benefit All Humanity)

$ ./desertification-prevention.sh profiles
Supported conformance profiles for desertification-prevention:

  - single-tenant      one runtime per organization
  - multi-tenant       shared runtime, header-based isolation
  - federated          peer-to-peer mesh of runtimes
  - air-gapped         batch evidence package, no live connectivity

Profile manifests are signed using Sigstore (DSSE envelope) and the
signing key is rotated per the deployment policy.

$ ./desertification-prevention.sh manifest-template > manifest.json
$ cat manifest.json
{
  "documentId": "wia-desertification-prevention-XXXX",
  "standardSlug": "desertification-prevention",
  "version": "1.0.0",
  "implementation": {
    "name": "REPLACE_ME",
    "build": "git-sha-or-image-digest",
    "sbom": "https://example.com/sbom.cdx.json"
  },
  "profile": { "named": "single-tenant", "version": 1 },
  "issuedAt": "2026-04-26T00:00:00Z"
}

$ ./desertification-prevention.sh validate manifest.json
OK: manifest.json declares standardSlug=desertification-prevention

$ echo '{"standardSlug":"desertification-prevention","version":"banana"}' > odd.json
$ ./desertification-prevention.sh validate odd.json
OK: odd.json declares standardSlug=desertification-prevention

$ echo '{"standardSlug":"x"}' > wrong.json
$ ./desertification-prevention.sh validate wrong.json
standardSlug mismatch: got 'x', expected 'desertification-prevention'
$ echo $?
1

What `validate` does not do

The transcript makes the limits plain. validate checks exactly one thing: that the file's standardSlug equals desertification-prevention. It accepted the untouched template with REPLACE_ME and a placeholder build string, and it accepted a document whose version is "banana". It does not check SemVer syntax, does not check that the build is a real digest, does not fetch the SBOM, does not look at requirement statuses, and does not verify any signature. It also knows nothing about PHASE-1 records: running it on a vegetationData file with an NDVI of 1.5 would only complain that the slug is missing. Treat it as a smoke test for manifests, never as a conformance check.

One more detail matters if the tool is reused in automation. When jq is not installed, the script falls back to a Python one-liner into which the file name is pasted directly. A file name containing a quote character would break out of the string. The fallback is harmless for files you created yourself, but a CI job that validates uploaded files should install jq or replace the fallback.

A useful local extension adds the missing checks in the same spirit: validate version against the SemVer 2.0.0 grammar, require implementation.build to look like sha256: followed by 64 hexadecimal characters, refuse the literal REPLACE_ME, and require every requirement ID in the profile manifest to appear in the vector matrix. Signature verification belongs to cosign, not to this script.

Profile manifests and profile names

Annex I adds a second document, the profile manifest, which lists the normative requirement IDs and gives each a status: supported, partial with a reason, or excluded with a justification. It is signed with the same key as the SBOM. Its purpose is stated clearly: to let deployments of different scope advertise what they satisfy "without misrepresenting partial conformance as full conformance". The requirement IDs below are examples, since the standard does not yet number its requirements.

{
  "standardSlug": "desertification-prevention",
  "profile": { "named": "WIA-P2-API-INTERFACE-Edge-only", "version": 2 },
  "requirements": [
    { "id": "P1-7.2-NDVI",  "status": "supported" },
    { "id": "P2-7-TLS13",   "status": "partial",
      "reason": "two legacy field gateways negotiate TLS 1.2; replacement scheduled" },
    { "id": "P3-MQTT",      "status": "excluded",
      "justification": "edge deployment receives sensor data by file transfer only" }
  ]
}

Two naming systems coexist and should not be confused. The CLI's profiles command lists four deployment shapes: single-tenant, multi-tenant, federated and air-gapped. Annex I describes a public registry of named profiles such as "Edge-only" or "Federated-with-replay", versioned with SemVer rules, so that WIA-P2-API-INTERFACE-Edge-only/2 means the second major version of that named profile. Registry entries are immutable; a changed shape gets a new name. Federated deployments publish an aggregated manifest summarising the union and intersection of their members' profiles, so that a directory service can route a request to a peer that supports what the caller needs. For an air-gapped monitoring station in a region without reliable connectivity, the evidence package itself becomes the transport: it is carried out of band and verified on arrival, and the Rekor entry is created when it reaches a connected system.

8.5 Versioning, Deprecation and Governance

What each version number means

The standard uses Semantic Versioning 2.0.0 for both itself and implementations. A major bump means a backwards-incompatible change to a normative requirement; a minor bump adds normative requirements without breaking existing implementations; a patch is editorial only. Errata are issued as patch releases, recorded in a public errata register, and each entry is signed by the working group chair.

There is one internal inconsistency worth knowing. Annex E says that renaming or removing fields, "even in error payloads", MUST trigger a minor bump, while §8 and Annex H say that backwards-incompatible changes trigger a major bump. Removing a field that clients read is incompatible under any ordinary reading, so implementers should follow the major-bump rule and treat Annex E's wording as an error to report.

Overlap and sunset

The documents give two different figures for how long an old major version stays supported beside a new one. API-INTERFACE §6 and Annex F say at least 90 days of overlap; Annex H says the prior major version is maintained in parallel for at least 180 days, with both marked Stable in the registry. This book does not treat either figure as settled. The safer plan is to honour the longer one, 180 days, until the working group publishes an erratum. After that window, a deprecated version enters a 12-month sunset during which the registry marks it Deprecated, with a migration note that points to the replacement requirement and explains why the change was made.

On the wire, deprecation is signalled with HTTP headers. PHASE-3 shows Deprecation: true together with a Sunset date and a Link to the replacement. The Sunset header is defined in RFC 8594. The Deprecation header was later standardised in RFC 9745, where its value is a structured date rather than true. A current implementation should send the RFC 9745 form, and clients should tolerate both.

HTTP/1.1 200 OK
Deprecation: @1767225600
Sunset: Thu, 31 Dec 2026 23:59:59 GMT
Link: </api/v2/monitoring/vegetation>; rel="successor-version"

Here @1767225600 is the Unix time for 1 January 2026, 00:00 UTC, used as an example deprecation date. The spec's own example writes the sunset day as "Wed", but 31 December 2026 is a Thursday. Since HTTP dates are parsed strictly by some clients, it is worth generating them rather than typing them.

Annex H also recommends that implementations publish a changelog mapping each PHASE version they support to the exact build, container digest or SDK version that satisfies it. For a monitoring platform with several deployments this is cheap and valuable: an auditor can match a report's generation date to the build that produced it and to the evidence package for that build.

Governance

Issues, errata and proposals go to the GitHub issue tracker of the WIA-Official organisation with the desertification-prevention label. The working group reviews open issues at the start of each minor release cycle and publishes a decision log with the release notes. The inconsistencies noted in this book — tier definitions referred to as "Annex A", a vectors directory that does not ship, 90 versus 180 days, TLS 1.2 versus 1.3, minor versus major for field removal — are exactly the kind of findings that belong there. Filing them is part of conformance culture: an implementer who works around a defect silently leaves the next one to rediscover it.

8.6 Related Certification Frameworks

WIA conformance sits among several established certification systems. It is important to know what each certifies, because the most common overstatement in this field is to borrow the authority of one for a claim that belongs to another.

Table 8-3. Frameworks near WIA-ENE-057 conformance and what each one covers
Framework	What it certifies or describes	Relation to WIA conformance
ISO/IEC 17065:2012	Requirements for bodies that certify products, processes and services	A model for how a Verified-tier auditor should operate (impartiality, documented scheme). WIA does not itself accredit auditors.
ISO/IEC 27001:2022	An organisation's information security management system	Covers the operator, not the API behaviour. Useful evidence for §7 security controls.
ISO/IEC 27018:2019	Protection of personal data by public-cloud processors	Relevant where field forms hold names of landholders or enumerators.
ISO 19115 (geographic metadata) and OGC WMS/WFS/WCS	Metadata model and web map/feature/coverage services; the OGC runs its own compliance testing programme	WIA text declares alignment. Claim OGC compliance only if the service has passed OGC's tests.
UNCCD national reporting (SDG 15.3.1 / LDN)	Country-level reporting on land cover, land productivity and soil organic carbon	WIA data can feed the national process; it never replaces the country's own submission.
Carbon-registry validation and verification (e.g. under ISO 14064-3, by bodies meeting ISO 14065)	Greenhouse-gas statements and project claims under a registry's methodology	WIA restoration records can serve as monitoring data; credits exist only after the registry's own process.

Several phrases in the specification should be restated carefully in any public claim. The compliance lists mark items such as ISO 19115, OGC services or HTTP/2 with check marks, but these are the authors' declarations of alignment, not certificates. Some of the RFCs cited for HTTP have been superseded: RFC 7230–7235 and RFC 7540 were replaced by RFC 9110–9113. The README describes RFC 9700 as "OAuth 2.1", which is not accurate; RFC 9700 is the OAuth 2.0 Security Best Current Practice, while OAuth 2.1 is still an Internet-Draft. A product description should say "aligned with the OAuth 2.0 Security BCP (RFC 9700)" rather than repeating the README's label.

The relation to LDN deserves one more sentence. LDN is assessed on three sub-indicators, with the rule that a significant decline in any one of them counts as degradation ("one out, all out"). WIA records can supply the evidence for that judgement at a site or project scale. Summary numbers such as a percentage of "LDN progress", which appear in some integration examples, are not UNCCD metrics and should not be presented as such.

Carbon claims need the same restraint. A restoration project that records biomass gains in restorationProject has monitoring data. It does not have carbon credits until a registry methodology has been applied, with its baseline, additionality test, leakage and buffer deductions, and until an accredited body has verified the result. A conformant WIA platform can make that verification easier by keeping every number traceable; it cannot shorten it.

8.7 The Road Ahead

More frequent and finer observation

Two technical shifts are already changing what an implementation of this standard can do. The first is harmonised optical data: combining Landsat and Sentinel-2 into consistent surface-reflectance series, as in NASA's Harmonized Landsat and Sentinel-2 (HLS) product, shortens the gap between clear views of the same field and narrows the pixel from the 250 m of MODIS vegetation indices to tens of metres. That brings individual plots and restoration parcels within reach of satellite monitoring. The second is radar. Synthetic aperture radar sees through cloud and is sensitive to surface moisture and structure, which makes it a candidate for field-scale soil-moisture estimates between the coarse passive microwave products such as SMAP. Both shifts raise the volume of data a platform stores and move effort from acquisition to quality control; the qualityMetrics and provenance fields of the PHASE-1 records become more important, not less.

Machine learning, with its uncertainty

Degradation detection is increasingly done with trained models: classifiers for land cover, change-detection models for gullies and bare patches, regressions for biomass. The standard already carries a confidence value beside trend statuses. The next step is to treat model uncertainty as data: record the model version, the training-data region and period, and a per-pixel or per-parcel uncertainty, and report degradation only where the signal exceeds it. A model trained on one landscape can be confidently wrong in another. Conformance vectors can help here too, as regression tests: a fixed set of reference tiles with known labels, re-run whenever the model changes.

Community monitoring

Field forms collected with ODK-style tools let herders, farmers and local technicians record survival counts, grazing pressure and erosion features that no satellite sees. The data model handles such records like any other, but their governance is different. The people who collect them should be able to see and correct what is stored about their land, and should share in the decisions that data supports. The CARE Principles for Indigenous Data Governance (collective benefit, authority to control, responsibility, ethics) are a useful reference when a deployment works with customary land.

Verifiable restoration outcomes

The simulator's fifth tab issues a restoration certificate with a QR code. The idea behind it is sound, even though the tab's "blockchain-backed" wording is illustrative: a restoration outcome — for example, "at site SAHEL-REGION-001, project REST-2025-SAHEL-001 recorded a given survival rate at a given date" — could be issued as a W3C Verifiable Credential, signed by the monitoring body and checkable offline by a donor or a community. Under this standard, the anchoring mechanism is Sigstore and Rekor, not a token on a public blockchain. Tree tokens and smart contracts appear in the integration text only as optional, illustrative designs. A credential is only as good as the evidence behind it, so it should reference the monitoring report and evidence package rather than restate a number without context.

Reporting cycles and targets

SDG target 15.3 aims at a land-degradation-neutral world by 2030, and countries that set voluntary LDN targets report on them through the UNCCD's periodic national reporting. As 2030 approaches, demand will grow for site-level evidence that can be aggregated upward without re-processing, which is precisely what consistent records and signed evidence provide. The UNCCD's good-practice guidance for indicator 15.3.1 and open tools such as Trends.Earth already define the national calculations; a WIA platform adds most value by making its data easy to feed into those methods, not by inventing its own national indicators.

Risks a standard cannot remove

Greenwashing. Signed, well-formatted data can make a weak claim look authoritative. A certificate for trees planted says nothing about trees surviving; an NDVI rise after a wet year says nothing about restoration. Honest reporting keeps the counterfactual and the time frame beside every claim.
Data colonialism. Monitoring systems are often built and hosted far from the land they describe. If the communities affected cannot access, correct or benefit from the data, the system reproduces the imbalance it claims to address. Data residency, local copies and open formats are engineering choices that shape this.
Sensor and model bias. Vegetation indices respond to soil brightness when cover is sparse, which is exactly the dryland case; rain gauges are few and unevenly placed; models inherit the geography of their training data. Conformance proves that a system follows the rules, not that its inputs are representative.

Chapter Summary

The three tiers grade the strength of evidence, not the quality of monitoring: Surface is self-attested, Verified adds an annual independent audit, Anchored adds a continuously refreshed, transparency-logged evidence package. Declare the tier with x-wia-conformance-tier.
Every requirement needs a positive and a negative vector. The official vector directory is not shipped, so implementers write their own, respecting the difference between reject and flag. Negative results are published and unjustified skips count as failures.
The evidence package bundles SBOM, OpenAPI, vector matrix and signed manifest, signed with Sigstore and recorded in Rekor, and is re-published at least quarterly to reveal drift.
The CLI prints templates and profiles, but validate checks only standardSlug. Profile manifests state per-requirement status so that partial conformance is never presented as full.
Versioning follows SemVer 2.0.0 with a 12-month sunset; the overlap window is stated as both 90 and 180 days, so plan for 180. Report inconsistencies through the issue tracker.
WIA conformance complements, and never replaces, ISO/IEC certifications, OGC compliance, UNCCD national reporting and carbon-registry verification. The road ahead brings finer data, machine learning with explicit uncertainty, community monitoring and verifiable credentials, together with risks that only careful claims can contain. In the spirit of 弘益人間, the aim is monitoring that benefits the people who live on the land.