BSFZ Ablehnungsrisiken — Wackelkandidaten & Verteidigung
Zweck: Welche APs hat die BSFZ am ehesten als „Fleißarbeit" ab, und wie argumentiert man dagegen?
Bezugsdokumente:
STRATEGY_public-funding.md(Vorhaben-Strategie),funding-application-plan.md(Beantragungsplan),funding-work-packages.md(AP-Katalog).
Das Kernrisiko
Die BSFZ lehnt Projekte ab, die nach betriebswirtschaftlicher Umsetzung aussehen — also: Gesetze lesen, Regeln in Code schreiben, fertig. Wenn der Gutachter denkt „Ein guter Entwickler mit dem Gesetzestext löst das in zwei Wochen", ist das Arbeitspaket nicht förderfähig.
Zwei typische Fehler in IT-Anträgen:
- Gesetzesreferenz im Titel → klingt nach Regelimplementierung
- Feature-Beschreibung statt Hindernisbeschreibung → klingt nach Produktentwicklung
Schnelltest für jeden AP
Liegt die Schwierigkeit darin, was das System tun soll (= Anforderung verstehen)? Oder darin, wie man es technisch löst (= Lösungsweg finden)?
Nur das Zweite ist förderfähig.
Wackelkandidat 1: AP1 — Tax Engine
Warum die BSFZ ablehnen könnte
Der AP behandelt Margenbesteuerung. Auch ohne Gesetzesreferenz im Titel liest der Gutachter „Steuerberechnung" und denkt: „Steuerregeln implementieren." Das ist Domänenwissen → Code, keine Forschung.
Was tatsächlich schwer ist (und was nicht)
Nicht schwer (Standard-Engineering):
- Strategy-Pattern für verschiedene Steuerregime — bekanntes GoF-Pattern
- Immutable-Append-Versionierung auf PriceMatrix — bekannt aus Event Sourcing
- DATEV-Mapping, Mollie-Integration, Invoice-Rendering, Valibot-Validierung — Implementierungsarbeit
Tatsächlich schwer (dokumentierte Unsicherheit):
Das System muss Preise berechnen, obwohl die Daten für die korrekte Steuerberechnung noch nicht existieren. Konkret: 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. Das ist kein hypothetisches Risiko, sondern ein nachweislich gescheiterter Ansatz.
Bisher 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). Im AP-Katalog jetzt aufgenommen. - § 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 (zuvor als „nur eine Schemaänderung" abgetan): Eine Abfahrt mit Tour-Marge und Onboard-Sales erzeugt zwei steuerlich getrennte Einnahmenströme. Der 1:N-Wechsel ist das Ergebnis eines Domain-Spannungsfelds, das erst während der Forschung entdeckt wurde.
WARNING
Ehrliche Einschränkung: Die einzelnen Techniken (deferred computation, append-only versioning, strategy pattern) sind etabliert. Die Innovation liegt in der spezifischen Kombination für ein Domain-Problem ohne Referenzimplementierung. ADR-012 (Fehlversuch) und der Drittlands-Split-Algorithmus sind die stärksten Belege.
CAUTION
Schwachstelle: 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 — das signalisiert Ehrlichkeit und stärkt die Glaubwürdigkeit.
NOTE
Phase-3-FinancialLedger ist bewusst offen. ADR-012 verschiebt die Tax-Decomposition in den FinancialLedger (Phase 3). Die Tatsache, dass die Deferral-Lösung noch nicht validiert ist, belegt laufende Unwägbarkeit — das FZulG fördert den Forschungsprozess, nicht abgeschlossene Ergebnisse. Im Antragstext: „Die architektonische Deferral-Entscheidung (ADR-012) ist getroffen, aber die Pipeline ist noch nicht validiert — genau diese Unsicherheit macht den Forschungsbedarf aus." Falls der Gutachter fragt: Das Projekt befindet sich in der Forschungsphase, nicht im Abschluss.
CAUTION
Schwachstelle: SB-2/ADR-012 Chronologie. Die Lösung (tax-engine.md) existierte am 2026-04-07, drei Tage vor der Problem-Dokumentation (SB-2 am 2026-04-10 als bereits ✅ Resolved committed). Es existiert kein Git-Zustand, in dem SB-2 als offenes Problem vorlag. Maßnahme: Ältere Commits auf Spuren der gescheiterten Per-Variante-Berechnung durchsuchen; bei Fehlanzeige im Antragstext ehrlich als retrospektive Dokumentation darstellen (siehe AP-Katalog §AP1 CAUTION für Details).
IMPORTANT
ADR-009 nicht als Forschungsbeleg. ADR-009 (BookingConfirmed = DEPOSIT_PAID) ist eine juristische Auslegung (§ 651a BGB), keine technische Innovation. Nur als Beleg für Planmäßigkeit verwenden.
Empfohlene Argumentation
Nicht sagen: „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
Warum die BSFZ ablehnen könnte
„Compliance Engine" klingt nach: Verordnung lesen, Regeln als Wenn/Dann-Bedingungen implementieren. Maximale Lenkzeit 9h, Ruhezeit 11h — das steht in der Verordnung.
Was tatsächlich schwer ist (und was nicht)
Nicht schwer (Standard-Engineering):
- Die 6 EU-561 Regeln in Code abbilden — das ist Domänenlogik, keine Forschung
- Sliding-Window-Berechnungen über Zeitfenster — gut erforschtes CS-Thema (Stream Processing, Windowed Aggregation)
- Daten aus verschiedenen Quellen zusammenführen — Standard-ETL
Tatsächlich schwer (dokumentierte Unsicherheit):
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.
Das EU-561 Research-Dokument listet drei mögliche Lösungen — keine davon war bei Projektstart ausgewählt, weil jede andere Tradeoffs erzeugt:
| 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 |
Das ist eine echte architektonische Spannung: Datenisolation (Sicherheit) vs. Datenaggregation (Compliance). Die Lösung erfordert eine Architekturentscheidung, die bei Projektstart offen war — dokumentiert durch 16 ungelöste Checkboxen im Research-Dokument.
WARNING
Ehrliche Einschränkung: Die Cross-Tenant-Spannung ist das stärkste Argument. Die restlichen Aspekte (Sliding-Window, Source-Normalisierung) sind bekannte Informatik-Probleme, die ich im ersten Entwurf rhetorisch aufgeblasen habe. Der BSFZ-Antrag sollte sich auf das Cross-Tenant-Problem konzentrieren und die anderen Aspekte nur als Kontext erwähnen.
Empfohlene Argumentation
Nicht sagen: „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
Warum die BSFZ ablehnen könnte
„Kalkulation" und „Preisgestaltung" klingen betriebswirtschaftlich. Jede ERP-Software kalkuliert Preise.
Was tatsächlich schwer ist
Die Trennung von Costing und Pricing als unabhängige Entities mit eigenen Lifecycles (ADR-006) ist eine Designentscheidung, die bei Projektstart nicht offensichtlich war — 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.
Aber: Die Techniken (Entity Separation, Append-Only Versioning, Checkout Validation) sind einzeln bekannt. Die Frage ist, ob die Kombination für den Gutachter ausreicht.
IMPORTANT
Empfehlung: AP6 nicht als eigenständiges Forschungsthema beantragen, sondern als Teil von Vorhaben 1 (zusammen mit AP1). Die Kalkulations-Engine liefert die Eingabedaten für die Tax-Pipeline — das Forschungsthema ist dann „Preis-Pipeline unter unvollständiger Datenlage", nicht „Kalkulation".
Wackelkandidat 4: AP7 — Crisis Communication [AUFGELÖST]
Status
AP7 wurde in zwei Teile aufgelöst:
- AP7a (65h, Vorhaben 2): Event-Driven Broadcast-Resilience — provider-spezifische Error Classification, Event-Cascade-Orchestrierung. Forschungsanteil bleibt.
- AP7b → AP5 (45h, Vorhaben 3): LLM-Krisennachrichten-Generierung integriert in AP5 als zweiter Anwendungskontext.
- 40h Standard-Infrastruktur (Rate Limiting, Circuit Breaker, Wallet Pass Updates) bewusst nicht beantragt.
Ursprüngliches Risiko und Lösung
„WhatsApp-Broadcasts senden" klingt trivial. Notification-Pipelines baut jedes SaaS. Die Auflösung adressiert genau dieses Risiko: KI-Anteil geht zu Vorhaben 3 (dort thematisch stark), Infra-Anteil bleibt in Vorhaben 2 als Event-Driven-Forschung, Standard-Infra wird ehrlich nicht beantragt.
IMPORTANT
Empfehlung bestätigt sich: Der KI-Fokus liegt jetzt korrekt in AP5 (Vorhaben 3). Die CPaaS-Standard-Infrastruktur (Token-Bucket Rate Limiting, Circuit Breaker) wird bewusst nicht beantragt — 40h ehrliche Abgrenzung.
Wackelkandidat 5: AP21 — AI-SEO / Generative Engine Optimization
Warum die BSFZ ablehnen könnte
"SEO-Optimierung" klingt nach Marketing. Landing Pages stehen auf vielen Ausschlusslisten. Der Gutachter liest "SEO" und denkt: Performance-Marketing, nicht Forschung.
Was tatsächlich schwer ist (und was nicht)
Nicht schwer (Standard-Engineering):
- Schema.org-Markup auf Webseiten anbringen — dokumentiert, Standard
- Meta-Tags und Open-Graph optimieren — SEO-Handwerk
- Server-Side Rendering für Crawler — bekanntes Web-Engineering
Tatsächlich schwer (informationstechnologische Unsicherheit):
Die Content-Pipeline generiert Reise-Landingpages dynamisch aus strukturierten Tourdaten (CostingSheet → PriceMatrix → semantisch angereicherte Seite). Zwei Retrieval-Systeme konsumieren diese Seiten 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 beiden 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 (die kurze, strukturierte Snippets bevorzugt).
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.
WARNING
Ablehnungsrisiko: 🟡 Mittel. Die Argumentation muss zwingend auf die Pipeline-Architektur fokussieren, nicht auf Ranking. Nicht sagen: "Wir verbessern unser Google-Ranking." Stattdessen: "Wir entwickeln eine Content-Pipeline, die aus strukturierten Tourdaten gleichzeitig crawler-optimierte und LLM-retrieval-optimierte Landingpages generiert — ohne manuelle Redaktion."
Empfohlene Argumentation
Nicht sagen: "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 6: AP23 — Privacy-Preserving Conversion Analytics
Warum die BSFZ ablehnen könnte
"Conversion-Funnel-Optimierung" ist Marketing-Jargon. Der Gutachter denkt: A/B-Testing, Google Analytics, Performance-Marketing.
Was tatsächlich schwer ist (und was nicht)
Nicht schwer (Standard-Engineering):
- Event-Tracking in einer Webapp — Standard Analytics
- A/B-Testing-Frameworks — Dutzende existieren (Optimizely, VWO)
- Google Tag Manager / Server-Side Tagging — bekannt
Tatsächlich schwer (informationstechnologische Unsicherheit):
Das Busflow Booking-Widget läuft als iFrame auf Drittseiten (Operator-Websites). Das erzeugt 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. Analytics-Daten verschiedener Operatoren dürfen nicht vermischt werden — aber 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.
WARNING
Ablehnungsrisiko: 🟡 Mittel. Fokus auf die technische Constraint-Kombination (iFrame + Privacy-Sandbox + Multi-Tenant), nicht auf Conversion-Rate. Die Abgrenzung ist: dies ist ein B2C-Produktfeature für Operatoren, kein Busflow-eigenes Marketing.
Empfohlene Argumentation
Nicht sagen: "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 | SB-2/ADR-012 Chronologie in Git nicht nachweisbar; 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 | [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 | Mutation-aware CWT-Lifecycle auf Basis EU-DCC-Stack (IETF RFC 8392/9052) | CWT-JS-Ökosystem dünn; kein ADR/Spike; Business-Impact der Offline-Edge-Case fraglich |
| 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 (Loro/Yjs), Dual-Layer-Architektur, 5 Unwägbarkeiten und 4-Phasen-Plan. Spike ausstehend. In V2 integriert (220h). |
| 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 (2026-05-04). Ansatz bleibt interessant, aber ohne On-Device-ML-Feasibility-Spike nicht beantragbar. Wiederaufnahme nach Technologieentscheidung TensorFlow.js/ONNX. |
| AP25 — Adaptive Feedback | 🟡 Mittel | Adaptive Channel-Routing + Domain Sentiment Analysis | Folgejahres-Pipeline: TODO — Frascati-Evidenz sammeln. Risiko: kann nach Geschäftsregel-Konfiguration klingen. |
| AP26 — Lifecycle Communication | 🟡–🔴 Mittel-Hoch | Cross-Context Event-Orchestrierung über 4 Bounded Contexts | Folgejahres-Pipeline: TODO — Frascati-Evidenz sammeln, insb. was die Cross-Context-Orchestrierung non-trivial macht vs. Standard-Workflow-Engine (n8n/Temporal). |
Behandlung der Kandidaten-APs (AP10–AP19)
Drei Argumentationsmuster decken alle neuen Kandidaten ab — sie sind jeweils Übertragungen der Patterns aus den vier 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" beantragen — als „Risikomodellierung über zeitlich entkoppelte Cashflows in Touristik-Buchungen".
- AP13 (Border Manifests): Spannung = Multi-Country-Compliance bei dynamischer Routenkonfiguration. Nicht als „Manifest-Generator" beantragen — 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" beantragen — 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 (CWT/COSE) für mutationsgewahre Buchungsvalidierung im Offline-Kontext. Credential-Versionierung gekoppelt an AP2-Manifest als Revocation-Orakel. Konkrete Hürden: CWT-TTL-Tradeoff bei Mehrtagestouren, Double-Offline-Konsistenzproblem (Credential und Manifest beide veraltet), QR-Kapazität unter Feldbedingungen.
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): Empfohlen 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.
Sonderfall AP18 (CRDT) [✅ AUFGELÖST]
ADR-032 dokumentiert die Technologieentscheidung (Loro primär, Yjs Fallback) und eine Dual-Layer-Architektur (CRDT-Kollaborationsschicht + relationale Projektion). Der Hasura-LWW-Ansatz bleibt als Produkt-Fallback erhalten — die CRDT-Architektur ist ein explizites Forschungsrisiko.
Frascati-Evidenz (erfüllt):
- 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 dokumentiert: 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, Loro/Yjs als Technologie-Hypothese mit Phase-1-Entscheidungspunkt.
NOTE
Code-Forensik oder bestehende Implementierungsbelege sind für AP18 nicht erforderlich — es handelt sich um ein zukünftiges Forschungsvorhaben. ADR-032 erfüllt die Dokumentationsvoraussetzung. Gleiches gilt sinngemäß für AP19, AP24 und AP26.
Muster D — Privacy-Spannung (Commerce-APs, Vorhaben 4)
Standardtechniken (CDP, Recommendations, Analytics, SEO) im Spannungsfeld mit DSGVO-Constraints. Der Zielkonflikt ist das Forschungselement, nicht die einzelnen Techniken.
- AP20 (360° Profile): Spannung = Datensparsamkeit (GDPR Art. 5(1)(c)) vs. vollständige Verhaltensaggregation über 4 Bounded Contexts. Nicht als "Customer Analytics" beantragen — 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" beantragen — als "Machine Unlearning unter Multi-Tenant-Consent-Constraints".
- AP23 (Conversion Analytics): Spannung = Cross-Origin-Messung vs. Privacy-Sandbox-Instabilität. Nicht als "Conversion-Tracking" beantragen — 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, nicht ein Privacy-Tradeoff.
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?"
Generelle Empfehlungen für den Antragstext
Gescheiterte Versuche betonen. ADR-012 (Tax: per-Variante Steuer war falsch) und ADR-006 (Kalkulation: JSONB-Hack verletzte Immutability) sind die stärksten Belege. Sie zeigen: Der Lösungsweg war tatsächlich unbekannt — wir haben es versucht und es hat nicht funktioniert.
Keine akademische Sprache. „Temporale Entkopplung in verteilten Multi-Entity-Systemen" klingt wie ein Dissertationstitel. Der Gutachter erkennt das als Verpackung. Besser: „Das System muss Preise berechnen, obwohl die Steuerdaten erst Wochen nach dem Verkauf verfügbar sind."
Konkreter sein. Statt „polymorphe Source-Aggregation unter heterogener Datenqualität" → „Drei verschiedene Datenquellen (Tachograph, Fahrer-Eingabe, Systemdaten) mit unterschiedlicher Genauigkeit müssen zu einer einzigen Compliance-Aussage zusammengeführt werden."
Nicht alles als F&E verkaufen. Ehrlich abgrenzen, was Standard-Engineering ist (Circuit Breaker, Rate Limiting, DATEV-Mapping, Valibot-Validierung) und was echte Unsicherheit war. Der Gutachter respektiert ehrliche Abgrenzung mehr als rhetorische Aufwertung.
Checkliste vor Einreichung
- [ ] Enthält der Antragstext keine Feature-Beschreibung aus Kundensicht?
- [ ] Beschreibt der Text ein technisches Hindernis mit unbekanntem Lösungsweg?
- [ ] Belegt der Text die Unsicherheit durch konkrete gescheiterte Versuche oder dokumentierte offene Fragen (ADRs, Research-Docs)?
- [ ] Vermeidet der Text Gesetzesreferenzen im Titel und ersten Absatz?
- [ ] Verwendet der Text klare, einfache Sprache statt akademischer Fachbegriffe?
- [ ] Trennt der Text ehrlich zwischen F&E-Anteil und Implementierungsanteil?