GEOX
Geospatial Engines
1. Overview
Geospatial Engines (GEOX) are a capability class of Micro Engines (MICE) responsible for processing, resolving, and enriching signals that contain spatial or geographic attributes.
GEOX engines:
- operate on coordinates, geometries, and spatial references,
- apply deterministic spatial logic (e.g. overlays, containment, proximity),
- enrich signals with location-derived meaning without altering underlying values.
GEOX engines answer: “Where does this signal apply?”
GEOX is a type, not an identity.
Concrete engines are identified by MEID, versioned via ZAR, and leave CMI lineage stamps at runtime.
2. Position in the MICE Model
Capability, not identity
A Geospatial Engine:
- does not define which engine runs (MEID does),
- does not define version or deployment (ZAR does),
- does define the kind of spatial operation being performed.
Multiple MEIDs may implement GEOX capabilities across:
- different spatial datasets,
- different resolutions or projections,
- different regulatory or analytical contexts.
Typical placement
| Dimension | Value |
|---|---|
| Capability type | GEOX |
| Common tiers | Tier-2, Tier-3 |
| Typical classification | Contract-Engine |
| Versioning | ZAR (CMI-level) |
| Lineage impact | Appends GEOX CMI stamp to USO |
3. Design Principles
-
Spatial Accuracy
All geographic operations must respect declared coordinate reference systems (CRS) and projections. -
Explicit Geometry
Spatial logic always references explicit geometries or spatial layers. -
Deterministic Resolution
Given identical inputs and spatial layers, results must be reproducible. -
Composable Geography
Outputs must remain usable by downstream engines (AGGR, RMAP, SCORE). -
Auditability
All spatial decisions must be traceable to source geometries and engine versions.
4. Scope of Responsibility
What GEOX engines do
- Resolve coordinates to regions or administrative units
- Perform spatial containment or intersection checks
- Apply spatial overlays (e.g. flood zones, biodiversity areas)
- Assign location-derived attributes or classifications
Typical examples:
- mapping assets to countries, regions, or river basins,
- assigning facilities to climate hazard zones,
- linking emissions sources to jurisdictional boundaries,
- resolving supply-chain nodes to biodiversity hotspots.
5. What GEOX Engines Do Not Do
GEOX engines are intentionally narrow.
They do not:
- ❌ compute ESG metrics (CALC)
- ❌ aggregate entities or hierarchies (AGGR)
- ❌ infer risk or impact levels (RMAP)
- ❌ estimate missing spatial data (SEM)
- ❌ enforce policy or governance decisions (ZSSR / assurance)
GEOX engines locate and resolve —
they do not judge or decide.
6. Inputs
Typical GEOX inputs include:
- geo-tagged signals (lat/long, polygons, references),
- spatial layers or datasets (boundaries, hazard maps),
- declared CRS and projection metadata,
- optional resolution or precision parameters.
All spatial inputs must be:
- explicit,
- versioned,
- referenceable.
7. Outputs
GEOX engines emit:
- spatially resolved attributes (region codes, zone IDs),
- derived geographic metadata,
- provenance references to spatial layers and rules.
Outputs are commonly consumed by:
- AGGR engines (geo-based roll-ups),
- RMAP engines (risk interpretation),
- SCORE engines (location-weighted scoring),
- reporting and disclosure pipelines.
8. Interaction with ZSSR
ZSSR does not route to “GEOX” generically.
Instead, it:
- selects specific MEIDs implementing spatial resolution logic,
- binds them to approved spatial datasets,
- enforces jurisdictional or policy constraints.
Tags such as geox, spatial, or domain tags may be used as:
- pre-filters or
- fallback selectors
…but explicit routing rules always take precedence.
9. Example Geospatial Engines
10. Summary
Geospatial Engines:
- resolve where signals apply,
- provide deterministic, auditable spatial logic,
- enable location-aware aggregation, risk mapping, and scoring,
- remain strictly separate from interpretation and governance.
They are the spatial grounding layer of the ZAYAZ platform.
Stable