Grounded AI for rural planning

AI in rural planning: grounded, cited and checked

main tellingdepth: standard3 min markdown

How JackDaw works is explained under JackDaw. This block covers what the Beta taught about using AI in planning at all.

What worked

The main positive usability finding from the pilots is the combination of map-based interaction with plain-language dialogue. It helps users who need territorial evidence but do not work with advanced GIS, and it links spatial evidence to planning questions and stakeholder discussions (D4.2 §6.3). In the MAA tool, the Ramon assistant extracted stakeholders and objectives from pilot documents, and users then validated them, which reduced administrative effort (§6.3).

Conditions for trust

D4.2 concludes that natural-language interfaces help people reach complex spatial resources when they are connected to structured metadata, validated datasets and controlled analytical services. AI interaction “must remain grounded in reliable data, clear provenance, appropriate tool selection and transparent communication of limitations” (§12). In practice this means four rules:

1. Retrieve from a controlled corpus. The Advisor runs as a private RAG over project-related collections, not the open web (§3.7).
2. Show sources, data validity and limits in every output meant for users, as a corrective action before wider deployment (§6.4).
3. Keep people validating. Ramon’s proposals are created only after a user confirms them. Following FAIR2Adapt, claims extracted from documents need provenance and expert review before anyone treats them as reliable (§3.9, §9.4).
4. Keep sensitive data at home. MCP-based integration, local deployment and metadata-driven tool selection allow setups where data stays inside an institution, as public administrations and paying agencies require (§9.6).

What still fails

The pilots name heterogeneous local data, uneven metadata completeness, different levels of technical skill, and the need for outputs that non-technical stakeholders can understand (§6.3). The roadmap adds linguistic robustness, the handling of local place names, the reliability of spatial queries, and removing unnecessary technical detail from answers (§11.1). Advisor testers also met a wrong programme reference that was corrected later in the dialogue (D2.3 Annex B).

Where it is heading

The planned next steps are a Knowledge Graph behind the RAG, for entity linking and transparent evidence trails (§3.7), and continuous testing that includes the quality of AI responses (§11.1). The open problems are set out in the depth block that follows. The public outputs include SHIELD, which filters unsafe or irrelevant queries before the AI responds.

Open research problems the GeoAI Beta exposed

another tellingdepth: research3 min markdown

D4.2 treats its limitations as inputs for the final development phase, not as failures. Read as a research agenda, they fall into eight problems.

1. Retrieval is not analysis

A RAG engine returns a small top-ranked set of chunks, often 10 to 20. That is a relevance match against a subset of documents, not an analysis of the whole corpus, and broad questions return general statements (D4.2 §3.6). Open question: how can multi-step conversations, such as Boxes & Arrows agent graphs, make the coverage and depth of an answer checkable?

2. Metadata sets the ceiling

Generic tools are only as good as the descriptions they run on. Heterogeneous source quality makes the same tool behave unevenly across datasets (§3.2). Natural-language search “cannot fully compensate for incomplete records, weak keywords or inconsistent classification” (§3.4). Open question: how can metadata gaps be detected and repaired before they reach a user’s answer?

3. Languages and place names

Pilots work in national and regional languages, and D4.2 asks for stronger multilingual and place-name handling (§6.4, §11.1). In KijaniSpace, adapting JackDaw to languages such as Swahili “requires more than translation”. The assistant must respect local crops, farming practices, institutional constraints and literacy levels (§9.5).

4. Text plus space

GeoRAG needs text retrieval, metadata discovery and access to geospatial services to work together, and D4.2 says this needs stronger harmonisation (§3.7). Many regional questions cannot be answered from prose alone.

5. Provenance and explanation

The planned Knowledge Graph would link answers to entities, documents and datasets (§3.7). FAIR2Adapt contributes RO-Crate packages with JSON-LD metadata to document evidence chains, and the I-ADOPT framework to describe variables. Without such descriptions, terms like soil moisture, land surface temperature or flood exposure may mean different things in different projects (§9.4). On the side of model explanations, a CVUT paper on reasoning-grounded explanations (predict-and-explain with compressed reasoning) was presented at the XAI World Conference (project fact sheet).

6. Safety before the answer

SHIELD, released by CVUT on GitHub, is a safety framework that filters unsafe or irrelevant queries before the AI responds (project fact sheet).

7. Rural infrastructure

Map interaction must cope with large spatial layers and limited rural connectivity (§6.4). In the Lake Victoria Basin, the same components face limited internet, uneven data and users who need offline, mobile-first and multilingual access, which D4.2 calls a useful stress test (§9.5).

8. Evaluation itself

Validation so far has been case-by-case and qualitative. For D4.3 it moves to systematic consultation with WP5 (§11.1), with continuous testing that includes the quality of AI responses. How to measure whether an AI answer was useful for a planning decision is still an open question.