BSFZ-Antrag — Angaben zum Vorhaben

Zweck: Abbildung der tatsächlichen BSFZ-Formularfelder auf unsere vier Vorhaben. Bezugsdokumente: funding-work-packages.md (AP-Katalog), STRATEGY_public-funding.md (Vorhaben-Clustering), bsfz-ablehnungsrisiken.md (Argumentationsmuster).

NOTE

Konvention §3.3 „Durchgeführte Arbeiten“: Das BSFZ-Feld "Durchgeführte Arbeiten" beschreibt den geplanten Forschungsumfang, nicht nur bereits abgeschlossene Tätigkeiten. Einträge können sowohl retrospektive als auch prospektive Arbeiten umfassen.

---

Vorhaben 1 — Preisberechnung unter temporaler Datenunvollständigkeit

3.1 — Allgemeine Angaben

Titel des FuE-Vorhabens (max. 200 Zeichen)

[TODO — Entwurf:] Algorithmische Preisberechnung für Touristik-Pakete, wenn steuerrelevante Kostendaten erst nach Leistungserbringung verfügbar sind

Start des Vorhabens

[TODO] — frühester relevanter Commit: 2026-03-21 (Projektstart), frühester AP1-relevanter Commit: 2026-04-07 (tax-engine.md)

3.3 — Inhaltliche/Fachliche Angaben

Ziel des Vorhabens / Herausforderung / Wissenslücke (max. 1.500 Zeichen)

[TODO — Rohtext:]

Das Vorhaben entwickelt eine algorithmisch korrekte Pricing- und Steuerzerlegungs-Pipeline für die Bus-Touristik-Domain.

Die zentrale Herausforderung: Das System muss Verkaufspreise berechnen, obwohl die für die korrekte branchenspezifische Steuerberechnung erforderlichen Eingabedaten zum Zeitpunkt der Preisberechnung physisch nicht verfügbar sind. Die Steuerzerlegung hängt von tatsächlichen Lieferantenrechnungen und finalen Passagierzahlen ab — beides kennt das System erst nach der Reise. Trotzdem muss es vor der Reise einen korrekten, verkaufsfähigen Preis ausgeben.

Zusätzlich erzeugen Abfahrten mit gemischten Leistungsstrategien (Pauschal-Marge und Bordverkäufe) zwei steuerlich getrennte Einnahmenströme, die eine 1:N-Kardinalität zwischen Abfahrt und Steuer-Ledger-Einträgen erfordern. Länderübergreifende Touren (EU/Nicht-EU-Anteile) benötigen einen ratio-basierten Margen-Split mit Negativmargen-Clamping.

Die Kalkulations-Engine muss als vorgelagerte Pipeline korrekte Eingabedaten liefern, obwohl Costing und Pricing unabhängige Entity-Lifecycles mit Immutable-Append-Versionierung folgen.

Abgrenzung Stand der Technik (max. 500 Zeichen)

[TODO — Rohtext:]

Branchenübliche Systeme (Kubus, Tourplan) verwenden monolithische Preisberechnung ohne Trennung von Costing und Pricing. Keine existierende Lösung bietet automatische Eigenleistung/Fremdleistung-Diskriminierung mit departure-level Steuer-Aggregation. Ratio-basierte Margen-Aufteilungen bei länderübergreifenden Touren und Deferred Steuerzerlegung existieren in keiner bekannten Branchenlösung.

Durchgeführte Arbeiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Entwurf und Verwerfung eines Per-Variante-Steuerberechnungsansatzes (geschätzte Steuer aus total_net_cost / break_even_pax) — mathematisch falsch, keine Grundlage im Steuerrecht (dokumentiert in ADR-012)
• Entwurf und Verwerfung eines kombinierten Costing/Pricing-Entity mit JSONB-Override-Hack — verletzte Immutability-Garantie (dokumentiert in ADR-006)
• Entwicklung einer Deferral-Architektur: Trennung der Pipeline in Vor-Reise-Phase (Schätzung) und Nach-Reise-Phase (Steuerzerlegung im FinancialLedger)
• Ratio-basierter Algorithmus zur Aufteilung der Gewinnmarge in steuerpflichtigen und steuerfreien Anteil bei länderübergreifenden Touren
• Costing/Pricing-Trennung als unabhängige Entity-Lifecycles mit Immutable-Append-Versionierung
• Persistenz-Design für vier buchhaltungspflichtige Invarianten mit GoBD-konformer Unveränderbarkeit
• 1:N TaxLedgerEntry-Kardinalität für Mixed-Strategy-Departures (ADR-015)

