Aviation Safety - Presentation Demo¶

Aletheia is a GraphRAG platform designed for domain-specific analytical reasoning over knowledge graphs.

It provides the following capabilities:

• Data Ingestion across multiple domain-specific knowledge graphs
• Schema inference mechanisms based on LLMs and Ontologies
• Entities and Relationships Extraction, normalization and deduplication
• Hybrid search: Graph traversal plus semantic embeddings
• Temporal relationships
• Embedded ontology access for domain-aware reasoning
• Direct Cypher analytics with validation and sanitization
• Cross-graph reasoning across independent knowledge domains
• MCP connectors with self-describing, schema-aware tool interfaces

A. Why Safety Analysts Need Every Detail¶

The Swiss Cheese Model¶

Aviation safety operates on a fundamental principle: accidents don't happen because of a single failure. James Reason's Swiss Cheese Model explains how accidents occur in complex systems through the alignment of multiple weaknesses.

                  HAZARD
                    │
                    ▼
            ┌───────────────┐
            │   ░░░░░░░░░   │  ← Layer 1: Procedures
            │ ░░░░░  ░░░░░░ │     (hole: outdated checklist)
            └───────────────┘
                    │
                    ▼
            ┌───────────────┐
            │  ░░░░░░░░░░░  │  ← Layer 2: Technology
            │ ░░░░  ░░░░░░░ │     (hole: sensor calibration)
            └───────────────┘
                    │
                    ▼
            ┌───────────────┐
            │   ░░░░░░░░░   │  ← Layer 3: Training
            │ ░░░░░░░  ░░░░ │     (hole: CRM gap)
            └───────────────┘
                    │
                    ▼
              ⚠️ ACCIDENT
        (when holes align)

Each "slice of cheese" represents a defense layer (procedures, technology, training, supervision), and the "holes" are inherent weaknesses. An accident occurs only when holes in multiple layers align, allowing a hazard to traverse the entire system.

Why This Matters for GraphRAG¶

Safety analysts investigating incidents need to:

1. Trace causal chains — From latent conditions through active failures to the accident
2. Identify contributing factors — Weather, human factors, maintenance, equipment
3. Connect related incidents — Similar failures across different contexts
4. Find patterns — Recurring weaknesses in defense layers

This requires navigating relationships across multiple entities — exactly what GraphRAG enables. A simple keyword search cannot connect a maintenance procedure gap in Lyon with a similar QA failure in Palma de Mallorca. A knowledge graph can.

B. Why GraphRAG and not RAG?¶

RAG (Vector stores) allow AI to find conceptually similar information through embeddings: keyword search on steroids. Vector search measures proximity in semantic meaning, not structure or causality.

RAG is fast, scalable, and excellent for recall, but it doesn't understand relationships. RAG can tell you what looks alike, not what belongs together.

C. Introducing EASA ECCAIRS for Aviation Safety¶

ECCAIRS (European Coordination Centre for Accident and Incident Reporting Systems) is the European framework used to collect, manage, and analyze aviation safety occurrences.

It covers:

• Standardized procedures for reporting incidents by aviation stakeholders
• Centralized and consolidated occurrence database where reports are stored and shared
• Common aviation safety taxonomy that structures how events, causes, and contributing factors are described

Together, these elements ensure consistency, comparability, and regulatory alignment in safety data across Europe.

What is an Occurrence?¶

An occurrence is the formal record of any aviation safety-related incident or event. It combines:

Together, the structured data enables large-scale analysis and comparability, while the narrative preserves context, nuance, and operational detail that cannot be fully captured by predefined fields.

D. ECCAIRS Ontology¶

Although it is published as a taxonomy rather than a formal ontology, the ECCAIRS model can be directly transformed into an ontology that describes the aviation safety domain.

It defines core domain concepts such as:

• Occurrence
• Runway
• Aircraft
• Engine
• Flight Crew Member
• Aerodrome

