Platform Ecosystem
Engineering Plan

This plan turns the Master Architecture (v1.7) and SIG-NAL's GeoAI Strategy into a single build order: one shared data-and-capability layer, one gateway, and three platform domains that pull from it rather than duplicate it. Global Risk, Food Security, and NRM are scoping and funding lenses, not three codebases — every capability below is built once, wrapped once, and registered once, regardless of which platform's budget paid for it.

The shared system, top to bottom

Two internal documents independently describe the same mechanism — the SERVIR Global Platform Technical Integration Guide and SIG-NAL's GeoAI Strategy — which means GeoAI capabilities don't need their own integration architecture. A model, an alert feed, and a classifier all become available the same way.

The wrap-once pattern

Gateway components

What already exists at the consolidation point

github.com/SERVIR-AI/global-platform is not a scaffold — it's a live, actively-developed MCP server (LangGraph + FastMCP, 183 commits, 3 contributors, EPL-2.0) already answering natural-language disaster-risk questions for Southeast Asia across flood, flash flood, drought, fire, landslide, cyclone, storm, tsunami, and earthquake, and already pulling in Food Security data (GEOGLAM, ENSO/IOD). It mints every answer as a replayable, litestream-backed receipt, gated by a groundedness check before publishing — real precedent for the human-approval checkpoint this whole gateway needs, not a pattern to invent from scratch.

What it does not have yet: the gateway itself (identity/policy/routing/audit) or Agent2Agent federation — one LangGraph pipeline inside one FastAPI service, not a hub for every platform's agents. Positioning: this plan's gateway wraps and federates what's already running there, rather than competing with it.

Migrating the scattered state into SERVIR-AI

David named the org's actual GitHub footprint directly: github.com/SERVIR-AI is confirmed as “the master one that everything will end up in and where people are building things” (Decision #14). Four hub-level orgs hold the current, more scattered build activity — that inventory is now complete and carried in full below — 259 public repositories, each with a triage call (Decision #14's residual, closed). The count moved from 230 to 231 on 9 September 2026 when Platform-Inventory itself was made public, taking SERVIR-AI from one repo to two — caught by the automated sweep, which is the intended behaviour — and to 259 on 16 September 2026 when github.com/geoglows was inventoried for the first time. GEOGloWS is named as the riverine-flood forecasting backbone throughout this plan; its 28 repositories had never been read, and until geoglows was added to scripts/sweep.py the authoritative record disagreed with the plan by exactly that many. The authoritative count is data/servir-repos.json in that repo, refreshed weekly; the figure quoted in this prose is a reading, not the record, and will drift between sweeps.

