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.

Ontology graph by the numbers: 540 classes, ~204,592 controlled-value individuals, ~205,132 nodes total in ontology_eccairs.

E. Occurrence Dataset¶

The aviation safety corpus has been engineered for analyst-grade demonstration. It contains 100 markdown incident reports under use_cases/aviation_safety/data/:

• 22 hand-authored cluster reports — four deliberate patterns planted to support multi-hop and cross-graph reasoning:

• 68 LLM-generated noise reports — produced by scripts/generate_aviation_corpus.py from a committed parameter table, validated through AviationSafetyParser. The noise raises retrieval pressure without diluting cluster signals.

• 9 multilingual reports (Spanish, French, German, Italian) embedded in the noise to demonstrate cross-language semantic search.

Structured fields use ECCAIRS canonical labels (Flight phase ∈ {Approach, En route, Landing, Manoeuvring, Standing, Take-off, Taxi, …}; Aircraft damage ∈ {None, Minor, Substantial, Destroyed, …}; Injury level ∈ {None, Minor, Serious, Fatal, …}). The cheatsheet lives at use_cases/aviation_safety/ontology_controlled_values.md.

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¶

100 European aviation occurrences from 2024, with multilingual narratives (English, Spanish, French, German, Italian).

Entities:

Relationships:

Safety Recommendations Graph¶

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

Entities:

Relationships:

Airworthiness Directives Graph¶

~1,000 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¶

Searching the ECCAIRS ontology¶

The ontology graph is queried like any other Aletheia graph. Two examples used live in the demo:

search_ontology("SCF-NP")
→ "SCF-NP: System/component failure or malfunction [non-powerplant]"
   (Occurrence categoryValue individual)

search_ontology("ATA 29 hydraulic power")
→ "2900 Hydraulic power system" (level 2)
→ "2910 Hydraulic main system" (level 3)
→ "Hydraulic main system line/fitting" (level 4)

These individual nodes are wired by INSTANCE_OF edges to their parent value classes (e.g., Occurrence_categoryValue, Ata_chapterValue), so kg_explore_node can pivot from an individual to its peers in the same enumeration.

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 follows an analyst's actual workflow over a quarter's worth of incidents: triage the corpus, surface anomalies, narrow to one, escalate to a structured investigation, and close on a budget-bounded decision. The four blocks correspond to the analyst's mental model — "What's recurring? Why? What should we do? What can we afford?" — not to a tour of capabilities.

Each block is presenter-ready. Italics under a query describe what the system does before output appears. Admonition boxes labelled Live presenter mark moments where latency or autonomy needs framing for the audience.

Chat structure¶

The 21 questions run across six chats. Each boundary is a real topic shift — splitting the chats keeps each LLM context window focused on what the analyst is doing right now and avoids cross-talk between unrelated tool results.

Inline markers in the script (🆕 **New chat**) flag each transition.

Block 1 — "Patterns of the quarter"¶

Single graph (aviation_safety). Goal: triage 2024 occurrences, surface a mosaic of anomalies, demonstrate the workspace UX (table → chart → map, save artifacts, edit live), and end on the ontology-jargon question that picks one anomaly to drill into.

Block opener. "We've ingested every 2024 occurrence into the aviation safety graph — 100 reports across the EU. Before drilling anywhere, I want to know what patterns are recurring this quarter."

Q1 — Triage table¶

"What recurring failure patterns do you see in our 2024 occurrences? Group by primary cause family and operator. Include incident count, severity distribution, and the airports involved."

The system runs a Cypher aggregation; the table renders inline in the chat.

The top three patterns surface visibly: the Iberia hydraulic cluster, the Embraer ERJ-195 DMC software anomaly, and the Frankfurt EDDF autumn bird strikes.

Q2 — Save the table to the workspace¶

"Save that as a document called 'Recurring Patterns 2024' under a folder named '2025 Annual Review'."

A new folder appears in the workspace tree; the table renders as a saved markdown document.

📁 Workspace now contains: - 2025 Annual Review/Recurring Patterns 2024.md

Q3 — Live edit the saved document¶

"Keep only the top three patterns. Drop the long tail."

The saved document re-renders in place; the workspace tree timestamp updates.

Q4 — Chart by operator¶

"Now show me a chart: severity-weighted incident frequency, top operators on the X axis, the three patterns stacked."

A bar chart renders; the chart is itself savable.

