BSFZ Ablehnungsrisiken — Wackelkandidaten & Verteidigung
Zweck: Projektspezifische Risiken pro AP und vorbereitete Verteidigungstexte. Generische FZulG-Argumentationshilfen liegen beim Berater.
Bezugsdokumente:
bsfz-strategie.md,funding-application-plan.md,funding-work-packages.md.
Schnelltest pro AP: Liegt die Schwierigkeit darin, was das System tun soll (Anforderung) oder darin, wie es technisch zu lösen ist (Lösungsweg)? Nur das Zweite ist förderfähig.
Wackelkandidat 1: AP1 — Tax Engine
Das System muss Preise berechnen, obwohl die Daten für die korrekte Steuerberechnung noch nicht existieren. Die Margensteuer 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.
ADR-012 dokumentiert, dass der erste Lösungsversuch innerhalb des Projekts (geschätzte Per-Variante-Steuer aus total_net_cost / break_even_pax) mathematisch falsch war — das Ergebnis hatte keine Grundlage im Steuerrecht. Nachweislich gescheiterter Ansatz.
Untergewichtete Forschungselemente:
- § 25 Abs. 2 Drittlands-Split (
tax-engine.mdZ.88-119): ratio-basierter Algorithmus, der die Marge in steuerpflichtigen EU-Anteil und steuerfreien Drittlands-Anteil aufteilt. Algorithmisch nicht-trivial (Negativmargen-Clamping, Split-Ratio-Berechnung, Netto-Rückrechnung). - § 25 Abs. 5 GoBD-Persistenz (
tax-engine.mdZ.131-140): Vier Werte müssen als unveränderliche DB-Spalten persistiert werden, nicht on-the-fly berechnet. Schneidet quer durch Schema-Design, Migration-Strategy und API-Layer. - ADR-015 Mixed-Strategy: Eine Abfahrt mit Tour-Marge und Onboard-Sales erzeugt zwei steuerlich getrennte Einnahmenströme. Der 1:N-Wechsel der TaxLedgerEntry-Kardinalität ist das Ergebnis eines Domain-Spannungsfelds, das erst während der Forschung entdeckt wurde.
CAUTION
Stundenüberschätzung. Von den 400h AP1-Stunden sind ~150–200h echte F&E (Strategy-Resolution, Drittlands-Split, Deferral-Architektur, GoBD-Persistenz-Design). Die restlichen ~200–250h sind Standard-Engineering (DATEV-Mapping, Invoice-Rendering, Valibot-Validierung). Empfehlung: Im Antrag proaktiv aufteilen.
NOTE
Phase-3-FinancialLedger ist bewusst offen. ADR-012 verschiebt die Tax-Decomposition in den FinancialLedger (Phase 3). Die nicht-validierte Deferral-Lösung belegt laufende Unwägbarkeit — das FZulG fördert den Forschungsprozess, nicht abgeschlossene Ergebnisse. Im Antragstext: „Die Deferral-Entscheidung (ADR-012) ist getroffen, aber die Pipeline ist noch nicht validiert — genau diese Unsicherheit macht den Forschungsbedarf aus."
IMPORTANT
ADR-009 nicht als Forschungsbeleg. ADR-009 (BookingConfirmed = DEPOSIT_PAID) ist juristische Auslegung (§ 651a BGB), keine technische Innovation. Nur als Beleg für Planmäßigkeit verwenden.
Empfohlene Argumentation
Nicht: „Wir haben die Margenbesteuerung automatisiert."
Stattdessen: „Wir mussten eine Preis-Pipeline entwerfen, die korrekte Verkaufspreise produziert, obwohl die für die Steuerberechnung erforderlichen Eingabedaten zum Zeitpunkt der Preisberechnung physisch nicht verfügbar sind. Unser erster Lösungsansatz (ADR-012) erwies sich als mathematisch fehlerhaft. Die gefundene Lösung erforderte eine fundamentale Trennung der Pipeline in eine Vor-Reise- und eine Nach-Reise-Phase — einschließlich eines ratio-basierten Drittlands-Margen-Splits und eines 1:N TaxLedgerEntry-Modells für Mixed-Strategy-Departures."
Wackelkandidat 2: AP3 — EU-561 Compliance Engine
EU-561 gilt pro Fahrer, nicht pro Betreiber. Ein Freelance-Fahrer arbeitet für mehrere Busunternehmen und hat eine einzige gesetzliche Ruhezeitbilanz. Das Multi-Tenant-Datenmodell isoliert aber Daten strikt pro Betreiber (RLS + Hasura RBAC, ADR-004). Das System kann die Compliance-Frage nicht beantworten, weil es die Hälfte der relevanten Daten nicht sieht.
Drei mögliche Lösungen, keine bei Projektstart ausgewählt:
| Option | Tradeoff |
|---|---|
| Ignorieren (Limitation dokumentieren) | Rechtliches Risiko für den Betreiber |
| Fahrer-Selbstdeklaration | Manuelle Eingabe, fehlerbehaftet, nicht verifizierbar |
| Tachograph-Datenaustausch | Komplexe IoT-Integration, Datenschutzprobleme bei mandantenübergreifendem Datenaustausch |
Echte architektonische Spannung: Datenisolation (Sicherheit) vs. Datenaggregation (Compliance). Bei Projektstart offen, dokumentiert durch 16 ungelöste Checkboxen im Research-Dokument.
Empfohlene Argumentation
Nicht: „Wir entwickeln ein System zur Überwachung der EU-561 Lenk- und Ruhezeiten."
Stattdessen: „Wir erforschen, wie compliance-kritische Daten über Mandantengrenzen hinweg aggregiert werden können, ohne die architektonischen Datenisolationsgarantien (Row-Level Security, RBAC) aufzubrechen — für den Fall, dass ein Fahrer als Freelancer für mehrere Betreiber arbeitet und die gesetzliche Ruhezeitbilanz mandantenübergreifend ist. Bei Projektstart existierten drei Lösungsansätze mit jeweils unklaren Tradeoffs; keiner wurde in der Branche bisher umgesetzt."
Wackelkandidat 3: AP6 — Kalkulations-Engine
Die Trennung von Costing und Pricing als unabhängige Entities mit eigenen Lifecycles (ADR-006) war bei Projektstart nicht offensichtlich — der erste Entwurf hatte ein kombiniertes Entity mit einem price_overrides JSONB-Hack, der die Immutability-Garantie verletzte. ADR-006 dokumentiert, warum das gescheitert ist.
IMPORTANT
Empfehlung: AP6 nicht eigenständig beantragen, sondern als Teil von Vorhaben 1 (mit AP1). Die Kalkulations-Engine liefert die Eingabedaten für die Tax-Pipeline — Forschungsthema dann „Preis-Pipeline unter unvollständiger Datenlage", nicht „Kalkulation".
Wackelkandidat 4: AP21 — AI-SEO / Generative Engine Optimization
Die Content-Pipeline generiert Reise-Landingpages dynamisch aus strukturierten Tourdaten (CostingSheet → PriceMatrix → semantisch angereicherte Seite). Zwei Retrieval-Systeme konsumieren sie gleichzeitig:
- Klassische Crawler (Googlebot): erwarten HTML-Struktur, Schema.org-Annotation, flache Content-Hierarchie
- LLM-Retrieval (AI Overviews, Perplexity): erwarten zitierbare Absätze, faktische Dichte, Quellenattribution
Die Paradigmen widersprechen sich: Schema.org-Markup (maschinenlesbar, nicht-textuell) ist für LLMs irrelevant; LLM-optimierte Textdichte (lange, autoritative Absätze) schadet der Crawler-Indexierung. GEO (Generative Engine Optimization) ist ein akademisch aktives Feld (erste SIGIR-Beiträge 2023). Branchenspezifische Schema.org-Erweiterungen (BusTrip, TouristTrip) existieren, aber ihre Wirkung in LLM-Retrieval-Kontexten hat niemand getestet.
Empfohlene Argumentation
Nicht: „Wir optimieren die SEO unserer Operatoren."
Stattdessen: „Wir erforschen, wie eine automatische Content-Pipeline aus strukturierten Geschäftsdaten (Preismatrizen, Tourpläne, Lieferanten) Webseiten generiert, die von zwei fundamental verschiedenen Retrieval-Paradigmen (crawler-basiert und LLM-basiert) korrekt konsumiert werden — wenn beide Paradigmen widersprüchliche Anforderungen an Content-Struktur stellen und keine Branchenreferenz für die Kombination existiert."
Wackelkandidat 5: AP23 — Privacy-Preserving Conversion Analytics
Das Busflow Booking-Widget läuft als iFrame auf Drittseiten (Operator-Websites). Drei gleichzeitige technische Constraints:
- Same-Origin-Policy / Storage-Partitioning: Der Browser isoliert den Widget-Speicher vom Host. Third-Party-Cookies blockiert. Keine Cross-Site-Identität möglich.
- Privacy-Sandbox-Instabilität: Chrome's Topics API, Attribution Reporting API und Protected Audience API ändern sich quartalsweise. Safari und Firefox implementieren keine davon — die Architektur muss browser-agnostisch bleiben.
- Multi-Tenant-Isolation: Jeder Operator hat ein eigenes Widget. Conversion-Pfade (Impression auf Operator-A.de → Checkout auf busflow.app) kreuzen Tenant-Grenzen.
Kein existierendes Analytics-Framework löst die Kombination aus iFrame-Embedding + Multi-Tenant-Isolation + API-Agnostizismus.
Empfohlene Argumentation
Nicht: „Wir optimieren die Conversion-Rate unserer Booking-Widgets."
Stattdessen: „Wir erforschen, wie man Nutzerinteraktionen in einem eingebetteten Widget (iFrame) datenschutzkonform über Vertrauensgrenzen korreliert — wenn Third-Party-Cookies blockiert sind, Privacy-Sandbox-APIs sich quartalsweise ändern, und die Multi-Tenant-Architektur Tenant-übergreifende Datenflüsse architektonisch verbietet."
Risikoübersicht aller APs
| AP | Risiko | Stärkstes Argument | Schwächstes Argument |
|---|---|---|---|
| AP1 — Tax Engine | 🔴 Hoch | ADR-012: gescheiterter Erstversuch + § 25 Abs. 2 Algorithmus | Phase-3 offen (aber: belegt laufende Unwägbarkeit) |
| AP3 — EU-561 | 🔴 Hoch | Cross-Tenant-Paradox: Isolation vs. Aggregation | Sliding-Window und ETL sind Standard |
| AP6 — Kalkulation | 🟡 Mittel | ADR-006: gescheiterter Erstansatz (JSONB-Hack) | Isoliert dünn — hängt vollständig an AP1-Verzahnung |
| AP7a — Broadcast-Resilience | 🟡 Mittel | Provider-spezifische Error Classification für Event-Cascades | AP7 aufgelöst — Standard-Infra (40h) nicht beantragt |
| AP10 — FX Risk | 🟡 Mittel | Touristik-spezifisches Hedging mit drei Lifecycle-Phasen | FX-Hedging ist Finance-Standard |
| AP12 — Telemetry | 🟡 Mittel | Cardinality-Tradeoff TimescaleDB ↔ Hasura-Subscriptions | Time-Series-Ingestion ist Standard-Topic |
| AP13 — Border Manifests | 🟡 Mittel | Routenabhängige dynamische Compliance-Konfiguration | Klingt nach Template-Management |
| AP15 — Crew Solver | 🟡 Mittel | Multi-Constraint-Solver mit EU-561-Awareness | Solo betrachtet bekanntes CSP-Problem |
| AP16 — Mobile OCR | 🟡 Mittel | Konfidenz-Loop mit Dispatcher-Verification-Workflow | OCR ist Standard-Technologie |
| AP17 — Reseller Settlement | 🟡 Mittel | Konditionale Clawback-Semantiken über Booking-State-Machine | Mollie liefert Primitives |
| AP19 — Passenger Offline (CBOR/CWT/COSE) | 🟡 Mittel | State-Reconciliation zwischen mutablen Wallet-Pässen und immutablen Papier-Ausdrucken (Analog-Fallback) | CWT-JS-Ökosystem dünn; kein ADR/Spike |
| AP2 — Offline Sync | 🟢 Niedrig | GoBD-Immutability vs. Eventual Consistency | — |
| AP4 — Multi-Tenant | 🟢 Niedrig | Polymorphe Audit Trails + Saga Correlation | Dual-Layer Isolation allein ist bekannt |
| AP5 — AI/IDP | 🟢 Niedrig | LLM → ACID-Datenbank Zuverlässigkeit | — |
| AP8 — Seat Map | 🟢 Niedrig | Concurrent Hold über Online/Offline-Kanäle | — |
| AP9 — Agentic Gov. | 🟢 Niedrig | Kein vergleichbares System existiert | — |
| AP11 — Seat Re-Mapping | 🟢 Niedrig | CSP mit Bus-spezifischen Heuristiken (Familien, Barrierefreiheit) | — |
| AP14 — Dispatch Conflict | 🟢 Niedrig | Optimistic-UI-Reconciliation mit Domain-Event-Replay | — |
| AP18 — CRDT Planning | 🟢 Niedrig | CRDT in Multi-Tenant-Architektur; FK-Validierung; GoBD-Audit über CRDT-DAG; Versionierungslifecycle | ADR-032 dokumentiert Technologieentscheidung, Spike ausstehend |
| AP20 — 360° Profile | 🟡 Mittel | GDPR ↔ Analytics-Spannung, ADR-021; Tombstone-Verhalten nach Löschkaskade offen | Noch keine Implementierung |
| AP21 — AI-SEO | 🟡 Mittel | Dual-Paradigmen-Indizierung (Crawler vs. LLM-Retrieval), aktives Forschungsfeld | „SEO" im Titel → Marketing-Wahrnehmung |
| AP22 — Recommendations | 🟡 Mittel | Machine Unlearning bei Multi-Tenant-Consent; Literatur adressiert Multi-Tenant nicht | Noch keine Implementierung |
| AP23 — Conversion Analytics | 🟡 Mittel | iFrame + Privacy-Sandbox-Instabilität + Multi-Tenant-Isolation | „Conversion-Funnel" → Marketing-Wahrnehmung |
| AP24 — Field Media Pipeline | 🗃️ Backlog | On-Device ML im PWA-Kontext + DSGVO-Consent inline | Zurückgestellt — ohne On-Device-ML-Feasibility-Spike nicht beantragbar |
| AP25 — Adaptive Feedback | 🟡 Mittel | Adaptive Channel-Routing + Domain Sentiment Analysis | Folgejahres-Pipeline; Risiko: kann nach Geschäftsregel-Konfiguration klingen |
| AP26 — Lifecycle Communication | 🟡–🔴 Mittel-Hoch | Cross-Context Event-Orchestrierung über 4 Bounded Contexts | Folgejahres-Pipeline; Cross-Context-Orchestrierung vs. Standard-Workflow-Engine (n8n/Temporal) muss klar abgegrenzt werden |
Behandlung der Kandidaten-APs (AP10–AP19)
Vier Argumentationsmuster decken alle Kandidaten ab — Übertragungen der Patterns aus den Wackelkandidaten oben.
Muster A — Cross-Domain-Spannung (analog AP1, AP3)
Standardtechniken im Domain-spezifischen Spannungsfeld. Die Spannung selbst ist das Forschungselement.
- AP10 (FX Risk): Spannung = Verkauf/Lieferantenzahlung/Endabrechnung in unterschiedlichen Währungs-Lifecycles. Nicht als „FX-Hedging" — als „Risikomodellierung über zeitlich entkoppelte Cashflows in Touristik-Buchungen".
- AP13 (Border Manifests): Spannung = Multi-Country-Compliance bei dynamischer Routenkonfiguration. Nicht als „Manifest-Generator" — als „routenabhängige Compliance-Engine für Mehrländer-Touren".
- AP17 (Reseller Settlement): Spannung = Refund-Clawbacks, nachdem Geld bereits an N Parteien ausgekehrt wurde. Fokus auf Booking-State-Machine-Integration, nicht auf Mollie-API.
Muster B — Konkrete technische Hürde (analog AP2, AP8)
Klar benennbarer technischer Engpass mit messbarer Schwelle.
- AP12 (Telemetry): Cardinality-Problem konkret beziffern (~30M Datenpunkte/Tag bei 100 Fahrzeugen). Nicht als „GPS-Tracking" — als „Hochfrequenz-Ingestion mit Echtzeit-Subscription-Reaktivität".
- AP14 (Dispatch Conflict): Konkrete Race-Condition zeigen (mehrere Dispatcher klicken parallel auf gleichen Fahrer). Optimistic-UI-Reconciliation als Lösung, nicht „besseres Locking".
- AP19 (Passenger Offline — CBOR/CWT/COSE): IETF-standardisierte Credentials für mutationsgewahre Buchungsvalidierung im Offline-Kontext. Entkräftung der „Wallet-Bedingung": Standard-Wallets sind nur der UX-Delivery-Mechanismus für Smartphone-Nutzer. Die Forschungsherausforderung ist die Schnittstelle Digital/Analog: State-Reconciliation immutabler Papiertickets vs. mutabler Wallet-Pässe, Double-Offline-Konsistenzproblem.
Muster C — Algorithmik mit Domain-Heuristiken (analog AP6)
Erkennbares CS-Problem mit spezifischer Domain-Anpassung.
- AP11 (Seat Re-Mapping): CSP mit Bus-Layout-Heuristiken (Familiengruppen, Barrierefreiheit). Explizit von Airline-Algorithmen abgrenzen.
- AP15 (Crew Solver): Als Erweiterung von AP3 beantragen, nicht eigenständig — die EU-561-Integration ist das Forschungselement, nicht der CSP-Solver an sich. Standalone-Risiko: 🔴 Hoch; integriert: 🟢 Niedrig.
- AP16 (Mobile OCR): Pipeline mit Verification-Loop ist neuartig, nicht die OCR-Engine selbst. Konfidenz-basierte State-Machine (PENDING → PARSED → VERIFIED → REJECTED → replaces) als Kernargument.
Muster D — Privacy-Spannung (Commerce-APs, Vorhaben 4)
Standardtechniken (CDP, Recommendations, Analytics, SEO) im Spannungsfeld mit DSGVO-Constraints. Der Zielkonflikt ist das Forschungselement.
- AP20 (360° Profile): Spannung = Datensparsamkeit (GDPR Art. 5(1)(c)) vs. vollständige Verhaltensaggregation über 4 Bounded Contexts. Nicht als „Customer Analytics" — als „privacy-konforme Verhaltensaggregation über mandantenisolierte Event-Streams mit ungeklärtem Tombstone-Verhalten".
- AP22 (Recommendations): Spannung = Consent-Widerruf vs. Modell-Integrität. Nicht als „Empfehlungssystem" — als „Machine Unlearning unter Multi-Tenant-Consent-Constraints".
- AP23 (Conversion Analytics): Spannung = Cross-Origin-Messung vs. Privacy-Sandbox-Instabilität. Nicht als „Conversion-Tracking" — als „datenschutzkonforme Ereigniskorrelation über Vertrauensgrenzen in eingebetteten Widgets".
- AP21 (AI-SEO): Folgt Muster B (konkrete technische Hürde) statt Privacy-Spannung — die Hürde ist das Dual-Paradigmen-Problem.
Kernargument für alle Privacy-Spannungs-APs: „Wie erreicht man X, ohne die Datenschutzarchitektur aufzubrechen — und welche Qualitätsverluste entstehen durch Privacy-Preserving-Methoden im Vergleich zu einer naiven Implementierung?"
Sonderfall AP18 (CRDT)
ADR-032 dokumentiert die Technologieentscheidung (Loro primär, Yjs Fallback) und eine Dual-Layer-Architektur (CRDT-Kollaborationsschicht + relationale Projektion). Hasura-LWW bleibt als Produkt-Fallback — die CRDT-Architektur ist ein explizites Forschungsrisiko.
Frascati-Evidenz:
- Neuartigkeit: Kein CRDT-Framework adressiert Multi-Tenant-Isolation + relationale Projektion mit FK-Validierung + GoBD-Audit-Trail. Kleppmann et al. (IEEE TPDS 2022) löst Tree-Move-Operationen, nicht die SaaS-Integration.
- Unwägbarkeit: Fünf konkrete Risiken: Projektionsservice (Write-Amplification, Drift), FK-Constraints im konfliktfreien Merge, GoBD-Attribution bei Merge-Events, Versionierungslifecycle (CRDT → diskret), Semantische Konflikt-UX.
- Planmäßigkeit: 4-Phasen-Plan (Spike → Integration → GoBD → UX), 220h Budget, Phase-1-Entscheidungspunkt für Loro/Yjs.
NOTE
Code-Forensik oder bestehende Implementierungsbelege sind für AP18 nicht erforderlich — zukünftiges Forschungsvorhaben. ADR-032 erfüllt die Dokumentationsvoraussetzung. Gleiches gilt sinngemäß für AP19, AP24 und AP26.