🤖 machine learning

DisasterLex: An Expert Concept-to-Schema Knowledge Graph for Geospatial Reasoning in Disaster Analytics

DisasterLex is a knowledge-graph-mediated framework that enhances natural-language-to-SQL performance in disaster analytics by inserting an Expert Knowledge Graph between user queries and heterogeneous geospatial databases, thereby significantly improving accuracy in routing and multi-table reasoning compared to state-of-the-art baselines.

Original authors: Yiming Xiao, Ankit Basu, Kai Yin, Sahil Vartak, Christian Swords, Ali Mostafavi

Published 2026-06-01

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Yiming Xiao, Ankit Basu, Kai Yin, Sahil Vartak, Christian Swords, Ali Mostafavi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are a disaster manager trying to save lives during a hurricane. You have a massive library of data—thousands of spreadsheets containing information about flood depths, hospital locations, power grid status, and population vulnerability. But these spreadsheets are messy, use different languages, and are connected in complex ways that only an expert would understand.

You want to ask a simple question like, "Which hospitals in Harris County are at risk of flooding, and where should we send rescue teams?"

In the past, asking a computer this question was like trying to find a specific needle in a haystack by throwing the whole haystack at a robot and hoping it guesses right. The robot would get confused by the sheer volume of data, mix up unrelated tables, or hallucinate (make up) connections that don't exist.

DisasterLex is a new system designed to solve this problem. Think of it as a super-smart, expert librarian who sits between you (the human) and the messy data library.

Here is how it works, broken down into simple steps:

1. The "Expert Map" (The Knowledge Graph)

Before the system even looks at the data, the researchers built a special "Expert Map."

The Problem: Computers don't naturally understand that "heavy rain" leads to "flooding," which leads to "power outages," which then stops "hospitals" from working.
The Solution: The team created a digital map (called an Expert Knowledge Graph) that connects these concepts like a flowchart. It's like a subway map where the stops are concepts (e.g., "Rain," "Flood," "Power Outage") and the lines show how they affect each other.
The Bridge: This map is also connected to the actual data tables. It knows that the concept "Hospitals" in the map points to a specific spreadsheet column about hospital counts.

2. The Four-Step "Orchestra"

When you ask a question, DisasterLex doesn't just dump the question at the computer. It runs it through a four-step assembly line, like a conductor leading an orchestra:

Step 1: The Translator (Context Extraction): It listens to your question and figures out the "vibe." Is this a routine check or a life-or-death emergency? It also identifies the location and the type of disaster (e.g., "Flood in Harris County").
Step 2: The Traffic Cop (Routing): Based on the vibe, it sends the question to the right "department." Is this about saving lives? Fixing infrastructure? Or just assessing damage? This prevents the system from wasting time looking at the wrong data.
Step 3: The Planner (Causal Reasoning): This is the magic step. The system looks at its "Expert Map" to plan the route. It asks: "To answer this, I need to follow the path from 'Rain' to 'Flood' to 'Hospitals'." It uses this map to decide exactly which spreadsheets to open, ignoring the 130 other spreadsheets that aren't relevant.
Step 4: The Executor (SQL Generation): Finally, it writes the specific computer code (SQL) to pull the data from the selected spreadsheets, runs the query, and synthesizes the answer into a clear report.

3. Why It's Better Than the Competition

The researchers tested DisasterLex against other top-tier AI systems.

The Old Way: Other systems tried to read the entire library of 150 columns of data for every single question. This confused them, leading to "hallucinations" where they connected unrelated things (like linking flood data to population data just because they shared a city ID).
DisasterLex's Way: By using the "Expert Map," it narrowed the search down to just 10–20 relevant columns. It was like giving the robot a specific list of books to check instead of the whole library.

The Results:
DisasterLex beat the other systems by a wide margin (1.4 to 2.75 times better). The main reason the others failed was that they got lost in the "routing" (picking the wrong department) and "multi-table composition" (trying to join too many spreadsheets incorrectly). DisasterLex's step-by-step plan prevented these errors.

4. The Bottom Line

DisasterLex isn't a magic crystal ball that predicts the future. It is a precision tool that helps human experts get the right data faster.

It doesn't replace the human decision-maker; it acts as a high-speed assistant that ensures the human is looking at the right facts.
It is specifically designed for structured data (tables and spreadsheets), not just reading news articles.
It is currently tested on disaster data in Texas, but the "Expert Map" approach could theoretically be used for other complex fields where cause-and-effect matters, like medical triage or supply chains.

In short, DisasterLex turns a chaotic mess of data into a clear, actionable story by giving the AI a "cheat sheet" of expert knowledge before it even starts working.

Technical Summary: DisasterLex

Problem Statement

Disaster management relies on rapid access to structured, information-dense geospatial data (hazard, exposure, vulnerability, and infrastructure) to coordinate time-critical responses. While natural language interfaces (Text-to-SQL) have advanced, they fail in the disaster domain for three primary reasons:

Schema Heterogeneity: Disaster databases span dozens of tables with specialized semantics, sentinel values for missingness, and inverted scoring conventions (e.g., higher scores indicating higher vulnerability in one dataset but resilience in another).
Causal Reasoning Gaps: Domain experts reason over causal chains (e.g., low resilience $\rightarrow$ reduced response capacity; flood depth $\rightarrow$ structural damage). Standard Text-to-SQL models lack these external causal encodings, leading to hallucinated joins between semantically unrelated tables sharing only a geographic key.
Retrieval Mismatch: Standard Retrieval-Augmented Generation (RAG) retrieves text passages, whereas disaster analytics requires executable SQL over structured tables. Existing graph-augmented RAG methods improve passage retrieval but do not solve the schema selection problem required for structured query answering.