The Iberia bar towers over the others on the hydraulic stack. Operators of Embraer ERJ-195 cluster vertically. Frankfurt EDDF arrivals cluster on the Lufthansa/Ryanair/KLM/Eurowings/Condor bars.

Q5 — Map the incidents¶

"Plot the incidents on a map, color-coded by pattern."

A map renders with markers colored by cluster; the geocoder resolves airport names to coordinates.

The Iberia hydraulic cluster traces an Iberian-peninsula + southern-European footprint. The ERJ-195 DMC events spread across northern Europe. The Frankfurt cluster is a single dense pin.

Q6 — ECCAIRS jargon focus pivot (showpiece)¶

"Any SCF-NP events on Airbus A320-family aircraft involving the hydraulic system during take-off and landing in 2024? Decode SCF-NP and the flight-phase codes against the ECCAIRS ontology. Which operator concentrates the cluster?"

The system queries the ECCAIRS ontology graph: search_ontology("SCF-NP") returns the System/Component Failure (Non-Powerplant) individual; search_ontology("Take-off"/"Landing") returns the matching Flight_phaseValue individuals. Then a Cypher query against aviation_safety filters by aircraft-type prefix and flight-phase tokens. The narrative answer is at analyst register — codes are decoded inline.

The cluster surfaces clearly: Iberia, six A320-family hydraulic-line incidents, six airports.

Block close. "Iberia is the strongest signal. Let me drill into it."

Block 2 — "Iberia deep dive"¶

Multi-graph (aviation_safety + safety_recommendations + airworthiness_directives). Goal: build the operator picture, surface the regulatory gap, save findings, and visualize the network as an independent UI component.

Block opener. "Iberia, six hydraulic-line incidents on A320-family aircraft. I want the timeline first, then the operator's risk profile, then I'll cross to the regulators to see if anyone is covering this specific failure mode."

Q7 — Operator timeline¶

"Show me Iberia's complete 2024 hydraulic timeline: incident, aircraft, airport, date, runway phase, severity."

A chronological table renders; one row per incident.

Q8 — Operator profile¶

"Build Iberia's risk profile from this data: fleet composition involved, common contributing factors, maintenance organization signals, geographic spread."

The system aggregates contributing factors, maintenance references, and locations into a structured profile section. Execution is direct — the analyst does not want a briefing yet.

Q9 — Cross-graph SR + AD coverage¶

"Cross-reference the safety_recommendations and airworthiness_directives graphs: any open EASA Safety Recommendation covering hydraulic-line fatigue near mounting-bracket attachments? Any active Airworthiness Directive on A320-family hydraulic-line inspection intervals or mounting-bracket attachments?"

The system fans out two parallel queries — one against safety_recommendations, one against airworthiness_directives. Results land in a two-column comparison.

The result reveals the regulatory gap. SR coverage of fixed-wing A320 hydraulic-line fatigue near mounting brackets is absent (the existing hydraulic SRs are AS 350 helicopter servo-transparency cases). AD coverage is adjacent: EASA AD 2024-0097 targets A318/A319/A320/A321 main-landing-gear door actuator fittings — but not the hydraulic-line/mounting-bracket pattern Iberia is showing.

Q10 — Save the findings¶

"Save these findings as 'Iberia hydraulic pattern' under the Annual Review folder."

A new document is added to the workspace.

📁 Workspace now contains: - 2025 Annual Review/Recurring Patterns 2024.md - 2025 Annual Review/Iberia hydraulic pattern.md

Q11 — Network graph (independent UI component)¶

"Show me Iberia's 2024 incident network as a graph: the operator at the center, first-degree links to aircraft and airports, second-degree to contributing factors and maintenance events."

The graph viewer opens as a separate workspace artifact. Edges are typed; the analyst can pan and zoom; clicking a node opens its details.

This is the visual moment of Block 2. The graph shows the six aircraft fanning out from Iberia, the airports fanning out from each aircraft, and the contributing factors collapsing into a few common nodes — visually the systemic pattern is unmistakable.

Q12 — Save the graph¶

"Save the graph in the Iberia folder."

The assistant offers two folder layouts: (a) create a new Iberia/ folder at the workspace root, or (b) save inside the existing 2025 Annual Review/ folder. The script chooses (a) create new Iberia folder — the workspace listings below assume a flat Iberia/ sibling. The assistant then writes the graph as Iberia/2024-incident-network.graph.

📁 Workspace now contains: - 2025 Annual Review/Recurring Patterns 2024.md - 2025 Annual Review/Iberia hydraulic pattern.md - Iberia/2024-incident-network.graph