Wissenschaftliche/technische/methodische Unsicherheiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Die architektonische Deferral-Entscheidung (ADR-012) ist getroffen, aber die FinancialLedger-Pipeline ist noch nicht validiert — es ist offen, ob die Vor-/Nach-Reise-Trennung unter realen Buchungskaskaden (Stornierungen, Teilstornierungen, Nachbuchungen) korrekte Steuerwerte produziert
• Der erste Lösungsansatz (Per-Variante-Steuer) war mathematisch falsch — das zeigt, dass der Lösungsweg nicht offensichtlich war
• Negativmargen-Clamping im Drittlands-Split erfordert Validierung gegen reale Buchungsdaten
• Die Kombination aus Immutable-Append-Versionierung und Deferred Steuerzerlegung über unabhängige Entity-Lifecycles hat keine Referenzimplementierung in der Branche
• Korrekte Steuerberechnung bei gemischten Strategien mit zwei unabhängigen Einnahmenströmen pro Abfahrt ist ungetestet

Anlagen

ADR-006, ADR-012, ADR-015, tax-engine.md, kalkulations-engine.md

Verwertungshorizont / Markteinführung

[TODO]

Verschlagwortung (min. 3 Schlagworte, max. 800 Zeichen)

[TODO — Entwurf:] Deferred Computation, Pricing-Pipeline, Temporale Datenunvollständigkeit, Immutable Versionierung, Multi-Varianten-Kalkulation, Touristik-ERP, SaaS, Margenbesteuerung

3.3.1 — Tabellarischer Arbeitsplan

Nr.	Titel	Zeitraum	Angestelltes Personal (PM)	Durchführung durch
AP1	Deferred-Pricing-Pipeline mit Post-Departure-Kostenzerlegung	[TODO]	[TODO]	Eigenbetrieblich
AP6	Two-Phase Kalkulations- & Preisgestaltungs-Engine	[TODO]	[TODO]	Eigenbetrieblich

---

---

Vorhaben 2 — Datenkonsistenz über Vertrauensgrenzen

3.1 — Allgemeine Angaben

Titel des FuE-Vorhabens (max. 200 Zeichen)

[TODO — Entwurf:] Dezentrale Datensynchronisation mit Immutability-Garantien und mandantenübergreifender Compliance für Edge-Computing-Systeme

Start des Vorhabens

[TODO]

3.3 — Inhaltliche/Fachliche Angaben

Ziel des Vorhabens / Herausforderung / Wissenslücke (max. 1.500 Zeichen)

[TODO — Rohtext:]

Das Vorhaben erforscht, wie ein verteiltes System Datenkonsistenz und Immutabilität gewährleistet, wenn Offline-Feldgeräte, konkurrierende Verkaufskanäle und kaskadierte Event-Pipelines widersprüchliche Anforderungen erzeugen.

Herausforderung 1 — Offline-Sync vs. Immutabilität: Busse operieren stundenlang offline. Das System erfasst Bordverkäufe und Schadensmeldungen lokal und synchronisiert später. GoBD-Immutabilität steht im Widerspruch zur Eventual Consistency — jeder Sync muss Unveränderbarkeit bereits persistierter Daten garantieren.

Herausforderung 2 — Concurrent Seat Holds: Gleichzeitige Sitzreservierung über Web, Telefon und Driver App mit Offline-Bordverkäufen. Bei Fahrzeugtausch existieren offline verkaufte Sitze nicht mehr — Konfliktlösung bei Reconnect ist offen.

Herausforderung 3 — Broadcast-Resilience: Kaskadierte Event-Pipelines müssen fehlerklassifiziert (transient vs. permanent, provider-spezifisch) und fehlertolerant zugestellt werden.

Herausforderung 4 — Cross-Tenant-Compliance: EU-561 Ruhezeiten gelten pro Fahrer, nicht pro Betreiber. Das Multi-Tenant-Modell isoliert Daten pro Mandant — Compliance-Aggregation über Mandantengrenzen ist ungelöst.

Herausforderung 5 — CRDT-Collaborative Editing: Disponenten bearbeiten Reisepläne gleichzeitig via CRDTs. Projektion opaker CRDT-Zustände auf relationale Tabellen, FK-Validierung im konfliktfreien Merge-Modell und GoBD-Audit über einen DAG gleichzeitiger Operationen sind ungelöst.