Vendor-agnostic by design (Decision #10)

MCP and Agent2Agent are open protocols, not one vendor's product. Every domain agent built under this plan must stay callable by whichever LLM backend a given hub or partner actually has access to — Claude, GPT-class models, Gemini, or an open-weight model run on SIG's own SOCRATES cluster. Google.org's funding of AgriNexus does not imply a Google-only model stack; this is settled policy, confirmed, not an assumption to revisit per platform.

What is being built right now in SERVIR-AI

Three repositories in the consolidation org are where the current build is actually being organised. They are named here by David; two are private and could not be read from outside, so this plan records what they are for and flags what it needs.

global-platform, in detail — the reference implementation

This is not a scaffold. It is an active build with tests, checked-in end-to-end example payloads, a Dockerfile and GCP deploy config, and near-daily commits. Read closely, it already implements four of the six seams §04 specifies — which makes it the thing to extend rather than the thing to compete with.

The GitHub migration inventory

Decision #14 confirmed github.com/SERVIR-AI as the consolidation target and left the migration mapping as its residual — the first engineering task in the roadmap. That inventory is below: every public repository across the seven organizations, with a triage call on each. It was compiled from the public GitHub organization listings on 2 September 2026; the REST API is unavailable from this environment, so the listings are the source, and private repositories do not appear.

github.com/SERVIR-AI — 1 repos

The confirmed consolidation target (Decision #14). One repo today — and it is the only repo of all 259 with an MCP endpoint.

1 wrap as mcp

github.com/SERVIR — 132 repos

The general / legacy org and by far the largest. Fifteen years of service code, six repos already archived upstream, and the great majority dormant.

19 wrap as mcp · 10 migrate · 35 review · 7 capacity material · 61 archive

github.com/Servir-Mekong — 44 repos

The deepest hydrology and land-cover bench in the ecosystem. hydra-floods and rlcms are the two assets the platform plan leans on hardest.

8 wrap as mcp · 2 migrate · 7 review · 1 capacity material · 26 archive

github.com/SERVIR-Amazonia — 38 repos

Newest activity of any hub org. Also carries an obvious consolidation target: fourteen Tethys/GEOGloWS repos are roughly three codebases forked once per country.

4 wrap as mcp · 22 review · 11 capacity material · 1 archive

github.com/SERVIRSEA — 7 repos

Small and modern — includes two foundation-model experiments (Claynge on Clay, cashew on a CNN) that are directly relevant to the GeoAI stack in §03.

5 wrap as mcp · 2 review

github.com/pyregence — 8 repos

Partner-tool org, named by David (Decision #16). Actively developed in Clojure through September 2026 — the wildfire capability in §04 is real, current software.

4 wrap as mcp · 3 migrate · 1 archive

github.com/geoglows — 28 repos

Partner-tool org. GEOGloWS is named as the riverine-flood forecasting backbone throughout this plan — §04's flood row, §05's irrigation-water-availability signal, §07's shared streamflow row, and the Malawi and IDEAM use cases — but its code had never been inventoried, so the plan was depending on software it had not read. It is the most actively developed org in this register: eleven repos pushed in the last month, against roughly six across the two largest hub orgs all year. Licensing is permissive throughout, verified by cloning: geoglows is on PyPI and conda-forge at 2.2.0 (BSD-3-Clause-Clear), geoglows-rest-api is MIT and already a running Flask service, river-route is BSD and on PyPI. That lowers the technical barrier to wrapping — it does not define the institutional relationship. GEOGloWS is a partner with its own governance (confirmed by David, 14 September 2026), and §04's flood row stays Partner. What the inventory changes is that the partnership turns out to be better provisioned than the label implied: integration here is an agreement to reach, not a capability to build.

12 wrap as mcp · 3 migrate · 9 review · 3 capacity material · 1 archive

Every engineering decision in §04–08 traces back to one of six design principles and six strategic pillars set out in SIG-NAL's cross-platform GeoAI Strategy. They're restated here as the checklist each platform section is built against, not as background reading.

Six design principles

Six strategic pillars

Shared technology stack

Governance mechanisms carried into every agent

Tiered capacity-building model

Human capital is built as a ladder, not a single training event, and each tier trains the next — a hub that only ever receives training never becomes able to sustain the capability once outside support ends.

RiskMap. Twelve perils under one MVP scope (Decision #1, resolved), each of which has to be answered on three different clocks: what is happening now, what the annualized baseline risk is, and how that baseline shifts under climate change. The matrix below is the build list — thirty-six cells, each one an element that has to exist, be wrapped, and interoperate with the other thirty-five.

Fig. 2 — The build matrix

Fig. 3 — How the thirty-six elements interact

The companion exposure layer

The matrix above answers what hazard, on what clock. It deliberately does not carry exposure, because exposure is not a per-peril question — the same population grid, the same protected-area layer and the same building footprints are joined against all twelve perils on all three clocks. Building it once, as a service rather than a per-peril lookup, is what keeps thirty-six cells from becoming thirty-six data pipelines.

Build detail — the six seams that make the elements interoperate

Thirty-six hazard cells, three exposure stacks and five agents only add up to a platform if they meet at defined seams. These six are the whole of the interoperability story; everything else is a peril specialist's business.

Interoperability standards

Already built, not to be re-built

Plus ClimateSERV (precipitation, active since 2015 — SERVIR/ClimateSERV2, updated June 2026), and a deep bench of hazard code in the hub orgs: flood_mapping_intercomparison, fierpy, RHEAS, lhasa, mrc_ffgs, hiwat_model_viewer — inventoried repo by repo in §02.

Where to partner, what to build

Domain agents

Use cases from the SERVIR archive

These are documented services with a named institution and a named decision — the demand evidence this platform is being built against. They are also the acceptance tests: if the matrix above is built correctly, every one of these becomes a query the orchestrator can answer rather than a bespoke tool someone has to maintain.

Four further Global Risk services are documented as tools without a named downstream government user on their public pages, and are carried here as capability evidence rather than demand evidence: HYDRAFloods (Lower Mekong flood mapping), LHASA-Mekong (landslide situational awareness), Mekong X-Ray (multidimensional flood vulnerability) and West Africa Flash Flood Vulnerability Mapping (ICRISAT-led consortium).

GeoAI AgriNexus (Google.org-funded). Climate-driver-led, not commodity-led — but the build list is commodity-shaped, because what has to be constructed is a crop-type layer, a yield method and a calendar per commodity. Same three-clock structure as Global Risk: what the crop is doing now, what this season will produce, and how the calendar itself moves under climate change. Currently maize-centric; EUDR compliance is confirmed scope (Decision #3, resolved).

Fig. 4 — The build matrix

Fig. 5 — How the elements interact

The backbone and exposure layers

Field boundaries are the spatial backbone. Every other layer in this platform is a value attached to a field polygon, not a standalone map — which means the field-boundary layer's quality caps everything built on top of it. Each layer also carries a maturity flag through to the API and UI (detection vs. estimation vs. proxy) rather than presenting uniform confidence.

Build detail — the six seams

Already built

Where to partner, what to build

Domain agents

Use cases from the SERVIR archive

Twenty-three hub-submitted cases already sit behind this platform's PDD. The twelve below are the ones documented publicly with a named institution and a named decision — the strongest evidence that the matrix above is aimed at real demand.

Five further Food Security services describe a user class rather than a named ministry and are carried as capability evidence: the Regional Drought Monitoring and Outlook System (South Asia), National Agricultural Drought Watch (Nepal), Rangelands Decision Support Tool (Zambia operational, Kenya in development), Farm Action Toolkit (Bhutan) and Southeast Asia Drought Watch.

Land Cover and Environmental Monitoring (LCEM). Five PDD components — Land Cover & Change, Carbon Estimation, Ecosystem Intelligence, NbS Monitoring, Decision Support — which resolve, in build terms, into twelve monitoring themes on the same three-clock structure: a change alert now, an annual accounting number, and a scenario projection. South Asia is the starting hub. Firm guardrail throughout: the platform provides underlying MRV data — it does not issue, register or guarantee carbon credits.

Fig. 6 — The build matrix

Fig. 7 — How the elements interact

The rights and accounting layers

Global Risk asks who is exposed; NRM asks a harder question — whose land is this, who is allowed to change it, and what was the change worth. Those are the companion layers, and two of them are the weakest data in the whole ecosystem.

Build detail — the six seams

Already built

Where to partner, what to build

Domain agents

Use cases from the SERVIR archive

This is the best-documented of the three platforms in the public archive — seventeen of nineteen recovered cases name a specific institution, and an unusually high share of those are ministry-level. That matters for the matrix above: these are not pilots looking for a user.

Seven further NRM services are documented and carried here in brief: Charcoal Production Site Monitoring (Ghana — A Rocha, Solidaridad), Land-cover mapping for GHG inventories (RCMRD, nine countries), REDD+ forest monitoring capacity (Kenya, Uganda, Zambia — mapping cycle shortened from six years to about one), TerraOnTrack (CPI-Acre, Imaflora, SIG — community territorial threat detection), Ecosystem services at the forest-agricultural interface (Imaflora, Brazil/Peru), MOCAF forest-road monitoring (ACCA, ABSAT) and iSWIM inland water quality (RCMRD).

Global Risk, Food Security, and NRM are three organizational and funding domains — three PDDs, three sponsor relationships, three sets of named hubs — sitting on top of what should be one shared system: one data layer, one capability layer, one set of MCP-wrapped tools. “Global Risk Platform” describes who scoped and funded a capability, not a separate system a user has to go find it in.

Five sharing points, built once

Every future build decision defaults to “build this once, in the shared system, tagged with which domain scoped it” — not “build this for platform X, then figure out sharing later.”

Common audience model

The Global Risk PDD's five user groups are adopted as the confirmed, shared audience model for all three platforms, rather than each platform inventing its own list:

Hub footprint — a real mismatch, flagged not hidden

Resolved (Decision #11): the Service Inventory's CATIE-led "Central America" hub and the PDDs' "Mesoamerica" hub are the same hub under two names — treat "Central America" as informal shorthand going forward.

22 tracked decisions as of Master Architecture v1.7. All 14 original items have a direction; 8 more surfaced when the three standalone platform documents were folded in. 18 of 22 still have real, unstarted next actions — none of the 8 newest have an owner yet.

Decisions 1–14 — the September 1–2 resolution round

Decisions 15–22 — surfaced by the v1.7 document consolidation

Four-phase roadmap

Per the GeoAI Strategy document — carried here in full rather than referenced, since it's the sequencing this entire engineering plan builds toward.

Every service this ecosystem has completed, started or retired — 123 across the six hubs, each with the user institution named where a source names one, and each with a status. This is the asset base the three build matrices sit on: the "already built, do not rebuild" cells in §04–06 are drawn from here, and so is the demand evidence. Compiled 3 September 2026 from each hub's own catalogue, cross-checked against the SERVIR Global App Center.

Reactivation candidates

Every service the crawl found retired or dormant, with what restarting it would actually involve. These belong in the build conversation alongside new construction — in several cases they are the cheapest route to a matrix cell currently marked as a gap.

The six hubs and who runs them

A seventh hub — the original SERVIR Mesoamerica, launched in Panama in 2005 — closed in 2011. The 2019 Central America hub is a separate re-establishment, not a continuation, so Decision #11's "Central America = Mesoamerica" equivalence holds for the current hub only.

Status across the whole portfolio

Hindu Kush Himalaya — ICIMOD, Kathmandu · 42 services

The largest catalogue of any hub. Its site carries wind-down language from a January 2025 phase boundary; the hub is open and operating. The status column below reflects what each page says, which is a statement about the documentation rather than the software.

7 operational · 16 active · 1 in development · 2 no longer active · 16 status unclear  ·  20 of 42 name a user institution

Southeast Asia — ADPC, Bangkok · 18 services

Renamed from SERVIR Mekong in 2023. Nine of sixteen tools are still named or scoped to the Lower Mekong specifically.

5 operational · 10 active · 1 in development · 1 dormant · 1 no longer active  ·  10 of 18 name a user institution

West Africa — ICRISAT-led consortium · 12 services

Consortium: AFRIGIST, AGRHYMET, AIMS, CERSGIS, CSE, ISESTEL, Columbia CIESIN/IRI, University of Florida. Phase 2 runs 2022–2027.

1 operational · 3 active · 5 in development · 3 status unclear  ·  9 of 12 name a user institution

Eastern & Southern Africa — RCMRD, Nairobi · 23 services

The thinnest hub web presence of the six: eight confirmed dead links and eight RCMRD subdomains unreachable. Several rows below are evidenced through NASA, Climatelinks or Agrilinks rather than the hub's own pages.

4 operational · 10 active · 2 in development · 1 no longer active · 6 status unclear  ·  20 of 23 name a user institution

Tropical South America — Alliance of Bioversity International and CIAT, Cali · 22 services

Renamed from SERVIR Amazonia in 2025. Spatial Informatics Group (SIG) appears as a build partner on six of these services.

6 operational · 8 active · 2 in development · 1 no longer active · 5 status unclear  ·  21 of 22 name a user institution

Central America — CATIE, Costa Rica · 6 services

Established 2019. Evidence is genuinely thin: no service catalogue, no per-tool detail pages, and SERVIR's own Service Tracker does not offer Central America as a filterable region. Four items in evidence, two of them training rather than tools.

1 operational · 3 active · 2 in development  ·  6 of 6 name a user institution

What this inventory changes in the plan

SERVIR is one programme inside a much larger NASA applied-science estate, and most of that estate is open, free and already operational. This section inventories what the other programmes provide that these three platforms would otherwise build — data products, analysis platforms, foundation models, training curricula and funding mechanisms — and maps each to the matrix cell or platform layer it serves. The recurring finding: several cells currently marked "new build" in §04–06 have a NASA asset sitting behind them that nobody has claimed.

Global Risk — what NASA already runs

Food Security and NRM — what NASA already runs

Shared infrastructure — what not to build

The §07 argument is that these are three domains over one shared system. This is the same argument one level down: several layers of that shared system already exist inside NASA, open-licensed and redeployable.

What this changes in the matrices

Terminology tie-breakers and the source record — kept together so a reader checking a fact knows exactly where it came from.

Consistency ledger — the tie-breaker for conflicting terms

Source documents

Internal (SERVIR shared Drive): Global Risk PDD (v0.1); Food Security PDD Template, Starting Use Case, and Use Case Worksheet; Land Cover and Environmental Monitoring PDD (v0.1) and Prototype doc; SERVIR Global Platform Technical Integration Guide; SIG-NAL's SERVIR GeoAI Strategy (2026–2030); SERVIR Service Inventory, Jan 2026 (85+ services) and its linked GitHub-repo manifest.

Code repository: github.com/SERVIR-AI/global-platform — investigated directly (cloned, read source).

GitHub organizations (named by David, all now inventoried in §02 — 259 public repos across seven orgs, 16 September 2026): github.com/SERVIR-AI (confirmed consolidation target), github.com/SERVIR-Amazonia, github.com/Servir-Mekong, github.com/SERVIRSEA, github.com/SERVIR. Forest Data Partnership (reviewed 10 September 2026, §05 F7): wri.org · fao.org · github.com/google/forest-data-partnership (MIT, trained models) · github.com/forestdatapartnership (6 repos incl. Whisp, MIT) · Earth Engine catalogue projects/forestdatapartnership/assets.

Partner-tool orgs: github.com/pyregence (Pyregence/Pyrecast and pyretechnics, wildfire behaviour — Decision #16, reviewed 4 September 2026), github.com/OurPlanscape (Planscape — wildfire-resilience treatment planning, CC0, built by SIG for the US Forest Service; planscape.org; reviewed 10 September 2026, §06 N7 and Decision #23) and github.com/geoglows (GEOGloWS River Forecast System — riverine-flood forecasting backbone for §04, §05 and §07; 28 repos, BSD/MIT, pygeoglows on PyPI; inventoried 16 September 2026, §02. Permissive licensing lowers the barrier to wrapping but does not make this a migration target — §04’s flood row stays Partner).

Hub service catalogues (crawled 3 September 2026, §09): servir.icimod.org · servir.adpc.net/tools · servir.icrisat.org · rcmrd.org and servirglobal.net/Regions/ESAfrica · servir.alliancebioversityciat.org · servir.catie.ac.cr · appcenter.servirglobal.net (n=1–82). 123 services across six hubs.

Open-source landscape research: OpenQuake, CLIMADA/climada_petals, IBF-system, TorchGeo, TerraTorch, PANGAEA-bench, Whisp, DSSAT, PCSE/WOFOST, AquaCrop-OS, Sen4CAP, OpenET, earthrise-media/mining-detector, MegaDetector, SMART, GBIF, Microsoft Planetary Computer biodiversity layers.

Companion published documents: Open-Source Gap-Fill Atlas · Decisions Log Action Plan (owners/target dates for the original nine residuals — not yet updated for the 13 additional residuals surfaced since).

Source of record for every claim in this plan: SERVIR Platform Ecosystem — Master Architecture, v1.7, and GeoAI Strategy Across the Three SERVIR Platforms. Where this plan condenses a table or note for length, the master document carries the full version.