Methodology: DisasterLex Framework

DisasterLex is a knowledge-graph-mediated agentic framework designed to bridge natural language queries and structured geospatial databases. It consists of three integrated components:

1. Unified Knowledge Graph

The system hosts a unified graph in Neo4j combining two sub-graphs:

Disaster Data Catalog Graph (DDCG): Auto-introspected from the relational database (DuckDB). It represents tables as DataTable nodes, columns as DataColumn nodes, and valid join patterns as JoinRule nodes.
Expert Knowledge Graph (EKG): A curated, directed graph of 107 domain concepts connected by 117 typed causal edges (types: INCREASES, REDUCES, INDICATES, REQUIRES, SCALES). Each concept includes synonym lists for fuzzy matching.
Concept-to-Schema Bridge: 52 explicit edges map EKG concept nodes to specific DataTable nodes in the DDCG. This allows the system to traverse from a user's natural language concept (e.g., "flood occurrence") to the specific database tables (e.g., HP_FLD_002) required for execution.

2. Concept-Aware Schema Retrieval

Instead of injecting the full 150-column schema into the prompt, DisasterLex performs a three-step retrieval:

Concept Matching: Uses token-boundary regular expressions to match query terms against EKG concept synonyms.
Graph Traversal: Performs a 1-hop Cypher traversal from activated concepts to connected DataTable nodes, retrieving relevant columns, join rules, and data-quality warnings.
Context Injection: Replaces the full schema with a compact block of 10–20 relevant columns, significantly reducing attention dilution.

3. Four-Stage Orchestration Pipeline

Implemented as a directed graph in LangGraph, the pipeline enforces an operational structure derived from the Incident Command System (ICS):

Context & Criticality Extraction: Parses the query for area of interest, hazard type, and a criticality level (1–5). It performs rule-based data-availability checks to surface missing or blocked tables.
Operational Domain Classification: Routes the query into one of three ICS-motivated clusters: Life-Safety Operations, Damage Assessment & Response, or Infrastructure Mitigation. Each cluster uses a specialized prompt template.
Causal-Informed Planning: A ReAct agent retrieves causal edges from the EKG and performs web searches (if needed) to construct a structured analysis plan, decomposing the query into sub-tasks and identifying necessary metrics.
Tool-Augmented Execution: A second ReAct agent executes the plan using two tools:
- Text-to-SQL Tool: Generates SQL based on the concept-aware schema, with syntax validation and retry logic.
- Knowledge Graph Tool: Traverses causal rules to synthesize evidence.
  The agent synthesizes an incident report with findings, recommendations (gated by criticality), and evidence.

Key Contributions

Concept-Level Schema Linking: The introduction of an Expert Knowledge Graph (EKG) as a schema selection layer. By interposing 107 concepts and 117 causal edges between queries and a 36-table schema, the system reduces prompt context from 150 columns to ~10–20, addressing the schema-selection failure mode of prior Text-to-SQL and RAG approaches.
ICS-Motivated Orchestration: A four-stage pipeline that decomposes disaster analytics queries into criticality extraction, cluster routing, causal planning, and grounded execution. Ablation studies demonstrate that removing routing or planning significantly degrades performance, particularly for multi-table composition.
Four-Tier Diagnostic Benchmark: A 75-case test set organized into four tiers to isolate specific failure modes:
- Tier R (Routing): Correct cluster and query-type selection.
- Tier K (EKG Grounding): Presence of expected causal tokens in the answer.
- Tier M (Multi-Table): Correct SQL joins across 2–4 tables.
- Tier D (Disclosure): Transparent reporting of missing or blocked data.
Cross-Model Evidence: Evaluation across seven base models (ranging from 8B to 70B parameters, including closed-source and open-weight families) and four state-of-the-art baselines (LightRAG, HippoRAG 2, ReFoRCE, CHESS).

Results

Evaluated on a 75-query test set over a Texas-wide disaster analytics database (36 tables, 150 columns):

Performance: DisasterLex achieved overall scores between 1.65 and 3.56 (on a 5.0 scale) across the seven base models.
Comparison: It outperformed four state-of-the-art baselines by 1.4× to 2.75× on every base model. All external baselines scored below 2.0 overall, while DisasterLex exceeded 2.5 on five of seven models.
Failure Analysis: Baseline failures clustered in routing (Tier R) and multi-table SQL composition (Tier M). DisasterLex explicitly addresses these via its routing layer and concept-aware schema retrieval.
Ablation Insights:
- Routing was universally critical; removing it caused the largest drops in Tier M scores (0.81–2.67 points) across all models.
- Planning and EKG effects varied by model capability. For instance, removing planning dropped Tier K scores by 3.19 on Qwen 3.6 but only 0.20–0.48 on other models, suggesting that the value of explicit orchestration is modulated by the base model's intrinsic reasoning capabilities.

Significance and Claims

The paper claims that for disaster analytics, the concept-to-schema layer plus orchestration matters more than the choice of retrieval substrate or text-to-SQL agent. The results suggest that general-purpose retrieval and Text-to-SQL pipelines are insufficient for domains requiring causal reasoning over heterogeneous, structured geospatial data.

DisasterLex demonstrates that an expert-curated causal concept graph, acting as a domain-specific schema selection layer, can effectively mediate between natural language and complex relational databases. The authors posit that this pattern is transferable to other domains where expert causal knowledge coexists with time-sensitive structured data, such as medical triage or supply-chain disruption.

The work is presented as a decision-support tool, explicitly noting that its outputs are not authoritative incident-command guidance and require human review, particularly for high-criticality recommendations. The system is designed to surface uncertainty (via data-availability disclosures) rather than replace expert judgment.