GeoAI Strategy Alignment
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
Bottom-up, case-driven
Capabilities are built from a real case a hub already has, not from a generic capability roadmap handed down centrally.
Replication & transferability
A model or workflow built for one region is designed, from the start, to be recalibrated for another — not rebuilt.
Open & FAIR science
Findable, accessible, interoperable, reusable — data and models publish through Source Cooperative and open standards, not siloed stores.
Human-centered design
Practitioners shape the tool's workflow; the model serves a decision a person already needs to make.
Ethical & responsible AI
Groundedness gates, receipts, and regional-sensitivity review are load-bearing, not optional add-ons late in the build.
Institutional capacity
A hub that adopts a capability also gains the ability to maintain and extend it — capacity transfer is a deliverable, not a side effect.
Six strategic pillars
| Pillar | What it commits the plan to |
|---|---|
| Bottom-up, domain-grounded development | Each platform section below (§04–06) starts from the hub's own case, per Principle 01. |
| Transferability & shared tech ecosystem | One shared capability layer (§07) rather than three independently-built stacks. |
| Operational integration | Capabilities ship as MCP-wrapped services reachable through the gateway (§02), not as standalone notebooks. |
| Open science | Source Cooperative as the storage/publication layer; STAC/OGC/CF conventions as the interoperability layer. |
| Human capital | The tiered capacity-building model below is a build deliverable alongside the software. |
| Infrastructure & compute sustainability | Hybrid SOCRATES + commercial-cloud compute, with data kept near the compute that uses it. |
Shared technology stack
| Layer | Components |
|---|---|
| Foundation models | Prithvi · DOFA · TerraMind · CROMA · OlmoEarth · Satlas · Tessera · Clay · AlphaEarth |
| Tooling | TorchGeo · TerraTorch · Raster Vision · eo-learn · PANGAEA |
| Compute | Hybrid: SIG's own SOCRATES cluster plus a commercial "core-3" (AWS / Google Cloud / Azure), chosen per-workload so data stays near the compute that processes it. |
| Storage & publication | Source Cooperative, org instance source.coop/737847 — the open-FAIR-science commitment made concrete. |
Governance mechanisms carried into every agent
Post-processing style agent
A dedicated agent trained on regional style guides reviews outputs for culturally and politically sensitive framing before anything publishes — same family of gate as SERVIR-AI/global-platform's groundedness check.
Permission-level sandboxing
Knowledge-management agents run inside sandboxes scoped to a permission level, so a capability's blast radius is bounded by what its caller is actually allowed to see or change.
Federated model stewardship
Distributed, hub-level model stewardship — rather than one central authority holding every model — is the named mitigation against over-centralization risk.
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.
| Tier | Capability transferred |
|---|---|
| Practitioner | Uses a deployed capability to answer a real operational question — runs the tool, reads the output, knows its limits. |
| Engineer | Recalibrates and extends a capability for a new region or dataset — the transferability principle made operational. |
| Research lead | Trains the next practitioner and engineer cohort — train-the-trainer, so capacity compounds rather than resets with each program cycle. |