Block close. "I have the operator picture and the regulatory gap. Time to escalate this to a structured investigation that leaves a PROV-O audit trail."

Block 3 — "Structured investigation"¶

Briefing creation + reasoning agent. Goal: introduce briefings explicitly. The analyst escalates to a scoped investigation with PROV-O auditing.

Block opener. "Manual queries will only get me so far. I want a structured, auditable investigation. The graph layer should plan and execute, and the briefing keeps the scope honest."

Q13 — Trigger briefing creation¶

"I want to launch a structured investigation. Build me a consolidated risk briefing for Iberia across all three graphs."

The assistant offers the available aviation templates as structured options. The picker shows the five aviation-profile templates (Operator Risk Profile, Fleet Defect Investigation, Regulatory Gap Analysis, Recommendation Lifecycle Trace, Airport Safety Profile) plus the generic Investigation Briefing. The analyst selects Operator Risk Profile.

Q14 — Elicitation walkthrough (narrative beat)¶

The assistant's elicitation flow runs before any heavyweight reasoning starts. Phase A is graph-grounded reconnaissance; Phase B is a sequence of structured-options cards, one section at a time. Each card lists 3–4 mutually-exclusive options; the analyst clicks the matching choice.

Phase A — Reconnaissance (no analyst input). The assistant runs semantic_search against all three graphs and explore_node on the verified Iberia node, then auto-fills the Entry Points table (Iberia → Operator, the involved aircraft types, the airport ICAOs) and the Domain Terms section (decoded ECCAIRS codes from search_ontology).

Phase B — Section cards (analyst chooses one option per card). The script's recommended choices below produce the comprehensive cross-graph briefing the rest of the demo expects.

Phase C — Approval. The completed briefing renders with all eight sections filled (Objective, Scope, Entry Points, Domain Terms, Graph Strategy, Expected Output, Constraints, Analyst Decisions). The analyst types "approved, proceed with the investigation"; the briefing transitions Draft → IN_REVIEW → APPROVED. The assistant then asks once more "Would you like to start the investigation now?" — the analyst confirms with "yes, start the investigation now".

Q15 — Watch the investigation run (no prompt; agent autonomy)¶

The reasoning agent (Phronesis) runs autonomously. The investigation graph populates incrementally in the workspace as the planner-executor loop progresses through plan → execute → observe → converge. Tool calls (Cypher, semantic search, ontology lookups) are visible inline; nothing is silent. The status panel shows the loop state: Planning → Executing → Synthesizing → Verifying → Complete.

Q16 — Show the investigation graph¶

"Show me the investigation graph."

The PROV-O investigation graph renders as an independent UI component, like the network graph in Block 2 but scoped to the run.

Q17 — Save the briefing and investigation¶

"Save the briefing and the investigation results in the Iberia folder."

Two artifacts are written to the existing Iberia/ folder (created in Q12). The assistant generates each as a markdown file: the briefing as the structured Operator Risk Profile document; the investigation results as the synthesized analyst-facing report (Executive Summary, Cluster analyses, Regulatory Gap, Recommendations, Claims).

📁 Workspace now contains: - 2025 Annual Review/Recurring Patterns 2024.md - 2025 Annual Review/Iberia hydraulic pattern.md - Iberia/2024-incident-network.graph - Iberia/Iberia Risk Profile Briefing 2024.md - Iberia/Iberia 2024 Consolidated Risk Assessment.md

Block close. "The investigation surfaced an open EASA Safety Recommendation directly applicable to the maintenance-audit gap, plus two more from the broader regulatory inventory that several operators in our 2024 corpus haven't yet implemented. Now I need to decide which we can fund."

Block 4 — "Decision: which recommendations do we fund?"¶

Decision agent (Euboulia). Goal: turn the analyst's accumulated portfolio (gap-analysis findings + EASA-derived recommendations) into a budget-bounded action plan.

Block opener. "From triage and the Iberia deep dive I have a candidate portfolio of safety actions, plus the EASA recommendations the investigation surfaced. Five-million-euro annual budget. Let me frame this for the decision agent."

Q18 — Frame the decision¶

"We have a candidate portfolio of safety actions: the Iberia maintenance audit, the ERJ-195 DMC software bulletin push, the Frankfurt 25L wildlife management upgrade, and three EASA-derived recommendations from the gap analysis. Each has an estimated implementation cost and an expected risk reduction. Help me decide which to implement under our €5M annual safety improvement budget — maximize total risk reduction."