Abgrenzung Stand der Technik (max. 500 Zeichen)

[TODO — Rohtext:]

Kein existierendes System in der Bus-Touristik löst das Zusammenspiel von Offline-Sync mit Datenimmutabilität, Echtzeit-Sitzverwaltung über Online/Offline-Kanäle und Event-Driven Broadcast-Resilience. Existierende Lösungen behandeln diese Probleme isoliert. Das Cross-Tenant-Freelancer-Problem (mandantenübergreifende Fahrer-Compliance) ist branchenweit ungelöst.

Durchgeführte Arbeiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Differenzielles Sync-Protokoll (RxDB + custom NestJS batch API) mit server-wins Conflict Resolution und Idempotency-Deduplizierung via sync_idempotency_log
• Drei Lösungsansätze für mandantenübergreifende Fahrer-Compliance evaluiert: Ignorieren (rechtliches Risiko), Fahrer-Selbstdeklaration (fehlerbehaftet), Tachograph-Datenaustausch (IoT-Komplexität, Datenschutz) — Auswahl bei Projektstart offen
• DutyActivity-Abstraktion mit polymorpher Quellenunterscheidung (TACHOGRAPH_IMPORT, SELF_DECLARATION, TOUR_LEG)
• Concurrent Seat-Hold-Synchronisation über heterogene Verkaufskanäle via Hasura GraphQL Subscriptions mit optimistic UI reconciliation
• Event-Cascade-Orchestrierung über 4 Bounded Contexts: provider-spezifische Error Classification (transient vs. permanent) für fehlertolerante externe Zustellung
• 40+ formal spezifizierte Domain Events mit Payload-Contracts und Cascade-Chains

Wissenschaftliche/technische/methodische Unsicherheiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Der architektonische Widerspruch zwischen GoBD-Immutabilität und Eventual Consistency hat keine Branchenreferenz — die gefundene Lösung (Idempotency-Deduplizierung + Append-Only-Audit-Trail) ist nicht gegen alle Edge-Cases validiert
• Drei Lösungsansätze für das Cross-Tenant-Freelancer-Problem existieren, keiner ist branchenweit erprobt — jeder erzeugt andere Tradeoffs (Datenschutz vs. Compliance-Vollständigkeit)
• Concurrent Seat Holds über Online- und Offline-Kanäle erfordern Konfliktlösung bei Fahrzeugtausch, wenn ein Fahrer offline Sitze verkauft hat, die durch einen Swap nicht mehr existieren
• Provider-spezifische Error Classification (CPaaS-Anbieter liefern unterschiedliche Fehlersemantiken) für kaskadierte Event-Pipelines ist nicht standardisiert
• CRDT-Projektion: FK-Constraint-Validierung in einem konfliktfreien Merge-Modell (Lieferant gelöscht während CRDT-Dokument bearbeitet wird), GoBD-Attribution bei Merge-Events (mehrere Nutzer → ein Diff), und Bridging von kontinuierlichem CRDT-Zustand zu diskreten Geschäfts-Lifecycles (Entwurf→Veröffentlicht) haben keine Referenzimplementierung

Anlagen

ADR-004, ADR-017, ADR-032, offline-sync-protocol.md, eu-561-compliance-research.md, dispatch-availability-engine.md, notification-pipeline-protocol.md, realtime-strategy.md

Verwertungshorizont / Markteinführung

[TODO]

Verschlagwortung (min. 3 Schlagworte, max. 800 Zeichen)

[TODO — Entwurf:] Offline-Synchronisation, GoBD-Konformität, Eventual Consistency, Datenimmutabilität, Cross-Tenant-Compliance, Concurrent Seat Management, Edge Computing, Event-Driven Architecture, Multi-Tenant SaaS, CRDT, Conflict-free Replicated Data Types, Collaborative Editing, Relationale Projektion

3.3.1 — Tabellarischer Arbeitsplan

