Idea: Customer Intelligence — Additional AP Candidates

Origin: Gap analysis of funding-work-packages.md against the Customer Intelligence domain model (domain-customer-intelligence.md, ADR-021). The existing APs (AP20, AP22, AP25) cover BehaviorAggregate, RecommendationModel, EngagementScore, and ChannelPreference — but leave CustomerSegment, CustomerActivityLog replay mechanics, and cross-tenant anomaly detection unaddressed.

---

Coverage Map — Existing vs. Proposed APs

CI Entity	Existing AP	Proposed AP
BehaviorAggregate	AP20 (Privacy-First 360° Profile)	—
RecommendationModel	AP22 (Consent-Aware Recommendation Engine)	—
EngagementScore	AP25 (Adaptive Multi-Channel Feedback)	—
ChannelPreference	AP25 (Adaptive Multi-Channel Feedback)	—
CustomerSegment	—	AP-CS-1 (Dynamic Cohort Segmentation)
CustomerActivityLog (replay)	—	AP-CS-2 (Zero-Downtime Projection Replay)
Cross-tenant booking patterns	—	AP-CS-3 (Federated Anomaly Detection)

---

AP-CS-1 — Natural-Language Dynamic Cohort Segmentation ⚪

• Forschungsfrage: Wie übersetzt ein System nicht-deterministische, natürlichsprachliche Operatoranfragen (z.B. „Finde alle wertvollen Kunden, die die Nordsee bevorzugen, aber seit 2 Jahren nicht mehr gebucht haben") in deterministische, datenschutzkonforme Segmentierungsabfragen über einem append-only Event Stream (CustomerActivityLog) — wenn die Abfrage gleichzeitig Multi-Tenant-Isolation einhalten, DSGVO-Consent-Filter anwenden und über vier Bounded-Context-Grenzen hinweg event-sourced Daten aggregieren muss?
• Neuartigkeit: Standard-CDPs (Segment, mParticle) verwenden rigide Query-Builder mit vordefinierten Filterkombinationen. Die Brücke zwischen LLM-Intent-Parsing und hochstrukturierten, event-sourced DB-Queries über eine mandantenübergreifende Grenze — bei gleichzeitiger on-the-fly DSGVO-Constraint-Enforcing — hat keine Referenzimplementierung. Drei offene Forschungsprobleme:
  1. Semantische Disambiguierung: Natürliche Sprache ist mehrdeutig („wertvoll" = Lifetime Revenue? Buchungsfrequenz? Beides?). Das System muss domänenspezifische Semantik (BehaviorAggregate-Felder) auf natürliche Sprache mappen, ohne falsche Segmente zu erzeugen.
  2. Query-Sicherheit: LLM-generierte Datenbankabfragen dürfen keine Tenant-Isolation durchbrechen. Ein Injection-resistentes Zwischenformat (z.B. AST → validierte SQL-Projektion) ist erforderlich.
  3. Temporale Abfragen: „seit 2 Jahren nicht gebucht" erfordert Negationsabfragen über ein append-only Event Log — semantisch korrekte Negation über Event Sourcing ist ein bekanntes Erschwernis.
• Belege: ADR-021 (CustomerSegment als Operator-definierbare Kohortendefinition), domain-customer-intelligence.md §Planned Entities, AP5 (LLM-Orchestrierung als architektonische Basis), AP20 (BehaviorAggregate als Datenquelle)
• Stundenaufwand: ~140h (Spike: 30h, Intent-Parser + AST-Generator: 50h, Tenant-Isolation-Enforcement: 30h, Temporale Negationsabfragen: 30h)

NOTE

Vorhaben-4-Integration: AP-CS-1 stärkt die V4-Klammer „Privacy-Aware Commerce Intelligence", indem es den operativen Zugang zu CustomerSegment erforscht. Es verbindet V3 (LLM-Zuverlässigkeit / AP5-Intent-Parsing) mit V4 (datenschutzkonforme Kundenanalyse). Die Query-Sicherheits-Dimension (LLM → mandantenisolierte SQL) ist ein eigenständiges Forschungsproblem mit BSFZ-relevanter Unwägbarkeit.

---

AP-CS-2 — Zero-Downtime Projection Replay für ML Feature Engineering ⚪

• Forschungsfrage: Wie replayed und re-materialisiert ein System effizient Millionen von Events aus dem CustomerActivityLog in neue BehaviorAggregate-Metriken, wenn sich das Datenschema evolutionär ändert (z.B. ein neuer Event-Typ AncillaryPurchased wird hinzugefügt) — ohne die PostgreSQL-Datenbank zu sperren, die strikten Cardinality-Budgets (ADR-027: Hardcap ≤80.000 active series) zu verletzen oder die laufende Echtzeitanalytik zu beeinträchtigen?
• Neuartigkeit: Event-Sourcing-Projection-Replays sind ein bekanntes Engineering-Pattern. Die Kombination aus folgenden Constraints erzeugt die Forschungsneuartigkeit:
  1. Live-System-Invariante: Das Replay läuft parallel zum Live-System. Neue Events treffen während des Replays ein und müssen ohne Datenverlust oder Doppelzählung integriert werden (Exactly-Once-Semantik über partielle Replays).
  2. Multi-Tenant-Cardinality: Jeder Tenant erzeugt eigene BehaviorAggregate-Projektionen. Bei 4.000 potenziellen Tenants × N Metriken pro Tenant sprengt ein naives Replay die Cardinality-Budgets. Das System braucht ein inkrementelles, tenant-aware Replay-Scheduling.
  3. ML-Feature-Konsistenz: Trainierte Recommendation-Models (AP22) basieren auf den alten Projektionen. Ein Replay ändert die Feature-Basis retroaktiv — das Modell muss entweder mittrainiert oder die Drift zwischen alter und neuer Projektion explizit gemanagt werden.
  4. GoBD-Audit-Trail: Replay-generierte Änderungen an materialisierten Aggregaten müssen im Audit-Trail als „Replay-Korrektur" (nicht als neue Geschäftsaktivität) markiert werden, um GoBD-Konformität zu wahren.
• Belege: ADR-021 (CustomerActivityLog als event-sourced Ledger), ADR-027 (Cardinality-Budget-Contract), AP20 (BehaviorAggregate-Schema-Evolution), AP22 (RecommendationModel-Feature-Abhängigkeit), domain-customer-intelligence.md §BehaviorAggregate
• Stundenaufwand: ~130h (Inkrementelles Replay-Framework: 40h, Exactly-Once-Semantik bei Live-Parallel-Betrieb: 35h, Cardinality-Budget-Enforcement: 25h, ML-Feature-Drift-Management: 30h)

WARNING

BSFZ-Ablehnungsrisiko: 🟡. Ein Gutachter könnte Projection Replay als Standard-Event-Sourcing abtun. Die Argumentation muss auf die Kombination der vier Constraints fokussieren (Live-Parallel-Betrieb + Multi-Tenant-Cardinality + ML-Feature-Drift + GoBD-Audit), nicht auf den Replay-Mechanismus selbst. Einzeln betrachtet ist jeder Constraint lösbar — die Interaktion erzeugt die Unwägbarkeit.

---

AP-CS-3 — Federated Anomaly Detection in Temporal Booking Patterns ⚪

• Forschungsfrage: Wie erkennt ein automatisiertes System Anomalien in temporalen Buchungsmustern (z.B. massenhafte simultane Seat Holds, ungewöhnliche Stornierungswellen, verdächtige Checkout-Abbruch-Muster) über mehrere isolierte Mandanten hinweg — wenn die Multi-Tenant-Architektur (Hasura RBAC + Postgres RLS) mandantenübergreifende Datenaggregation strikt verbietet, die statistische Baseline aber mandantenübergreifende Vergleichsdaten erfordert, um saisonale, routen- und operatorspezifische Normalverteilungen zu unterscheiden?
• Neuartigkeit: Anomaly Detection in Buchungssystemen ist branchenüblich für einzelne Mandanten (Stripe Radar, Mollie Risk Engine). Das Multi-Tenant-Isolations-Problem erzeugt die Forschungsneuartigkeit:
  1. Privacy-Preserving Federated Approach: Um mandantenübergreifende statistische Signifikanz zu erreichen, ohne Rohdaten zu mischen, muss das System aggregierte, anonymisierte Muster-Signaturen (z.B. „Stornierungsrate pro Wochentag, normalisiert auf Buchungsvolumen") über Tenant-Grenzen hinweg vergleichen — ein Federated-Learning- oder Differential-Privacy-Ansatz ohne Branchenreferenz in der Bus-Touristik.
  2. Domänenspezifische Baseline: Die „Normalität" variiert extrem: Ein Nordsee-Operator hat saisonale Buchungsspitzen im Mai, ein Alpen-Operator im Dezember. Gruppenreisen erzeugen natürliche „massenhafte simultane Holds" — das System muss domain-aware Anomalie-Schwellwerte pro Operator, Route und Saison lernen, ohne ausreichende historische Daten in der Frühphase (Cold-Start-Problem).
  3. Real-Time vs. Batch: Seat-Hold-Manipulation (AP8) erfordert Echtzeit-Erkennung (Sekunden), Stornierungswellen-Erkennung erlaubt Batch-Analyse (Stunden). Das System braucht eine duale Pipeline mit unterschiedlichen Latenz- und Genauigkeits-Tradeoffs.
  4. False-Positive-Kosten: Ein fälschlich blockierter Checkout kostet direkt Umsatz. Die Schwellwert-Kalibrierung hat asymmetrische Fehlerkosten und erfordert domänenspezifische Precision/Recall-Optimierung.
• Belege: ADR-004 (Tenant-Isolation-Strategie: Hasura RBAC + Postgres RLS), ADR-021 (CustomerActivityLog als Datenquelle), AP8 (Concurrent Seat Hold Management als Echtzeit-Anomalie-Trigger), AP20 (BehaviorAggregate liefert Baseline-Metriken), gdpr-strategy.md (Tombstone-Architektur beeinflusst historische Baseline-Stabilität)
• Stundenaufwand: ~160h (Federated Aggregation Framework: 50h, Domänenspezifische Baseline-Engine: 40h, Duale Real-Time/Batch-Pipeline: 40h, Asymmetrische Schwellwert-Kalibrierung: 30h)

IMPORTANT

Vorhaben-4-Integration: AP-CS-3 stärkt V4 substanziell, da es die „Commerce Intelligence"-Dimension über reine Empfehlungen und Profile hinaus auf operative Sicherheit erweitert. Die Federated-Privacy-Komponente verbindet sich direkt mit AP20 (DSGVO-Spannungsfeld) und AP22 (Consent-Aware ML). Gleichzeitig erzeugt die Echtzeit-Dimension eine Brücke zu V2 (AP8 Seat Holds), was die Vorhaben-übergreifende Kohärenz stärkt.

---

Stundenübersicht — Neue Kandidaten

AP	Titel	Stunden	Fokus-Entity
AP-CS-1	Natural-Language Dynamic Cohort Segmentation	~140h	CustomerSegment
AP-CS-2	Zero-Downtime Projection Replay für ML Feature Engineering	~130h	CustomerActivityLog
AP-CS-3	Federated Anomaly Detection in Temporal Booking Patterns	~160h	Cross-tenant patterns
Summe		~430h

NOTE

Diese drei Kandidaten erweitern Vorhaben 4 um 430h auf insgesamt ~1.070h (640h bestehende AP20–AP23 + 430h neue Kandidaten). Sie bleiben in der Folgejahres-Pipeline und dienen als Argumentationsgrundlage für den Steuerberater. Vor Übernahme in den AP-Katalog (funding-work-packages.md) müssen die APs formal nummeriert und die BSFZ-Forschungsfragen gegen die Frascati-Kriterien validiert werden.

Next Steps

1. Steuerberater-Review: Kandidaten in die Beratungssitzung einbringen, um die Förderfähigkeit und das Gesamtvolumen V4 zu bewerten.
2. Formale Nummerierung: Bei Annahme erhalten die APs fortlaufende Nummern (AP29, AP30, AP31) und werden in funding-work-packages.md integriert.
3. Codebasis-Validierung: Alle drei APs stehen auf 🟡 oder ⚪ — vor Antragstellung muss der Bezug zur existierenden Codebasis geprüft werden.