The resulting ontology represents a highly specialized domain vocabulary, using precise and formal terminology. For instance, Aerodrome is the canonical term covering airports, heliports, and other landing areas, reflecting the regulatory need for unambiguous and standardized language.

E. Occurrence Dataset¶

Given that the ECCAIRS occurrence database is not publicly available, this use case is built using synthetic but realistic incident data.

The current dataset contains 10 safety incidents.

The sample documents are modeled as aviation safety occurrence reports, combining structured, taxonomy-aligned fields (metadata, aircraft, flight phase, weather, findings, and recommendations) with a free-text narrative describing what happened in operational terms.

Sample Document¶

F. The Challenge¶

The challenge for Aletheia is to generate accurate answers given the combined characteristics of both the input data and the questions.

Data Challenges¶

Example Query¶

A question such as "What incidents in Barcelona or Madrid involved Boeing aircraft and resulted in emergency declarations (MAYDAY or PAN-PAN)?" must resolve to a single incident matching all criteria:

The Madrid incident (2024-0734-EU) involved an Airbus A330-200, not Boeing, so it doesn't match.

G. The Knowledge Graphs¶

Aletheia's aviation safety use case spans three independent knowledge graphs, each built from different data sources and covering a distinct regulatory domain.

Three Domains, One Analytical Platform¶

These three datasets mirror the real-world safety lifecycle: an incident triggers an investigation that produces recommendations, which may escalate to mandatory directives. In practice, analysts must cross-reference these databases manually. Aletheia connects them through knowledge graphs.

Aviation Safety Graph¶

10 European aviation occurrences from 2024, with multilingual narratives (English, French, Spanish).

Entities:

Relationships:

Safety Recommendations Graph¶

94 EASA Safety Recommendations linked to 138 occurrences, issued by 37 investigation authorities across 24 countries.

Entities:

Relationships:

Airworthiness Directives Graph¶

743 EASA Airworthiness Directives covering 331 aircraft types, referencing 228 technical documents, approved by 137 design approval holders.

Entities:

Relationships:

Knowledge Graph Visualization¶

FalkorDB Graph Explorer¶

H. Building the Knowledge Graphs¶

When building a knowledge graph, an LLM is used to extract entities and relationships from text.

Without schema guidance, this process easily leads to inconsistent entity types, ambiguous relationships, and fragmented vocabularies, resulting in a graph that lacks structural coherence.

Why Schema Matters¶

Schema Inference in Aletheia¶

Schema inference determines the vocabulary of entity types, relationships, and properties that the LLM must use during extraction.

The most robust approach combines LLM-assisted schema inference with domain ontologies. In this model:

1. LLM-driven schema discovery
2. Semantic alignment with existing ontology through knowledge graph search and embeddings
3. Automatic resolution of terminology mismatches

This hybrid approach enables the extraction of high-confidence schemas, enriched and constrained by authoritative domain knowledge.

Inferred Schemas¶

Each knowledge graph has its own domain-specific schema, inferred through the same ontology-guided process.

Knowledge Graph: aviation_safety_quality

✅ Entity types: 6
   - Occurrence
   - Aircraft
   - AerodromeGeneral
   - Operator
   - Manufacturer
   - Country

✅ Relationship types: 5
   - INVOLVED_AIRCRAFT
   - OCCURRED_AT
   - OPERATED_BY
   - MANUFACTURED_BY
   - LOCATED_IN

Knowledge Graph: safety_recommendations

✅ Entity types: 6
   - SafetyRecommendation
   - Occurrence
   - Aircraft
   - SafetyInvestigationAuthority
   - Manufacturer
   - Country

✅ Relationship types: 5
   - STEMS_FROM
   - ISSUES
   - INVOLVES
   - MANUFACTURES
   - LOCATES

Knowledge Graph: airworthiness_directives

✅ Entity types: 4
   - AirworthinessDirective
   - AircraftType
   - Document
   - DesignApprovalHolder