Nr.	Titel	Zeitraum	Angestelltes Personal (PM)	Durchführung durch
AP2	Offline-First Sync Protocol mit Immutability-Garantien	[TODO]	[TODO]	Eigenbetrieblich
AP3	Mandantenübergreifende Compliance Engine	[TODO]	[TODO]	Eigenbetrieblich
AP4	Event-Driven Multi-Tenant Architecture	[TODO]	[TODO]	Eigenbetrieblich
AP7a	Event-Driven Broadcast-Resilience	[TODO]	[TODO]	Eigenbetrieblich
AP8	Concurrent Seat Hold Management	[TODO]	[TODO]	Eigenbetrieblich
AP18	CRDT-Based Collaborative Trip Planning	[TODO]	[TODO]	Eigenbetrieblich

---

---

Vorhaben 3 — LLM-Zuverlässigkeit für domänenkritische Prozesse

3.1 — Allgemeine Angaben

Titel des FuE-Vorhabens (max. 200 Zeichen)

[TODO — Entwurf:] KI-gestützte Verarbeitung und Generierung domänenkritischer Inhalte mit Halluzinationsschutz

Start des Vorhabens

[TODO] — frühester AP5-relevanter Commit: 2026-04-04 (docs-assistant RAG-Prototyp)

3.3 — Inhaltliche/Fachliche Angaben

Ziel des Vorhabens / Herausforderung / Wissenslücke (max. 1.500 Zeichen)

[TODO — Rohtext:]

Das Vorhaben erforscht die zuverlässige Orchestrierung nicht-deterministischer Large Language Models (LLMs) für Geschäftsprozesse, bei denen fehlerhafte Ausgaben rechtliche oder finanzielle Konsequenzen haben.

Herausforderung 1 — Dokumentenverarbeitung: Unstrukturierte Reisedokumente heterogener Leistungsträger (Hotels, Fähren, Ausflüge) müssen über LLM-basiertes Tool-Calling in eine strikt relationale ACID-Datenbank überführt werden. Die Eingabedaten haben kein standardisiertes Format. Die Zuverlässigkeit und Halluzinationsrate von LLMs in buchungskritischen Kontexten war bei Projektstart unbekannt. Fehler erzeugen falsche Preise, Passagierdaten oder Steuerwerte mit rechtlichen Konsequenzen.

Herausforderung 2 — Krisennachrichten-Generierung: LLMs generieren Passagiernachrichten in sicherheitskritischen Szenarien (Verspätungen, Ausfälle). Halluzinierte oder fehlerhafte Anweisungen an Hunderte Fahrgäste erzeugen Sicherheitsrisiken. Human-in-the-Loop-Absicherung muss unter Zeitdruck (Krisensituation) funktionieren.

Herausforderung 3 — LLM-Safety: Nicht-deterministische LLM-Ausgaben müssen gegen ein strikt typisiertes Datenbankschema validiert werden, bevor sie ACID-Transaktionen auslösen. Die Anti-Corruption-Layer-Architektur (Valibot-Validierung) fängt strukturelle Fehler ab — semantische Halluzinationen (korrekt formatiert, inhaltlich falsch) erfordern zusätzliche domänenspezifische Plausibilitätsprüfungen.

Herausforderung 4 — Agentic Governance: Einsatz von KI-Agenten als „virtuelle Belegschaft" für ein Solo-Founder-geführtes SaaS-Unternehmen. Fehler in mehrstufigen Agenten-Pipelines (Self-Review → Supervisor → Founder) können kaskadieren.

Herausforderung 5 — Taxonomy-Aware Retrieval: Die Dokumentationsbasis folgt einer PARA-Taxonomie (Projects, Areas, Resources, Archive) mit maschinenlesbarem Frontmatter. Der RAG-Retrieval-Prozess nutzt dieses Signal nicht — autoritative Spezifikationen (resource) und archivierte Entwürfe (archive) erzeugen im Embedding-Raum ähnliche Vektoren, obwohl sie für LLM-Antworten und Agenten-Entscheidungen unterschiedliche Autorität besitzen. Die Interaktion zwischen semantischer Ähnlichkeit und kategorialer Autorität hat keine Referenzimplementierung.

Herausforderung 6 — Domain-State PARA Derivation: Die Plattform-Entitäten besitzen domäneneigene Lifecycle-Zustände (z.B. TourDeparture: DRAFT→PUBLISHED→COMPLETED, FinancialLedger: OPEN→CLOSED), die implizit eine PARA-Taxonomie auf Produkt-Datenebene erzeugen: bevorstehende Abfahrten sind Projects (handlungsrelevant), Reisevorlagen sind Resources (wiederverwendbar), vergangene Abfahrten sind Archive (Kontext). KI-Agenten benötigen diese abgeleitete Taxonomie, um zwischen aktuell handlungsrelevanten und historischen Geschäftsentitäten zu unterscheiden. Drei offene Probleme: duale Kategorie-Zugehörigkeit (ein Template ist gleichzeitig Resource und Container für Projects), Übergangs-Timing (Archive bei COMPLETED, bei Ledger-Close oder bei GoBD-Fristablauf?), und Cross-Entity-PARA-Vererbung (über Bounded-Context-Grenzen hinweg).