Euboulia (the decision agent) is invoked. The 8-stage pipeline begins: analyzer → extractor → formulator → coder → assembler → executor → verifier → interpreter. The first three stages are gated by short approval prompts ("Does this problem statement capture what you're trying to solve?", "Are the extracted parameters correct and complete?", "Are the constraints and objective correctly identified?") — the analyst clicks through with Yes, proceed, Parameters look good, Constraints and objective are correct.

The analyst supplies the per-action input data when the executor stage asks for it:

MaxBudget = 5,000,000. Total cost if all six were selected: €6.9M — the budget binds, so the optimizer must choose. (Risk reduction is a dimensionless score; the units are arbitrary as long as they are consistent across rows.)

Q19 — Inspect the formulation¶

"Walk me through the formulation: what's the objective function, what are the constraints, what are the decision variables?"

The decision agent renders its problem as KaTeX — visible math, not a black box. The Problem panel header classifies it as BIP — Binary Integer Program, 1 binary variable, 2 constraints, 4 parameters (N, Cost, RiskReduction, MaxBudget), solver CVXPY (CBC backend).

The formulation is a 0-1 knapsack:

• Decision variables: $\text{Select}_i \in {0, 1}$ for $i \in {1, \ldots, N}$ — one per candidate. Selected at most once (binary).
• Objective: $\max \sum_{i=1}^{N} \text{RiskReduction}_i \cdot \text{Select}_i$
• Budget constraint: $\sum_{i=1}^{N} \text{Cost}_i \cdot \text{Select}_i \leq \text{MaxBudget}$, with $\text{MaxBudget} = 5{,}000{,}000$.

The formulate_clause stage emits each clause with a confidence score (5/5 expected for this problem). After the analyst accepts ("Model is correct"), the coder stage generates the CVXPY Python script, which the analyst can inspect under the Code tab before it runs.

Q20 — Run the optimization¶

"Run the optimization. Show me the optimal portfolio with the rationale for each item picked and rejected."

Stages 6–8 of the pipeline run: executor solves the BIP via CVXPY in a sandboxed subprocess, verifier confirms the solution against the constraints, interpreter renders the analyst-facing artifact. The Solution panel header reads optimal; the Objective Value reads 235.

The optimal portfolio for the Q18 input data:

Portfolio summary: 5 of 6 actions implemented · total cost €4.1M of €5M (82% utilization, €900K slack) · total risk reduction 235 units · 1/1 constraints verified.

Why Frankfurt 25L was excluded: at €2.8M it would consume the entire remaining budget after the other five (which together cost €4.1M and deliver risk reduction 235); swapping any selected item for Frankfurt would lower the objective. The interpreter renders the rationale inline in plain English, sourced from the optimizer's primal/dual values — not an LLM rationalization.

Q21 — Save the decision¶

"Save the decision file as '2026 Safety Investment Plan' in the Annual Review folder."

The decision is persisted to the Annual Review folder as a structured document. This is the artifact the analyst hands to leadership.

📁 Workspace at the end of the demo: - 2025 Annual Review/Recurring Patterns 2024.md - 2025 Annual Review/Iberia hydraulic pattern.md - 2025 Annual Review/2026 Safety Investment Plan.md - Iberia/2024-incident-network.graph - Iberia/Iberia Risk Profile Briefing 2024.md - Iberia/Iberia 2024 Consolidated Risk Assessment.md

Block close. "That's the case for the budget meeting. The triage gave me the population. The Iberia investigation gave me the audit trail. The decision agent gave me the portfolio. The system did not decide — I did. But every step is reproducible."

L. Summary¶

The demo follows an analyst's arc: triage → deep dive → structured investigation → decision. Each block adds capabilities; the cumulative work product is a folder of saved artifacts.

Capabilities by block¶

The arc¶

Block 1: "Find me something." Block 2: "Connect these." Block 3: "Investigate this." Block 4: "Decide for me."

The system did not decide. The analyst did. But every step is reproducible from saved artifacts and PROV-O records.

Workspace at the end¶

2025 Annual Review/
├── Recurring Patterns 2024.md
├── Iberia hydraulic pattern.md
├── 2026 Safety Investment Plan.md
└── Iberia/
    ├── network graph
    ├── Operator Risk Profile briefing
    └── investigation graph

That's the case for the budget meeting.