Skip to main content
Jira progress: loading…

GEOX

Geospatial Engines

1. Identity​

AttributeValue
Type codeGEOX
Canonical nameGeospatial Engines
Parent typeRSLU
Type statusreview
Tier scopetier-2, tier-3
Invocationchained
Payload effectannotate
Lineage rolestamps-cmi

GEOX is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: GEOX. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary​

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?”

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.

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.

3. Membership criteria​

3.1 Inclusion tests​

A micro engine is a member of GEOX when its specification satisfies the following:

  • 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

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.

3.2 Exclusions​

A micro engine is not a member of GEOX when any of the following is its responsibility; each belongs to the type named:

  • ❌ 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.

3.3 Boundary cases​

  • GEOX versus RMAP: resolving a facility to a flood zone is GEOX; deciding that the facility therefore carries high physical risk is RMAP.
  • GEOX versus META: an attribute derived from geometry (containment, overlay, proximity) is GEOX; a location label copied from metadata is META.

4. Design rules​

RULE-GEOX-001 — Spatial Accuracy

All geographic operations SHALL respect declared coordinate reference systems (CRS) and projections.

RULE-GEOX-002 — Explicit Geometry

Spatial logic always references explicit geometries or spatial layers.

RULE-GEOX-003 — Deterministic Resolution

Given identical inputs and spatial layers, results SHALL be reproducible.

RULE-GEOX-004 — Composable Geography

Outputs SHALL remain usable by downstream engines (AGGR, RMAP, SCORE).

RULE-GEOX-005 — Auditability

All spatial decisions SHALL be traceable to source geometries and engine versions.

5. Contract​

5.1 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 SHALL be:

  • explicit,
  • versioned,
  • referenceable.

5.2 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.

6. Position in the computation chain​

6.1 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.

7. Identity rules for members​

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

  • mice.category SHALL be GEOX.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of RESOLVE, CLASSIFY.
  • The DOMAIN segment SHALL be any registered MEID domain.
  • Typical FUNCTION segments: RESOLVER, CLASSIFIER.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: tier-2, tier-3; invocation: chained; payload effect: annotate.

10. Members​

Loading micro engines…
  • RSLU — Resolution Engines
  • EXTR — Extraction Engines
  • VALI — Validator Engines
  • META — Metadata Enrichment Engines
  • AGGR — Aggregation Engines
  • RMAP — Risk Mapping Engines
  • SCORE — Scoring Engines
  • CALC — Calculation Engines


GitHub RepoRequest for Change (RFC)
Last updated on by ZAYAZ