Abgrenzung Stand der Technik (max. 500 Zeichen)

[TODO — Rohtext:]

Existierende LLM-Integrationen (ChatGPT-Plugins, LangChain-Demos) operieren auf unstrukturierten Ausgaben ohne ACID-Garantien. Keine Branchenlösung verbindet LLM-Tool-Calling mit domänenkritischen Datenbankmutationen unter Halluzinationsschutz. Die Kombination aus struktureller Validierung (Anti-Corruption Layer) und sicherheitskritischer Inhaltsgenerierung (Krisennachrichten) hat kein Referenzsystem.

Durchgeführte Arbeiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• RAG-Pipeline-Prototyp: Evolution von docs-assistant (Nuxt-Monolith) zu context-engine (Standalone-Server) — zwei verworfene Architekturansätze dokumentiert
• Evaluierung von Embedding-Qualität (Gemini Embeddings) und LLM-Streaming-Architektur (Claude SSE Streaming + Qdrant Vector Search)
• 3-Layer Defense-in-Depth Validierungsarchitektur: PostgreSQL (strukturelle Integrität), Hasura/GraphQL codegen (Netzwerkgrenze), Valibot (LLM-Safety Runtime-Validierung)
• Human-in-the-Loop-Mechanismus für sicherheitskritische Krisennachrichten: LLM-Entwurf → Dispatcher-Review → Freigabe/Ablehnung unter Zeitdruck
• Agentic-Governance-Spezifikation (383 Zeilen): Bounded-Context-scoped Agent Access Control via MCP, dreistufige Review-Pipeline, Blast-Radius-Klassifikation
• MCP-Agent-Bridge-Protokoll für domänenspezifische Tool-Bereitstellung
• PARA-Taxonomie als maschinenlesbare Metadatenebene: 50+ Dokumente mit para_category-Frontmatter, Qdrant-Payload-Integration vorhanden — drei Retrieval-Strategien (harte Filter, Score-Multiplikatoren, Kontextfenster-Ordnung) identifiziert, keine evaluiert
• PARA-Mapping auf Domain-Entitäten: Entity-Lifecycle-Zustände über vier Bounded Contexts analysiert (TourDeparture.status, Booking.status, TourTemplate.status, PriceMatrix.status, FinancialLedger.status, Incident.status) — implizite PARA-Zuordnungsregeln identifiziert, aber weder formalisiert noch in die KI-Pipeline integriert

Wissenschaftliche/technische/methodische Unsicherheiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Halluzinationsrate von LLMs bei buchungskritischen Mutationen (Preise, Passagierdaten, Steuerwerte) ist bei Projektstart unbekannt — falsche Werte erzeugen rechtliche und finanzielle Konsequenzen
• Die Anti-Corruption-Layer-Architektur (Valibot-Validierung) fängt strukturelle Fehler ab, aber semantische Halluzinationen (korrekt formatiert, inhaltlich falsch) erfordern zusätzliche domänenspezifische Plausibilitätsprüfungen, deren Zuverlässigkeit offen ist
• LLM-Halluzinationsrisiko bei sicherheitskritischen Passagiernachrichten — der Human-in-the-Loop-Mechanismus muss unter Zeitdruck (Krisensituation) funktionieren, ohne dass der Dispatcher zum Flaschenhals wird
• Kaskadierende Fehler in Multi-Agent-Pipelines: Wenn ein Agent in Stufe 1 einen subtilen Fehler macht, kann der Supervisor in Stufe 2 diesen nicht zuverlässig erkennen — die Fehlererkennungsrate über mehrere Pipeline-Stufen ist unbekannt
• Taxonomy-Aware Retrieval: Drei offene Strategien (harte PARA-Filter, weiche Score-Multiplikatoren, Kontextfenster-Priorisierung) für die Disambiguierung von Dokumentenautorität — falsche Wahl degradiert LLM-Antwortqualität. Zusätzlich: Agenten benötigen PARA-Signale für Tool-Routing (aktives Projekt vs. archivierte Entscheidung), aber die optimale Signalintegration ist offen
• Domain-State PARA Derivation: Automatische Ableitung von PARA-Kategorien aus Entity-Lifecycle-Zuständen erzeugt drei ungelöste Probleme — (1) duale Zugehörigkeit (Template = Resource + Project-Container), (2) Übergangs-Timing (wann wird Departure zu Archive?), (3) Cross-Entity-Vererbung über Bounded-Context-Grenzen (Booking = Archive, aber verknüpfter PassengerProfile = Area). Zusätzlich: GoBD-Aufbewahrungspflichten verkomplizieren die Archive-Semantik — archivierte Daten haben weiterhin aktive rechtliche Relevanz

