JourneyMind AI

Hintergrund

In der Reisebranche sind Störungs-Entscheidungen kosten- und vertragsrelevant. Reine KI-Antworten reichen nicht, weil sie nicht prüfbar sind. Ich wollte zeigen, dass man KI-Orchestrierung mit einem deterministischen, erklärbaren Entscheidungskern kombinieren kann — auch unter Hackathon-Zeitdruck.

Problem

Bei Reisestörungen müssen Operatoren Passagierkontext, Tarifregeln und Umbuchungsoptionen schnell abgleichen. Manuell ist das langsam und inkonsistent; ein rein generativer KI-Ansatz ist nicht nachvollziehbar und nicht prüfbar.

Ziele

• KI für Kontext- und Options-Vorbereitung, nicht für die finale Entscheidung
• Deterministischen, regelbasierten Entscheidungsmotor mit integrierter Begründung
• REST-API zwischen React-Frontend und FastAPI-Backend für einfache Integration
• End-to-End-Tests des primären Operator-Ablaufs mit Playwright

Architektur

Technologie-Stack

React · TypeScript · Vite · Tailwind CSS · FastAPI · Python · REST APIs · Playwright

Technische Herausforderungen

• Trennung von probabilistischer KI-Orchestrierung und deterministischer Entscheidung
• Begründung als echter Output des Entscheidungsmotors, nicht nachträglich generiert
• Constraints so modellieren, dass sie maschinell evaluierbar und menschlich lesbar bleiben
• Hackathon-Umfang: Architektur vollständig, aber bewusst nicht alle Produktionsaspekte umgesetzt

Abwägungen

• Deterministischer Kern bietet Prüfbarkeit, aber weniger Flexibilität als ein End-to-End-Modell — für regulierte Domänen die richtige Wahl
• REST statt GraphQL/gRPC: kleine, lesbare Oberfläche ohne zusätzlichen Werkzeugaufwand; Transport ist hier nicht der Engpass
• Erklärbarkeit erfordert mehr Datenpflege, aber sie ist der Hauptwert des Systems
• Hackathon-Umfang: Architektur und Kernabläufe sind vollständig; Auth, Lasttests und Live-Daten-Integration sind entworfen, aber nicht implementiert

Erkenntnisse

• Determinismus allein garantiert keine Erklärbarkeit — Begründung muss im Entscheidungsprozess entstehen
• KI-Orchestrierung außerhalb des finalen Entscheidungsschritts hält das System prüfbar
• End-to-End-Tests des Operator-Ablaufs decken mehr auf als isolierte Unit-Tests
• Explizite Constraints sind im regulierten Kontext wertvoller als implizite Modell-Flexibilität

Aktueller Status

Hackathon-Build mit vollständiger Architektur und Kernabläufen — ohne Live-Daten-Integration oder Produktionshärtung.

Zukünftige Verbesserungen

• Produktionshärtung: Auth, Rate-Limiting, Beobachtbarkeit, Resilienz
• Live-Daten-Integration für Störungen, Tarife und Umbuchungen
• Konfigurierbare Constraints ohne Code-Änderung
• Audit-Log für Empfehlungen und manuelle Überschreibungen

Geschätzte Meilensteine

• Q3 2026 — Auth und grundlegende Beobachtbarkeit
• Q4 2026 — Konfigurierbare Constraints und Audit-Log
• Q1 2027 — Live-Daten-Integration und Lasttests