✅ Relationship types: 4
   - APPLIES_TO
   - APPROVED_BY
   - REFERENCES
   - SUPERSEDES

Ingestion Process¶

I. ECCAIRS Ontology Graph¶

Ontologies encode expert knowledge about a domain.

In the context of knowledge graphs, an ontology serves as a schema or blueprint that describes:

The Terminology Problem¶

Without ontology alignment, inconsistencies arise:

Ontology Graph Solution¶

How can we link an entity (like airport) with the corresponding ontology class (aerodrome)?

Aletheia provides the ability to build an ontology graph — a semantic projection of a formal ontology that enables the system to access domain knowledge through embeddings and graph search.

The ontology graph is built before the knowledge graph, ensuring schema inference can rely on it.

During schema inference, when detecting an "Airport" entity, Aletheia queries the ontology graph using semantic search to find the matching canonical class ("Aerodrome").

Ontology Graph in FalkorDB¶

ECCAIRS Ontology Structure¶

J. The MCP Connector¶

Aletheia exposes each knowledge graph through a self-describing MCP (Model Context Protocol) connector — a standardized interface that allows any LLM to discover, search, traverse, and analyze the graph.

Each connector is domain-aware: it advertises what entity types, relationship types, and query patterns exist in its graph, enabling the LLM to generate precise queries without guessing at graph structure.

Tool Surface¶

Each connector provides 13 tools organized into five capability groups:

Search Capabilities¶

The search tool provides unified access to nodes, edges, and communities with advanced filtering:

Cypher Analytics¶

The run_cypher tool executes read-only Cypher queries with a four-stage validation pipeline:

LLM generates Cypher
        │
        ▼
┌─ Stage 1: LLM Fixups ─────────────┐
│  Smart quotes, unicode, missing    │
│  RETURN clause, direction fixes    │
└────────────────────────────────────┘
        │
        ▼
┌─ Stage 2: FalkorDB Dialect ────────┐
│  Auto-fix: date(), toLower, etc.   │
│  Reject: APOC, pattern comp., etc. │
└────────────────────────────────────┘
        │
        ▼
┌─ Stage 3: Security Whitelist ──────┐
│  Only: MATCH, WHERE, RETURN, WITH  │
│  Reject all write operations       │
└────────────────────────────────────┘
        │
        ▼
┌─ Stage 4: Safety Injection ────────┐
│  Auto-inject LIMIT, timeout        │
└────────────────────────────────────┘
        │
        ▼
   GRAPH.RO_QUERY (database-level
   read-only enforcement)

Results are returned as typed JSON envelopes (scalar, tabular, graph, or path) with metadata including row count, truncation status, execution time, and a list of any auto-corrections applied to the query.

Embedded Ontology Access¶

Every data connector includes search_ontology and explore_ontology tools that query the ECCAIRS ontology directly. The LLM can decode aviation shorthand (e.g., "SCF-NP" → "System/Component Failure - Non-Powerplant", "ATA 36" → "Pneumatic system") without switching to a separate ontology server.

Self-Describing Connectors¶

Each connector advertises its domain schema in the tool metadata. For example, the Safety Recommendations connector tells the LLM:

Entity types: Aircraft, Country, Manufacturer, Occurrence,
              SafetyInvestigationAuthority, SafetyRecommendation

Edge types:   INVOLVES, ISSUES, LOCATES, MANUFACTURES, STEMS_FROM

This means the LLM knows — before making any query — that STEMS_FROM connects SafetyRecommendation to Occurrence, that ISSUES connects SafetyInvestigationAuthority to SafetyRecommendation, and so on. It can write precise filtered searches and valid Cypher queries on the first attempt.

K. Aletheia in Action¶

The demo is structured as a progressive showcase across four levels of complexity. Each level introduces new capabilities, building from semantic search over a single graph to full analytical reasoning across three knowledge graphs with ontology support.

Act 1 uses a single tool. By Act 4, the system orchestrates 10+ tool calls across four knowledge graphs in a single conversation turn.