Anlagen

ai.md, mcp-agent-bridge.md, validation-strategy.md, docs-hub.md (§Context-Engine, §Knowledge Graph), agentic-led-company-spec.md, ADR-020, notification-pipeline-protocol.md, context-engine/src/indexer/walker.ts, context-engine/src/chat/rag.ts, PRODUCT_domain-model.md (§Entity-Lifecycle-Definitionen), gdpr-strategy.md, workflow-orchestration.md

Verwertungshorizont / Markteinführung

[TODO]

Verschlagwortung (min. 3 Schlagworte, max. 800 Zeichen)

[TODO — Entwurf:] LLM-Orchestrierung, Halluzinationssicherheit, Tool-Calling, ACID-Datenbank, Anti-Corruption-Layer, Human-in-the-Loop, Krisenkommunikation, RAG-Pipeline, Taxonomy-Aware Retrieval, PARA-Metadaten, Dokumentenautorität, Domain-State PARA Derivation, Entity-Lifecycle-Taxonomie, Kontext-Priorisierung, Agentic Governance, MCP

3.3.1 — Tabellarischer Arbeitsplan

Nr.	Titel	Zeitraum	Angestelltes Personal (PM)	Durchführung durch
AP5	KI-gestützte Verarbeitung und Generierung domänenkritischer Inhalte	[TODO]	[TODO]	Eigenbetrieblich
AP5+	Taxonomy-Aware Retrieval [SCOPE-ERWEITERUNG]	[TODO]	[TODO]	Eigenbetrieblich
AP5+	Buchungsmutationen über LLM [SCOPE-ERWEITERUNG]	[TODO]	[TODO]	Eigenbetrieblich
AP9	Agentic Company Governance	[TODO]	[TODO]	Eigenbetrieblich
AP27	Domain-State PARA Derivation für KI-Kontextpriorisierung	[TODO]	[TODO]	Eigenbetrieblich

---

---

Vorhaben 4 — Privacy-Aware Commerce Intelligence

3.1 — Allgemeine Angaben

Titel des FuE-Vorhabens (max. 200 Zeichen)

[TODO — Entwurf:] Datenschutzkonforme Kundendatenanalyse und Empfehlungssysteme in mandantenfähiger Touristik-Software

Start des Vorhabens

[TODO] — frühester relevanter Commit: 2026-04-17 (ADR-021 Customer Intelligence Context)

3.3 — Inhaltliche/Fachliche Angaben

Ziel des Vorhabens / Herausforderung / Wissenslücke (max. 1.500 Zeichen)

[TODO — Rohtext aus AP-Katalog:]

Das Vorhaben erforscht, wie ein mandantenfähiges Touristik-System Kundenverhaltensdaten aggregiert und nutzt — wenn DSGVO-Datensparsamkeit, Multi-Tenant-Isolation und ein cookieloses Web die dafür nötigen Datenflüsse architektonisch unterbinden.

Herausforderung 1 — Privacy vs. 360° Profil: Das System aggregiert Buchungsfrequenz, Lifetime Value und Churn-Risk aus Event-Streams vier unabhängiger Systemkomponenten. Die DSGVO fordert Datensparsamkeit, während Verhaltensanalyse maximale Datenanreicherung erfordert. Die bestehende Tombstone-Architektur löst Löschung operativer Daten — das Verhalten aggregierter Metriken nach Löschkaskaden bleibt offen.

Herausforderung 2 — Consent-Aware ML: Trainierte Empfehlungsmodelle können bei Consent-Widerruf den Beitrag eines Nutzers nicht isoliert „vergessen“. Die Multi-Tenant-Dimension verschärft das: Operator A hat Consent, Operator B nicht — das Modell sieht mandantenübergreifende Daten.

