TGISDetailed concept
How the compound system works. What each role does, how they cooperate, what the system commits to.
The concept page describes TGIS as a compound AI system built around seven cooperating roles. This page opens each role up: what the orchestrator actually does when a question arrives, how the three domain experts reach heterogeneous sources, how the fusion and reconciliation experts compose their outputs, how the presenter assembles the answer, and what external surfaces the system talks to. Everything here is downstream of what the concept page establishes; nothing on this page overrides it.
The compound system at a glance
Fig 1. TGIS in context. An orchestrator triggers domain experts (structured, geospatial, unstructured), a fusion expert that combines aligned evidence, and a reconciliation expert that surfaces disagreement where sources conflict. The system queries sources and remote compute, then returns an answer as text, tables, maps, figures, and a reconciliation log.
Three of the seven roles belong to the user surface: the orchestrator receives the question, the presenter composes the answer, and between them sits the reasoning that ties one to the other. Three are the domain experts that reach outside the system: structured-data, geospatial, and unstructured-knowledge. Two are composition experts (fusion and reconciliation) that prepare expert outputs into a single coherent answer. The rest of this page walks each in turn: orchestrator first, then the common machinery experts share when they reach external sources, then the three domain experts, then fusion and reconciliation, then the presenter, and finally what starts concrete.
The orchestrator: picking a workflow and running it
The orchestrator is the component the user talks to. It receives a question in natural language and runs a workflow to produce an answer: a sequence of expert calls, pre-checks, compute steps, and composition operations. Workflows are the unit of work the orchestrator operates on, and they come from two places.
Prepared workflows. TGIS carries a library of workflows for recognised question shapes. Direct retrieval (one expert, one source). Multi-source fusion without reconciliation (several experts, then fusion). Multi-source fusion with reconciliation (several experts, fusion, then reconciliation). Ecosystem-prechecked outcomes retrieval (pre-checks, then retrieval, then reconciliation). Prescriptive-outcomes with modelling (retrieval, then remote compute, then synthesis). Each prepared workflow is a sequence of building blocks: no transport specifics in the workflow itself, only in the inputs the orchestrator binds to it. The orchestrator picks the matching shape when an incoming question fits the pattern. These are the workflows the orchestrator is instructed to follow.
Dynamically composed workflows. For questions that don't match a prepared pattern, the orchestrator composes a workflow from the building blocks (retrieval from one or more experts, ecosystem pre-checks, remote compute, fusion, reconciliation, RAG). The shape is decided at runtime from the question.
Which mode applies depends on the reasoning maturity available to the orchestrator: a well-covered question pattern uses its prepared workflow; an unfamiliar one uses dynamic composition. Over time, dynamically composed workflows that work well become prepared workflows in the library. The orchestrator carries the reasoning trace regardless of mode.
A worked example follows, showing one prepared workflow running end to end in response to a single cross-source question. It is one shape of workflow among many.
User: "Which transport corridors in Sub-Saharan Africa are most
vulnerable to climate disruption relative to their trade importance?"
Orchestrator reasoning:
Pass 1 (Discovery): Check registry → need OPSIS (infrastructure +
climate risk), PortWatch (trade/port data),
World Bank (trade indicators)
Pass 2 (Reference): Resolve "Sub-Saharan Africa" → list of countries
+ bounding box
Pass 3 (Parallel queries, dispatched to experts):
- Geospatial expert (OPSIS): Get major corridors in SSA bbox with
climate risk scores
- Geospatial expert (PortWatch): Get trade volumes for SSA ports
- Structured expert (World Bank): Get trade-to-GDP ratios for SSA
countries
Pass 4 (Fusion): Fusion expert joins corridor risk data with
trade importance via shared country codes and
spatial references
Pass 5 (Reconciliation): Reconciliation expert checks for conflicting
trade figures between sources (here, none
beyond tolerance)
Pass 6 (Synthesis): Rank corridors by vulnerability × trade impact,
return top 10 with narrative explanation
Pass 7 (Optional presentation): Presenter generates a map showing the
top corridors colour-coded by combined
risk-trade score
The orchestrator handles the passes. Decomposing the work into experts rather than running it in the orchestrator is what gives TGIS its compound-system properties: the orchestrator's context stays small (it sees its own reasoning and summarised expert outputs, not every raw response), experts run in parallel when their work is independent, a failure in one expert is isolated from the others, and each expert develops specialised skills for its surface without competing with the others for shared attention. Three reasoning principles run through every orchestrator run regardless of workflow: provenance-by-default (every number in every answer is attributable to the source that produced it), surface-both (when the reconciliation expert detects material disagreement, both values are shown), and trace-as-output (the reasoning trace itself is part of what the system returns, not hidden machinery).
How experts reach external surfaces
All five experts reach out beyond the system to do their work. The three domain experts (structured-data, geospatial, unstructured-knowledge) reach out to data sources: statistical APIs, geospatial services, document stores. The two composition experts (fusion, reconciliation) also reach out to data sources when they need to look up reference data. And any of the five, domain or composition, can reach out to remote compute runtimes when an operation is too heavy to sit in the expert's own reasoning context: a structured-data expert running a cross-country statistical model, a geospatial expert running a zonal aggregation over billions of features, an unstructured-knowledge expert running batch embedding over a fresh corpus, a fusion expert running a large spatial join.
The umbrella term for everything an expert can reach out to (a data source or a compute runtime) is an external surface. The machinery for reaching any external surface is the same across all five experts. This section describes that shared machinery. The domain experts themselves follow in the next section, and fusion and reconciliation come later in the page.
What a connector is
Every external surface presents some kind of machine-readable interface: a REST API, an SDMX endpoint, a Zarr store in object storage, an HTML archive, a folder of PDFs, a compute runtime. An expert needs three capabilities from that surface: it has to discover that the surface exists and is relevant to the question at hand, comprehend it well enough to call it correctly (what the fields mean, what parameters are valid, what a response looks like), and call it to retrieve the evidence or trigger the computation.
The layer that delivers those three capabilities to the expert is what this page calls a connector. The term is narrower than the generic "API connector" a developer might think of: a connector in this sense is agent-facing: it isn't just a callable interface, it is discoverability + comprehension + call, packaged together, designed to be reached by an LLM-powered expert rather than a human developer. All five experts reach external surfaces through this same kind of connector. Two things vary from one connector to another: what the surface on the other side is, and how the connector is packaged. The next three subsections take these in order: what every connector provides regardless of form, how a connector is packaged (as a skill, as an MCP server, or both), and how much the connector itself has to do to bridge the gap to the surface.
What a connector provides
Discovery, comprehension, and call travel together in every connector. They are not separate infrastructures: they are three things the connector has to carry before an expert can act. This subsection describes each capability abstractly; the following subsection shows the two forms a connector can take to deliver them.
Discovery depends on a registry the expert can consult before making any query. Think of it as the table of contents an expert reads before deciding which chapters to open: what datasets exist, what topics and geographies they cover, what questions each one can answer, how fresh the data is, what format and access method it uses, which other datasets it can be combined with. The registry can take many shapes. One illustrative example, for OPSIS:
- id: opsis-global-infrastructure
name: "OPSIS Global Infrastructure Resilience"
provider: "University of Oxford"
description: "Global road, rail, air, and maritime infrastructure networks
with climate risk exposure analysis"
capabilities:
- "Infrastructure network topology for any country"
- "Climate hazard exposure for transport corridors"
- "Multi-modal connectivity analysis"
geographic_coverage: "Global"
transport_modes: ["road", "rail", "air", "maritime"]
data_types: ["geospatial", "network", "risk-indicators"]
update_frequency: "Quarterly"
access_method: "rest_api"
api_base: "https://global.infrastructureresilience.org/api/v1"
combinable_with:
- id: portwatch
relationship: "Port disruptions can be overlaid on OPSIS maritime
network nodes"
- id: world-bank-indicators
relationship: "Country-level transport indicators can contextualise
infrastructure data"
license: "ODbL + CC-BY-4.0"
The expert needs to know what exists and whether it's relevant before calling anything. Analogues exist in neighbouring fields: STAC for earth observation, CKAN for open data portals, tool manifests for AI agents: but nothing equivalent covers global transport data in an agent-friendly form today. The concrete form the registry takes can vary; what matters is the role.
Comprehension is a different kind of knowledge. Discovery answers "is this source relevant to my question?" Comprehension answers "now that I've chosen it, how do I call it correctly?" Parameter types, valid values, units, coordinate systems, join keys, response shape, edge cases. The same distinction appears in every tool-using agent stack: OpenAI function calling separates function descriptions from typed parameter schemas; MCP tool manifests do the same; OpenAPI contracts sit next to catalogue entries, not inside them. For the same OPSIS source the discovery entry above points to, the comprehension packaging looks like this:
# Example comprehension: tool schema + semantic hints for OPSIS
tool: opsis.get_infrastructure
description: "Retrieve infrastructure features within a bounding box,
optionally filtered by mode and climate-risk threshold."
parameters:
bbox:
type: array[number]
format: "[minLon, minLat, maxLon, maxLat]"
crs: "WGS84 (EPSG:4326)"
example: [33.9, -4.7, 41.9, 5.0] # East Africa
modes:
type: array[string]
values: ["road", "rail", "air", "maritime"]
climate_risk_min:
type: number
range: [0.0, 1.0]
semantics: "0 = no exposure; 1 = highest modelled exposure to any
hazard (flood, cyclone, heat)"
response:
type: "GeoJSON FeatureCollection"
key_fields:
iso3: "ISO 3166-1 alpha-3 country code (joins to World Bank, IATI)"
mode: "one of [road, rail, air, maritime]"
climate_risk: "composite 0-1 score, same scale as climate_risk_min"
example_query: "bbox=33.9,-4.7,41.9,5.0&modes=road&climate_risk_min=0.7"
Comprehension lives inside the connector, not in a separate artifact. It happens through progressive disclosure: the expert doesn't load the full schema up front. Instead, what the expert sees first is minimal (the tool description, a few typed parameters, one or two concrete examples) usually enough to attempt a first call. If the first call works, the expert has learned the shape of the source from a single round-trip and can move on. If the first call fails or returns an unexpected structure, the response itself becomes the next piece of comprehension: an error message that names which parameter was wrong, a response whose field names the expert now inspects to adjust the follow-up query. The expert keeps refining through interaction rather than digesting a 200-line YAML definition before starting. Exhaustive schema documentation exists when the source has it (OpenAPI contracts, JSON Schema, GraphQL introspection) but is not a prerequisite; the expert can reach it on demand if a particular call needs it. The design commitment is to start with what the source already provides, fill gaps with lightweight annotations, and let the expert learn the rest by calling.
Call is the expert invoking the connector and receiving a response. Unlike discovery and comprehension, there is deliberately little to say about it here: by design, call looks the same to the expert whether the connector reads a clean REST API directly, translates a complex legacy service, or fronts a serverless compute runtime. That uniformity is what makes the expert's reasoning portable across sources: the expert says get_infrastructure(bbox=..., modes=...) and gets a bounded response, with the same interaction shape regardless of what machinery sits behind. The machinery is the subject of the next subsection.
How a connector is packaged: skills and MCP servers
Connectors show up in two technical forms. These are not alternatives that compete for the same job: they are two different ways of packaging discovery, comprehension, and call, and most real connectors use some combination of the two.
A skill is a file the expert reads. It has a frontmatter-like header that does discovery (what this surface is, when to use it, what questions it's good for, what other surfaces it combines with) and body prose that does comprehension: what the parameters mean, what the units and coordinate systems are, what a typical response looks like, worked examples. Call is carried by whatever the skill tells the expert to invoke: the URL pattern for a clean REST API, the sequence of MCP tools for a more complex surface, the query language for a specialised store. A skill is intelligence the expert reads and reasons with; it doesn't run anything on its own.
An MCP server is a live service the expert connects to. Its tool manifest does discovery: what tools exist, what each is for. Its tool schemas do comprehension: typed parameters, descriptions, return types. Its tool invocations do call: the expert calls a function with parameters and receives a response. An MCP server is machinery the expert talks to; the server does the actual work of hitting the underlying surface.
The two cooperate naturally. When the surface is directly callable, the skill is often enough on its own: the skill tells the expert what this surface is good for and how to construct a request, and the expert calls the HTTP API directly. When the surface needs translation (a complex legacy protocol, esri-specific spatial encoding, dimension-based SDMX queries) an MCP server wraps the native protocol and exposes typed tools; the skill's role shifts. It no longer tells the expert how to assemble URLs or queries. Instead, it tells the expert which of several MCP tools to call, and in what combination, for this kind of question. The skill stays above; the MCP server handles the protocol below.
A one-liner captures the division of labour: a skill tells the expert what to do and why; an MCP server gives it the tools to do it. Most real connectors in TGIS use both together: a skill framing the surface, an MCP server handling protocol when the surface demands one, and both sharing the three capabilities between them.
Fig 2. Skill and MCP server as peer carriers of the three capabilities. Each column shows how that form does discovery (what exists), comprehension (how to call it), and call (getting the response). The bottom band records that in practice most connectors use both.
How much a connector has to do
Connectors also vary in how much work they have to do to make the external surface reachable at all. That variation is driven by the surface itself, not by the packaging choice: a clean REST API needs little bridging, while a folder of PDFs needs substantial bridging before any expert can use it. The figure below shows the two axes together: how the surface is packaged to the expert (horizontal) and how much the connector has to do to make the surface reachable (vertical).
Fig 3. The connector spectrum, on two axes. Vertical: what the surface demands of the connector, from "already directly callable" at the top to "doesn't yet exist in a usable form" at the bottom. Horizontal: how the connector is packaged to the expert, from skill-only through skill+MCP-together to MCP-dominant. The two axes are independent; real connectors tend to cluster along the diagonal because heavier surfaces typically need MCP involvement, but any packaging can in principle be used at any level.
Four levels on the vertical axis:
Surface is directly callable. A well-designed REST API with OpenAPI documentation, sensible parameters, and predictable responses. The World Bank indicators API and OPSIS's infrastructure REST endpoints sit here. The expert can construct requests and parse responses without protocol translation. A skill alone is usually enough: the skill frames the surface, and the expert hits the API directly.
Surface is callable with guidance. A usable API with specific idioms the expert needs coaching on: GraphQL endpoints like Transitland, OGC API Features with CQL2 filters, APIs with unusual pagination or authentication. The expert can still call directly, but the skill has more work to do: teaching the pattern, providing worked query examples, handling cursor-based pagination. Still a skill-dominant connector; the MCP side is optional.
Surface needs translation. A complex native interface that's hard for an LLM-powered expert to generate queries against reliably. ArcGIS REST services with esri-specific spatial encoding. SDMX with dimension-based query syntax. OGC WFS/WMS with SOAP and GML. Here an MCP server wraps the native protocol and exposes simple typed tools. The skill shifts role: it now tells the expert which tool to use for what, rather than teaching protocol details. For SDMX specifically this aligns with the community's own direction: the sponsors' September 2025 joint statement on AI-readiness explicitly explores MCP as a way for agents to access official statistics, and the IMF's StatGPT 2.0 already demonstrates AI querying of SDMX-structured data.
Surface doesn't yet exist in a usable form. The surface has to be built before it can be served. Static downloads on Zenodo, CSV dumps, PDF reports need pre-ingestion into a queryable store. A multi-source climate-risk raster stack, a zonal aggregation across billions of geometries, imagery inference on Sentinel tiles, format conversion (shapefiles to GeoParquet, NetCDF to Zarr, GeoTIFFs to COG with appropriate chunking) need precomputation. Both patterns put an MCP server in front of an infrastructure layer that either holds ingested data or runs serverless compute on demand. Geo-native platforms like Fused (UDFs as HTTP endpoints) and Wherobots (distributed spatial compute with an MCP-based coding assistant) sit here, alongside general-purpose runtimes like Coiled, Modal, and Lithops: the backends the EO community uses to build Zarr data cubes from Sentinel imagery at planetary scale. This is also where remote compute lives: any expert whose operation exceeds what it can hold in its own context calls a connector at this end of the spectrum. For ecosystem work where TGIS's job is to prepare data that doesn't yet exist in usable form, this end is also how the system contributes back: the UDF or compute pipeline that produced a derived layer can itself be published as a skill or MCP tool for other AI tools to reuse.
Across all four levels, the skill-vs-MCP choice is genuinely independent. Most sources TGIS reaches today are at the "directly callable" or "callable with guidance" levels, packaged mostly through skills. Sources at the "needs translation" level use MCP servers with skills guiding the expert in tool selection. Sources at the "doesn't yet exist" level always use MCP on the call side, with substantial skill work on top to brief the expert about what the prepared surface provides.
The sources TGIS reaches today sit across the spectrum as follows:
| Source | Surface | Reachability | Packaging |
|---|---|---|---|
| World Bank | REST/JSON | Directly callable | Skill |
| OPSIS | REST/JSON | Directly callable | Skill |
| OGC API Features | REST/JSON (CQL2) | Callable with guidance | Skill with patterns |
| Transitland | GraphQL | Callable with guidance | Skill with patterns |
| PortWatch | ArcGIS REST | Needs translation | Skill + MCP |
| OECD/ITF | SDMX | Needs translation | Skill + MCP |
| Overture Maps | S3/Parquet | Needs translation | Skill + MCP (DuckDB) |
| African Transport DB | Static download | Needs building | Skill + MCP + ingestion |
| (any) | Climate-risk layer that doesn't yet exist | Needs building | Skill + MCP + compute |
Why this matters
Pushing connector complexity into skills and MCP servers rather than into the expert's own reasoning is a design commitment grounded in evidence. Community benchmarks like GeoBenchX evaluate the tool-calling capabilities of LLMs on multi-step geospatial tasks and find common errors include misunderstanding geometrical relationships, relying on outdated knowledge, and inefficient data manipulation. The expert should not be constructing WKT geometries, encoding ArcGIS spatial reference objects, managing chunk indices, orchestrating Dask clusters, or picking chunking strategies for a Zarr write. It should say region=KEN or ask for zonal statistics on a climate layer, and the connector underneath handles it.
The three domain experts
With the shared connector machinery in place, what differs across the three domain experts is not how they reach their sources but what those sources look like and what idioms each category imposes. Structured data arrives as rows keyed by dimension. Geospatial data arrives as geometries with coordinates. Unstructured knowledge arrives as passages of text. Each expert is specialised for the shape of its world.
The structured-data expert
The structured-data expert handles country-level indicators, time series, and statistical tables. Tabular APIs (World Bank, OECD/SDMX, IATI) deal in indicators and categorical data: filter by dimension (country, year, indicator code), get back rows of values. Spatial references are abstract: country or region codes (ISO 3166, UN M.49), not coordinates. Responses are typically small (hundreds to thousands of rows). The expert can say "get road fatality rates for East African countries, 2020–2025" and receive a clean table.
What's distinctive about this expert is how unequal its sources are in comprehension readiness. SDMX sources arrive with comprehension built in. Every dimension has a formal definition, every value is constrained to a codelist, and structural metadata travels with the data. An expert querying OECD transport statistics via SDMX already knows what each field means, what values are valid, and how observations relate to each other. LLM hallucinations drop significantly when grounded in this kind of structured semantic context. For SDMX sources, the comprehension layer is largely free. The standard was designed for exactly this kind of machine interpretability. For non-SDMX sources (World Bank REST/JSON, IATI REST/XML, ADB and AfDB portals), comprehension requires more work but happens incrementally through the progressive-disclosure pattern described earlier. Most have OpenAPI specs, JSON Schema, or well-documented response shapes. The structured-data expert works across all of them through a consistent query pattern, even where the underlying calls differ.
The geospatial expert
The geospatial expert sees two kinds of data: vector and raster. Vector features (roads as LineStrings, ports as Points, administrative areas as Polygons) are the most common in transport contexts and the most compact, delivered over REST or GraphQL and stored natively or in cloud-friendly forms like GeoParquet. Raster data is grid-shaped, one or more values per cell; it covers climate-risk layers, land-cover classifications, elevation models, and (at the heaviest end) satellite imagery, which adds multiple spectral bands per pixel and a temporal axis of repeat observations. Generic raster is served as heavyweight legacy formats (GeoTIFF, NetCDF) or their cloud-native successors (COG, Zarr); satellite archives (Sentinel, Landsat, commercial EO) can reach terabytes per scene stack. Between the two, response sizes range from tens of kilobytes (a country capital as a Point) to terabytes (a multi-year Sentinel-2 archive over a corridor). The geospatial expert's job is to ask for only the subset a question actually needs, regardless of which kind of data is involved.
Queries combine spatial filters (bounding box, point+radius, polygon, tile) with attribute filters (feature type, hazard class, cloud cover, time window); responses come back as vector features with coordinates, raster tiles, or bounded imagery extracts. Spatial references are literal: WGS84 latitude/longitude, bounding boxes, full geometries. The expert can say "get all road segments within 50 km of Mombasa port that have flood risk > 0.7" and receive a set of map features, or "give me the mean NDVI over this corridor for Q2 2025" and receive a bounded raster summary.
What's distinctive about this expert is the shape of the spatial query surface. Across both kinds of data, a small set of spatial query patterns covers most of the work:
| Pattern | Description | Example |
|---|---|---|
| Bounding box | Features or pixels within a rectangle | "Road network in this map extent" |
| Point + radius | Features within distance of a point | "Ports within 100 km of Dar es Salaam" |
| Region lookup | Features within a named administrative boundary | "Infrastructure in Kenya" |
| Corridor query | Features along a route/line | "Climate risk along the Mombasa–Nairobi corridor" |
| Intersection | Features that overlap with another geometry | "Road segments that cross flood zones" |
Region lookup and bounding box together cover 80% of use cases. Corridor and intersection queries are more advanced but critical for transport-specific analysis. And the expert should not need to construct WKT geometries, encode ArcGIS spatial reference objects, pick chunking strategies for a Zarr read, or assemble tile coordinates for a Sentinel request to perform any of these queries. It should be able to say region=KEN or bbox=36.6,-1.5,37.1,-1.1 and get results. The complexity of spatial encoding (whatever the data type) lives in the connector, not in the expert's reasoning.
When the data needs to be produced. Not every geospatial answer already exists. Often an MCP or API will return ready-made segmentation masks, classifications, or extracted features that the expert can consume directly: no compute needed. Other times the derived data has to be generated: "Segment flooded roads along a corridor after cyclone X" can't be satisfied by a lookup. When this happens, the expert dispatches to a remote compute runtime.
The remote compute isn't exclusively ML. It's whichever form of computation fits the question: an ML model doing segmentation, a rule-based spatial algorithm (flood extent from DEM + water level), a scientific simulation (network routing, hydrology), or a custom Python function that composes several of these. All share the same dispatch pattern: the expert calls a serverless runtime with bounded inputs, receives a bounded result, with lineage traced back to what produced it.
For the ML case specifically, the 2026 landscape has three layers to reach. Model catalog: STAC-MLM is a live open spec (v1.3) describing a geospatial model well enough that inference is reproducible across platforms. Model hub: geospatial foundation models like Prithvi-EO, Clay, and SatMAE are on Hugging Face with open weights; task-specific fine-tunes follow the same pattern. Serverless compute runtime: Modal, Replicate, Google Vertex AI, AWS SageMaker Serverless Inference, and Hugging Face Inference Endpoints all ship production on-demand compute today.
Composing catalog lookup and compute dispatch through an LLM-driven expert (the pattern the figure depicts) is where geospatial AI agent tech is heading. Google's Geospatial Reasoning / Earth AI is one early public example, with a Gemini-based agent orchestrating foundation models across imagery, population, and environment data.
Fig 4. One path the geospatial expert can take when an answer has to be computed: query a model catalog (STAC-MLM descriptions pointing to Hugging Face weights), dispatch to a serverless compute runtime (Modal, Replicate, Vertex AI, SageMaker, Hugging Face Inference Endpoints), receive the derived output. The figure shows the ML-inference path; the same dispatch pattern works for scientific simulation and rule-based processing.
The unstructured-knowledge expert
Transport information has a third component, probably larger than both tabular and geospatial data: unstructured knowledge. Policy reports, NDC commitments, project evaluations, corridor studies, master plans, research papers, conference proceedings, HVT and RECaP study outputs, World Bank project completion reports, news articles about transport developments. This is where institutional knowledge lives. It's what gives the numbers context. A road safety statistic for Kenya is more useful when an expert can also surface the HVT study that evaluated the interventions tried there, or the NDC commitment that pledged a shift to non-motorised transport, or the project evaluation that found maintenance budgets were diverted.
What's distinctive about this expert is that it doesn't query schemas: it retrieves passages. The unstructured-knowledge expert uses retrieval-augmented generation (RAG) as its primary pattern. Documents are indexed (chunked, embedded, stored in a vector database) and when the expert receives a question it retrieves the most relevant passages before generating a response. The expert's answer is grounded in actual source material rather than whatever the model absorbed during training.
The practical workflow:
- Index key document collections. HVT/RIDE/RECaP research outputs, SLOCAT policy tracker documents, World Bank transport project documents, NDC submissions with transport components, ITF policy papers.
- Cross-reference with structured data. The structured data says what happened. The unstructured knowledge says why, and what was tried. The fusion expert joins both into a single answer.
- Every claim from an unstructured source carries a citation back to the original document. The expert always points to the evidence. That's where trust comes from.
This is the part of the transport information space that's most naturally suited to AI and least served by existing standards work. TDC catalogues datasets. SDMX structures statistics. Nobody makes the sector's accumulated knowledge searchable and synthesisable alongside live data. That's a genuine gap.
The fusion expert: aligning multi-modalities
The fusion expert is called when the orchestrator has gathered outputs from two or more domain experts that need to be combined. Its job is mechanical alignment: making the outputs combinable without changing what they mean.
The three domain experts face different worlds, but they need to cooperate on almost every outcomes question. "What is the climate risk to road corridors in East Africa?" needs the structured-data expert (World Bank indicators), the geospatial expert (OPSIS infrastructure + climate layers), and possibly the unstructured-knowledge expert (relevant research findings). They have to speak the same language where their outputs meet, and that language is what the fusion expert supplies.
What fusion does, concretely:
- Unit and format normalisation. Two sources report road length in kilometres vs metres; the fusion expert harmonises. Two sources return GeoJSON vs GeoPackage; the fusion expert picks one target and converts.
- Geographic alignment. The structured-data expert returns indicators keyed by ISO country code; the geospatial expert returns features with coordinates. The fusion expert uses shared reference frames (described below) to bring them onto a common basis.
- Temporal alignment. Each source has its own temporal model: different granularity, different period semantics, different lag. The fusion expert uses shared temporal metadata (also described below) to decide whether two pieces of evidence are comparable for the period in question.
- Type-joining. Statistical indicators need to sit alongside geospatial features and policy documents in the same answer. The fusion expert handles the join: country indicators attached to country polygons; policy commitments linked to the spending records they commit; research findings attached to the outcomes they evaluate.
Most cross-source questions are fusion-dominated, not reconciliation-dominated. The sources are complementary (different facets of the same picture), and the work is alignment: picking formats, choosing common references, making sure temporal windows match. In the Sub-Saharan Africa corridors example earlier in this page, passes 3 and 4 are entirely fusion; no two sources disagreed on the same number.
Fusion is also where some of the work crosses the line from reasoning to computation. A large spatial join between a country's road network and a climate-risk raster, a temporal resampling across thousands of stations, or a multi-source aggregation at sub-national granularity is not something the expert should hold in its own context. The fusion expert calls remote compute for these operations and receives a bounded result, exactly as the domain experts do when they need to prepare data that doesn't yet exist in usable form.
Geographic alignment
Different APIs express the same place differently:
| API Type | How Geography is Expressed |
|---|---|
| World Bank | country=KEN;TZA;UGA;ETH (ISO codes) |
| OECD/SDMX | REF_AREA=KEN+TZA+UGA+ETH |
| OPSIS | bbox=28.8,-11.7,51.4,5.0 (bounding box) |
| PortWatch ArcGIS | geometry={"rings":...}&geometryType=esriGeometryPolygon |
| OGC API Features | bbox=28.8,-11.7,51.4,5.0 or CQL2 spatial filter |
| Overture Maps | Parquet partition by S2 cell or DuckDB spatial filter |
The service layer provides a geographic reference resolver so experts don't have to construct these translations themselves. The expert says "East Africa"; the resolver knows this means ISO codes KEN, TZA, UGA, ETH, RWA, BDI, SSD, SOM, DJI, ERI for tabular queries and bounding box [28.8, -11.7, 51.4, 5.0] for spatial queries. The resolver exposes a small set of lookup tools, and returns every result in a single stable envelope so the fusion expert can parse any resolver output with one contract:
/resolve/country?lat=-1.3&lon=36.8
→ {
"type": "country",
"id": "KEN",
"id_scheme": "ISO-3166-1-alpha-3",
"name": "Kenya",
"parents": [{"type": "region", "id": "east-africa", "name": "East Africa"}],
"geometry": {"kind": "polygon-ref", "ref": "country/KEN"}
}
/resolve/region?name=East Africa
→ {
"type": "region",
"id": "east-africa",
"id_scheme": "internal",
"name": "East Africa",
"members": [
{"type": "country", "id": "KEN", "id_scheme": "ISO-3166-1-alpha-3"},
{"type": "country", "id": "TZA", "id_scheme": "ISO-3166-1-alpha-3"}
// ...
],
"geometry": {"kind": "bbox", "coords": [28.8, -11.7, 51.4, 5.0]}
}
/resolve/port?name=Mombasa
→ {
"type": "port",
"id": "KEMBA",
"id_scheme": "UN-LOCODE",
"name": "Mombasa",
"parents": [{"type": "country", "id": "KEN", "id_scheme": "ISO-3166-1-alpha-3"}],
"geometry": {"kind": "point", "coords": [39.67, -4.04]}
}
Every resolver response carries the same top-level keys: type (what kind of entity), id + id_scheme (how to reference it), name (human-readable), a relational link (parents or members, depending on direction), and a typed geometry payload whose kind discriminates which coordinate shape to expect. The fusion expert reads geometry.kind and handles point, bbox, or polygon-ref consistently, regardless of whether the thing resolved was a country, a region, a port, a corridor, or any future entity type.
Shared identifiers link other data types: ISO country codes across tabular datasets, Port LOCODE across port-related data, IATA/ICAO codes for aviation. No universal identifier exists for roads, rail lines, or transit stops, so spatial joining fills the gap (find the World Bank transport spending for the country that contains this OPSIS road segment) with the resolver doing point-in-polygon lookups.
Temporal alignment
Time is as fragmented as geography, in more dimensions and with less visible convention. Sources disagree on:
| Dimension | How sources vary |
|---|---|
| Granularity | Annual (World Bank indicators), quarterly (OPSIS updates), monthly (many OECD series), daily or intra-day (PortWatch disruption events) |
| Period semantics | Calendar year vs fiscal year (IATI); period instant (a snapshot date) vs period interval (a covered range); observation date vs reporting date vs publication date |
| Lag | World Bank indicators arrive with 1–2 year lag; OPSIS quarterly with near-current state; PortWatch near-real-time; IATI with variable reporting lag |
| Calendar | Gregorian for most sources; some MENA statistics expose Hijri alongside Gregorian; financial-year conventions differ by country |
| Representation | ISO 8601 date vs year integer vs SDMX TIME_PERIOD (annual 2024, quarterly 2024-Q1, monthly 2024-01) vs Unix timestamp |
A question like "road investment in Ethiopia in 2023" resolves to different things depending on whether you're asking what was committed in Ethiopia's fiscal year 2023, what was disbursed in calendar year 2023, or what the reporting system records as 2023 (which for IATI may be disbursements reported during 2023, including retrospective corrections to earlier years). Combining evidence across sources without accounting for these differences produces numbers that are technically correct per-source and meaningfully wrong in combination.
The fusion expert handles this through a temporal resolver with the same envelope pattern as the geographic one. Temporal expressions are normalised to a stable response that the fusion expert can reason over consistently:
/resolve/period?expression=2024
→ {
"type": "period",
"id": "2024",
"id_scheme": "ISO-8601-year",
"kind": "interval",
"start": "2024-01-01",
"end": "2024-12-31",
"calendar": "gregorian",
"semantics": "calendar-year"
}
/resolve/period?expression=FY2023&country=ETH
→ {
"type": "period",
"id": "FY2023-ETH",
"id_scheme": "internal",
"kind": "interval",
"start": "2023-07-08",
"end": "2024-07-07",
"calendar": "gregorian",
"semantics": "fiscal-year",
"context": {"country": "ETH", "fiscal-year-start": "Hamle 1"}
}
/resolve/period?expression=2024-Q1
→ {
"type": "period",
"id": "2024-Q1",
"id_scheme": "ISO-8601-quarter",
"kind": "interval",
"start": "2024-01-01",
"end": "2024-03-31",
"calendar": "gregorian",
"semantics": "calendar-quarter"
}
Every resolved period carries type, id + id_scheme, kind (instant or interval), explicit start and end in ISO 8601, calendar, and semantics (calendar-year, fiscal-year, observation-window, reporting-window). Where a period is context-dependent (fiscal year for Ethiopia is different from fiscal year for India) the context field records what's needed to interpret it.
Alongside the resolver, datasets carry temporal metadata with the same fields: what period each observation covers, what the semantics are, what the expected lag is between observation and publication. The fusion expert uses this to decide, for a given question, whether two pieces of evidence are temporally comparable: whether combining 2023 infrastructure data with 2025 spending data is honest, whether a fiscal-year spending figure can be compared with a calendar-year outcome, whether near-real-time port data can sit alongside annual aggregates without misleading the reader. When exact alignment is impossible, the fusion expert picks nearest-matching observations and records the approximation in the trace. When alignment is not possible without distortion, the fusion expert flags the mismatch and lets the reconciliation expert or the orchestrator decide how to present it.
Where fusion ends and reconciliation begins
Fusion handles different facets of the picture: different sources filling in different parts of a coherent whole. Reconciliation handles the same facet, seen differently: different sources publishing materially different values for the same indicator. In the Kenya road-safety question, fusion aligns the reported series with the WHO-modelled series (same concept, different methodology); reconciliation then detects that the two series materially disagree and prepares the surface-both presentation described next.
The reconciliation expert: surfacing disagreement
The reconciliation expert is called when the orchestrator has gathered two or more sources that publish the same indicator with materially different values. WHO-modelled versus police-reported road fatalities is the canonical case: the same country's safety record, two materially different series, each authoritative within its own methodology.
When disagreement beyond tolerance is detected, TGIS does not silently pick a winner. The reconciliation expert produces a surface-both output: both values with per-source provenance, and a one-line explanation of why they differ: different methodology, different collection year, different definition. The orchestrator folds this into the final answer alongside the other evidence. The reconciliation log records the decision so it can be audited later.
Workflows: when reconciliation is part of the answer
Most outcomes questions don't need reconciliation: one expert is called, one value comes back. A smaller set of questions have a shape where the honest answer depends on the reality of the data itself, and for those the orchestrator runs a workflow that puts ecosystem pre-checks (accuracy, representativeness, freshness) before outcomes retrieval and the reconciliation expert composes the findings into a qualified answer rather than a single number. The Kenya road-safety question takes this shape. "Has road safety in Kenya improved over the last decade?" is an outcomes question, but answering it responsibly needs the data interrogated first. Reported fatality figures from national police sources typically under-count pedestrian and motorcyclist deaths, and WHO-modelled estimates correct for this: the two series can diverge by a factor of three or more, and their trends can point in different directions. A single-number answer collapsing either series into "yes" or "no" would be dishonest. The workflow for this question therefore runs roughly as follows:
- The structured-data expert retrieves the reported series (police or national statistical office).
- The structured-data expert retrieves the WHO-modelled series.
- The reconciliation expert compares the two series, flags the divergence as beyond tolerance, and prepares a surface-both presentation.
- The orchestrator composes an outcomes answer of the form "the reported trend shows X; the modelled trend shows Y; the gap is primarily explained by Z; the confidence on 'are roads actually safer' is wider than either single series suggests."
This is the pattern the concept page refers to when it says the two sides interact. Ecosystem pre-checks feed into outcomes answers where the underlying data is known to be non-trivially imperfect. The reconciliation expert is the component that does this work.
The presenter: composing the answer
The presenter receives the synthesised evidence and decides how to present it. Five output forms are available: text, tables, maps, figures, and the structured reconciliation log. Most answers use more than one.
The choice of form depends on the question and the audience. A few patterns:
- Text + reconciliation log is the analyst default. A narrative paragraph covers the finding; the log is expandable for anyone reviewing the answer.
- Map as primary output is the natural fit for spatial questions. "Which East African corridors have the highest climate risk?" returns a map with corridors colour-coded by risk score, with the text as supporting narrative. The answer is the map: the presenter composes it from the geospatial expert's output.
- Table + figure fits comparative and trend questions. Side-by-side country comparisons, time-series of an indicator, ranked lists.
- Text-heavy with inline citations is the unstructured-knowledge default. When the answer draws on policy documents and research findings, the presenter renders it as narrative with every claim hyperlinked to the original document.
The presenter is also where persona-variation happens. An analyst sees the full surface-both detail and the trace on demand. A policymaker may see a single reconciled headline with a confidence band, with the detail one click away. The underlying evidence is the same; the rendering differs. (Persona variation is a live open question on the downstream side; the analyst view is the current live capability, policymaker and investor views come later.)