Act 1: "It Understands"¶

Single knowledge graph (Aviation Safety). Semantic search. Goal: demonstrate that Aletheia interprets meaning, not just keywords — across languages and imprecise queries.

Q1 — Semantic cause lookup

"What caused the turbulence-related injuries near Barcelona?"

Q2 — Multilingual entity resolution

"¿Qué fabricante construyó el avión que tuvo el incidente de humo en cabina sobre el Mediterráneo?"

Q3 — Temporal reasoning

"What was the emergency response timeline at Palma de Mallorca during the fuel spill?"

Act 2: "It Navigates"¶

Single knowledge graph, but now using the full MCP tool surface: get_schema, run_cypher, explore_node, search_ontology. Same data, dramatically more powerful questions.

Q4 — Schema-aware analytics

"Which manufacturer has the highest incident count in our data, and what types of aircraft are involved for each?"

Expected approach: The LLM calls get_schema to understand the graph topology, then writes a Cypher aggregation query:

MATCH (o:Occurrence)-[:INVOLVED_AIRCRAFT]->(a:Aircraft)-[:MANUFACTURED_BY]->(m:Manufacturer)
RETURN m.name, count(DISTINCT o) AS incidents, collect(DISTINCT a.name) AS aircraft_types
ORDER BY incidents DESC

Q5 — Graph traversal + analytical follow-up

"Show me everything connected to the Palma de Mallorca fuel spill — the aircraft, operator, airport, country, manufacturer. Then tell me if this operator has other incidents in our data."

Expected approach: explore_node("Occurrence 2024-0975-EU", depth=2) maps the full neighborhood, then a Cypher query checks for other incidents by the same operator.

Q6 — Ontology-informed analysis

"What ECCAIRS occurrence categories are represented in our incident data? Use the ECCAIRS ontology to classify each incident."

Expected approach: The LLM calls search_ontology to retrieve ECCAIRS Occurrence Category Values, then maps each incident's characteristics against the formal taxonomy.

Act 3: "It Connects"¶

Three knowledge graphs (Aviation Safety + Safety Recommendations + Airworthiness Directives). Cross-domain reasoning. Goal: show that connecting independent graphs multiplies analytical power.

Q7 — Cross-graph entity resolution

"The fuel spill at Palma de Mallorca involved a Vueling A320. Are there any active airworthiness directives for the A320 fuel system, and have any safety recommendations been issued for similar maintenance-induced fuel integrity issues?"

Expected approach:

1. Aviation Safety graph: confirm the incident details — A320-232, incorrect valve torque
2. AD graph: search for ADs applying to A320 fuel system (ATA 28)
3. SR graph: search for recommendations related to maintenance-induced fuel integrity failures

── Aviation Safety connector ──────────────────────────────
search("Palma de Mallorca fuel spill A320")
  → Occurrence 2024-0975-EU, A320-232, Vueling, ATA 28

── Airworthiness Directives connector ─────────────────────
search("A320 fuel system", entity_types=["AirworthinessDirective"])
run_cypher("""
  MATCH (ad:AirworthinessDirective)-[:APPLIES_TO]->(at:AircraftType)
  WHERE at.name CONTAINS 'A320' AND ad.name CONTAINS 'fuel'
  RETURN ad.name, at.name
""")

── Safety Recommendations connector ───────────────────────
search("maintenance fuel integrity failure", entity_types=["SafetyRecommendation"])

Q8 — Manufacturer intelligence report

"Build me an Airbus risk profile: count the 2024 incidents, find any open safety recommendations for the involved aircraft types, and list active ADs. What's the combined risk picture?"

Expected approach: Cypher analytics on each graph, then cross-reference by aircraft type.

Act 4: "It Thinks Like an Analyst"¶

Three graphs + ECCAIRS ontology as semantic backbone. Full analytical reasoning. These are questions that safety analysts actually ask — and they normally require days of manual cross-referencing.