Herausforderung 3 — Dual-Paradigmen-Content: Dynamisch generierte Reise-Landingpages müssen für klassische Crawler und LLM-Retrieval-Systeme gleichzeitig funktionieren — bei widersprüchlichen Anforderungen an Content-Struktur.

Herausforderung 4 — Privacy-Preserving Analytics: Booking-Widgets laufen als iFrames auf Drittseiten. Funnel-Messung ohne Third-Party-Cookies unter sich quartalsweise ändernden Privacy-Sandbox-APIs erfordert eine API-agnostische Architektur.

Abgrenzung Stand der Technik (max. 500 Zeichen)

[TODO — Rohtext:]

Existierende CDPs (Segment, mParticle) bieten keine Multi-Tenant-Isolation für Bus-Touristik-Metriken. Kein Branchensystem kombiniert DSGVO-konforme Löschkaskaden mit event-sourced Behavioral Analytics. Machine Unlearning bei Consent-Widerruf in Multi-Tenant-Recommendation-Systemen fehlt in der Literatur. GEO (Generative Engine Optimization) ist ein aktives Forschungsfeld ohne Touristik-Referenz.

Durchgeführte Arbeiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• ADR-021: Architekturspezifikation des Customer Intelligence Bounded Context als event-sourced Analytics-Domain mit CustomerActivityLog, BehaviorAggregate, CustomerSegment, EngagementScore und RecommendationModel
• GDPR-Strategy: Tombstone-Architektur mit per-Entity-Retention-Windows, Idempotency-Guards und Legal-Hold-Overrides als Basis für die Privacy-Pipeline
• Event-Emission-Vorbereitung: Alle vier operativen Contexts emittieren die für Customer Intelligence benötigten Domain Events (BookingConfirmed, BoardingEventCreated, MessageDelivered, PassengerProfileUpdated)
• Schema.org-Evaluation für TouristTrip/BusTrip-Strukturierung der Commerce-Landingpages

Wissenschaftliche/technische/methodische Unsicherheiten (max. 1.000 Zeichen)

[TODO — Rohtext:]

• Wie verhält sich ein aggregiertes BehaviorAggregate nach einer GDPR-Löschkaskade? Ein gelöschter Passagier beeinflusst weiterhin Kohorten-Statistiken und trainierte Modelle — die analytische Nutzbarkeit nach Löschung bleibt offen
• Machine Unlearning bei Multi-Tenant-Consent: Der Beitrag eines einzelnen Nutzers in einem trainierten Recommendation-Modell ist nicht isolierbar. Differentielles Privacy, k-Anonymität oder föderiertes Lernen als mögliche Lösungsansätze — keiner im Bus-Touristik-Kontext validiert
• Dual-Paradigmen-Indizierung (Crawler vs. LLM-Retrieval) für dynamisch generierte Reise-Landingpages hat keine Branchenreferenz
• Privacy-Sandbox-APIs (Topics, Attribution Reporting) ändern sich quartalsweise — die Widget-Analytics-Architektur muss API-agnostisch bleiben, was die Stabilität der Messpipeline gefährdet

Anlagen

ADR-021, gdpr-strategy.md, PRODUCT_differentiators-10-percent.md §1

Verwertungshorizont / Markteinführung

[TODO]

Verschlagwortung (min. 3 Schlagworte, max. 800 Zeichen)

[TODO — Entwurf:] Customer Data Platform, DSGVO-Konformität, Datensparsamkeit, Machine Unlearning, Consent Management, Recommendation Engine, Multi-Tenant Analytics, Generative Engine Optimization, Privacy Sandbox, Behavioral Analytics, Event Sourcing, Bus-Touristik

3.3.1 — Tabellarischer Arbeitsplan

Nr.	Titel	Zeitraum	Angestelltes Personal (PM)	Durchführung durch
AP20	Privacy-First 360° Customer Profile	[TODO]	[TODO]	Eigenbetrieblich
AP21	AI-SEO / Generative Engine Optimization	[TODO]	[TODO]	Eigenbetrieblich
AP22	Consent-Aware Recommendation Engine	[TODO]	[TODO]	Eigenbetrieblich
AP23	Privacy-Preserving Conversion Analytics	[TODO]	[TODO]	Eigenbetrieblich