Q9 — ECCAIRS-coded analytical query

"Any SCF-NP events with ATA 36 involvement that resulted in diversions? Cross-reference with open safety recommendations and applicable ADs."

Expected approach:

1. Ontology decode: search_ontology("SCF-NP") → "System/Component Failure - Non-Powerplant"; search_ontology("ATA 36") → "Pneumatic system (bleed air, pressurization, ducting)"
2. Aviation Safety graph: search with decoded terms
3. AD graph: search for ATA 36 directives → discover the dense cluster of A320-36-xxxx SBs and AD 2025-0096
4. SR graph: search for open recommendations on bleed/pneumatic systems

Q10 — Full safety lifecycle trace

"Trace the complete safety lifecycle for bleed duct fire risk on wide-body Airbus: start with AD 2021-0280 for the A380 bleed duct detachment issue. Did the corrective actions prevent any 2024 incidents? Do similar risks exist for A320 or A330 fleets without equivalent ADs?"

Expected approach:

1. AD graph: explore_node("AD 2021-0280", depth=2) → map the directive, its referenced SBs, aircraft applicability
2. Aviation Safety graph: search for A380 bleed/pneumatic incidents in 2024 → zero results (the AD worked)
3. AD graph: Cypher query for all ATA 36 ADs across Airbus types → find AD 2025-0096 (A320) and AD 2023-0136 (A330)
4. Gap analysis: identify aircraft types with similar risk but no equivalent directive

Q11 — Predictive gap analysis

"Identify 2024 incidents whose root causes have no matching airworthiness directive. For each gap, check if a safety recommendation exists. If neither exists, flag it as an unmonitored risk."

Expected approach:

1. Aviation Safety graph: Cypher to extract all incidents with their primary causes
2. For each cause pattern, search the AD graph for matching directives
3. Where no AD exists, search the SR graph for matching recommendations
4. Where neither exists → unmonitored risk

── Aviation Safety connector ──────────────────────────────
run_cypher("""
  MATCH (o:Occurrence)-[:INVOLVED_AIRCRAFT]->(a:Aircraft)
         -[:MANUFACTURED_BY]->(m:Manufacturer)
  RETURN o.name, a.name, m.name, o.summary
""")
  → 10 incidents with aircraft types and summaries

── For each incident, cross-reference ─────────────────────

── Airworthiness Directives connector ─────────────────────
search("<cause pattern>", entity_types=["AirworthinessDirective"])
  → AD found? ✓ Covered  |  No match? → check SR graph

── Safety Recommendations connector ───────────────────────
search("<cause pattern>", entity_types=["SafetyRecommendation"])
  → SR found? ⚠ Pending  |  No match? → 🔴 Unmonitored risk

Q12 — Predictive gap analysis (emerging risks)

"Identify emerging risks that haven't yet reached the Airworthiness Directive stage: Find 2024 incidents with novel or unusual primary causes. Check if any Safety Recommendations exist for similar issues (even if from different aircraft types). Verify that NO Airworthiness Directive currently addresses these specific failure modes. Flag these as 'regulatory gaps' requiring proactive attention. Estimate time-to-AD based on historical patterns from similar issues."

Q13 — Manufacturer intelligence (consolidated report)

"Create a consolidated Airbus safety intelligence report: List all 2024 incidents involving Airbus aircraft from Aviation Safety. Find all open Safety Recommendations mentioning Airbus or specific Airbus types. Retrieve all active Airworthiness Directives for Airbus aircraft. Identify any Airbus models appearing across all three datasets with unresolved issues. Recommend which Airbus fleet operators should prioritize based on combined risk exposure."

L. Summary¶

Capabilities Demonstrated¶

The demo builds through four levels of analytical sophistication:

The Progression¶

Act 1: "Find me something"
  ↓
Act 2: "Compute this for me"
  ↓
Act 3: "Connect these domains"
  ↓
Act 4: "Think like a safety analyst"

Full Capability Matrix¶