Funding Drilldown — Level 1

Zweck: Vorbereitung von 8 eigenständigen Level-2-Drilldown-Prompts für die systematische Vertiefung der FZulG-Beantragungsstrategie.

AP-Stand: 27 APs (AP1–AP6, AP7a, AP8–AP9 Kern [AP7 aufgelöst], AP10–AP19 Kandidaten, AP20–AP23 Commerce, AP24–AP27 Neue Kandidaten Operations/Comms/AI). Gesamtvolumen-Maximum ~4.270h (historisch in L1 als ~4.110h geführt — die Differenz von 160h erklärt sich durch AP27 [100h] und AP5 Taxonomy-Aware Retrieval [60h], die nach Erstellung dieses Dokuments hinzukamen).

Bezugsdokumente: STRATEGY_public-funding.md, funding-application-plan.md, funding-work-packages.md, bsfz-antrag-vorhaben.md, bsfz-ablehnungsrisiken.md, forschungszulagengesetz.md

Nutzungsanleitung

Jeder L2-Drilldown ist als eigenständige Konversation konzipiert. Der Prompt enthält:

• Scope: Was abgedeckt wird — und was explizit nicht
• Quelldokumente: Dateien, die die L2-Session lesen muss
• Untersuchungsfragen: Konkrete Fragen, die beantwortet werden müssen
• Erwartete Ergebnisse: Was die Session produziert (Edits, neue Dateien, Empfehlungen)
• Randbedingungen: Sprachregeln, Permission-Tiers, Prozessvorgaben

Reihenfolge: G → A → B → D/E/F (parallel) → C → H. Begründung: G liefert das vollständige AP-Inventar (inkl. neuer Kandidaten), das A für die Vorhaben-Clustering-Bewertung braucht. D/E/F liefern die per-AP F&E-Splits und Gutachter-Einwände, die C für die Querschnitts-Konsolidierung benötigt. H steht am Ende, da es primär Folgejahre bedient.

---

Dokumentationslandschaft

Datei	Rolle	Typ
STRATEGY_public-funding.md	Gesamtstrategie: Vorhaben-Clustering, Finanzen, Submission-Strategie	abstract / read-only
funding-application-plan.md	Operativer 5-Phasen-Beantragungsplan	concrete / read-only
funding-work-packages.md	AP-Katalog mit Forschungsfragen, Belegen, Stunden	abstract / read-only
bsfz-antrag-vorhaben.md	BSFZ-Formularfeld-Abbildung für 4 Vorhaben	concrete / read-only
bsfz-ablehnungsrisiken.md	Risikobewertung, Argumentationsmuster, Checkliste	abstract / read-only
forschungszulagengesetz.md	Gesetzesgrundlage (Kurzfassung)	reference
forschungszulagengesetz-ausfuehrlich.md	Gesetzesgrundlage (Langfassung, 1.5MB)	reference

Ergänzende Dokumente (nicht Funding-spezifisch, aber relevant):

Datei	Relevanz
docs/architecture/*.md (18 Dateien)	Technische Belege für AP-Forschungsfragen
docs/product/PRODUCT_domain-model.md	Entity-Definitionen, auf die APs referenzieren
docs/product/PRODUCT_differentiators-10-percent.md	Feature-Roadmap mit Funding-Überlappung
docs/strategy/STRATEGY_platform-vision.md	Horizont-Planung, Agent-Produkte
docs/strategy/STRATEGY_feature-subsets.md	Modulare Go-To-Market-Pakete
docs/strategy/STRATEGY_future-ideas.md	Visionäre Konzepte für potenzielle neue APs
docs/protocols/*.md	Protokoll-Spezifikationen als Planmäßigkeitsbelege
docs/supporting/architectural-decision-record/*.md	ADRs als Kernbelege
docs/supporting/STRATEGIC_BLIND_SPOTS.md	Dokumentierte Blind Spots mit Unwägbarkeits-Belegen
docs/supporting/plans/docs-hub.md	Context-Engine-Architektur, Knowledge-Graph-RAG (AP5-Belege)

---

L2-A: Allgemeine Strategie-Optimierung

Scope

Überprüfung und Optimierung der übergeordneten Beantragungsstrategie — unabhängig von einzelnen APs. Clustering-Empfehlung bezieht sich auf die bestehenden Vorhaben 1–4 und den erweiterten AP-Katalog aus L2-G. Die Detailzuordnung von AP24–AP26 entscheidet L2-E.

Nicht im Scope: Einzelne AP-Inhalte (→ L2-D/E/F), Ablehnungsrisiken (→ L2-C), AP24–AP26-Vorhaben-Zuordnung im Detail (→ L2-E).

Quelldokumente

• docs/strategy/STRATEGY_public-funding.md
• docs/strategy/funding-application-plan.md
• docs/strategy/bsfz-antrag-vorhaben.md (aktuelle Vorhaben-Struktur, um Clustering-Frage zu bewerten)
• docs/supporting/reference/forschungszulagengesetz.md

Untersuchungsfragen

1. Vorhaben-Clustering: Ist die Aufteilung in 4 Vorhaben optimal? Gibt es Argumente für 3 oder 5? Wie wirkt sich die Anzahl auf Gutachter-Wahrnehmung, Verwaltungsaufwand und Teilablehnungs-Risiko aus?
2. Einreichungsreihenfolge: Ist die parallele Einreichung (Woche 17–18) tatsächlich optimal, oder wäre eine gestaffelte Einreichung (erst die sichersten Vorhaben) risikoärmer?
3. Finanzielle Optimierung: Nutzt die aktuelle Strategie die 100€/h-Pauschale und die 40h/Woche-Obergrenze optimal? Gibt es Zeitfenster-Effekte (z.B. Bemessungsgrundlage 10M→12M ab 2026)?
4. Solo-Founder-Taktiken: Welche Solo-Founder-spezifischen Vorteile oder Risiken existieren, die noch nicht adressiert sind? (z.B. Abgrenzung Geschäftsführer-Tätigkeit vs. F&E-Tätigkeit)
5. Berater-Strategie: Ist der empfohlene Ansatz (Eigenantrag + Berater für rote APs) tatsächlich kosteneffizient? Was kostet ein Vollberater im Vergleich?
6. Zeitliche Planung: Sind die Phase-0-Voraussetzungen (Stundenerfassung, Time-Zero) realistisch in 4 Wochen umsetzbar?
7. Folge-Vorhaben-Strategie: Wie plant man die Jahre 2+ — gleiche Vorhaben verlängern oder neue einreichen?

Erwartete Ergebnisse

• Empfehlungen als kommentierte Liste in STRATEGY_public-funding.md (Abschnitt „Strategie-Review")
• Ggf. Anpassungsvorschläge für funding-application-plan.md

Akzeptanzkriterien

• Clustering-Empfehlung enthält eine Begründung mit konkreten Gutachter-Wahrnehmungs-Argumenten (nicht nur "5 wäre besser")
• Jede Empfehlung referenziert die spezifische Stelle im Quelldokument, die sie ändert
• Folge-Vorhaben-Strategie enthält mindestens 2 konkrete Szenarien (Verlängerung vs. Neueinreichung) mit Vor-/Nachteilen

Offene Hypothesen (L1)

• Stundenkonsistenz: Zahlen zwischen STRATEGY_public-funding.md und AP-Katalog stimmen überein (Konservativ 1.660h, Maximum ~4.110h). Kein Handlungsbedarf. Aktualisiert: Das Maximum ist ~4.270h (AP-Katalog funding-work-packages.md:286-294). Die Differenz zu den hier genannten ~4.110h (160h) entsteht durch AP27 (+100h) und AP5 Taxonomy-Aware Retrieval (+60h). Konservativ 1.660h bleibt gültig.
• Vorhaben-2-Breite: 5–6 APs über heterogene Forschungsfragen (Offline-Sync, EU-561, Event Architecture, Broadcast, Concurrency, ggf. Dispatch Conflict). Die Klammer "Datenkonsistenz über Vertrauensgrenzen" ist abstrakt — ein Gutachter könnte V2 als Sammelbecken empfinden. Prüfen, ob V2 in zwei Vorhaben aufgesplittet werden sollte.
• Folge-Vorhaben: Kein Dokument adressiert Jahre 2+ (Verlängerung vs. Neueinreichung, Interaktion mit laufenden Bescheinigungen).

Randbedingungen

• Sprache: Deutsch (Fachbegriffe deutsch)
• Keine Änderungen an AP-Inhalten — nur an der Strategie-Ebene
• Alle Empfehlungen müssen gegen die aktuelle Gesetzeslage (FZulG, Wachstumschancengesetz 2024) geprüft sein

---

L2-B: Querschnittsthemen

Scope

Themen, die alle 4 Vorhaben und mehrere APs gleichzeitig betreffen. Ziel: Konsistenz und Vollständigkeit über alle Dokumente hinweg sicherstellen.

Nicht im Scope: AP-spezifische Inhalte (→ L2-D/E), strategische Gesamtbewertung (→ L2-A).

Quelldokumente

• Alle 7 Funding-relevanten Dokumente (siehe Dokumentationslandschaft)
• docs/architecture/infrastructure.md (Infrastruktur-Stunden)
• docs/architecture/observability.md (Observability als Forschungsinfrastruktur)
• docs/architecture/workflow-orchestration.md (Workflow-Architektur)

Untersuchungsfragen

1. Infrastruktur-Stunden-Allokation: Wie verteilt man forschungsbedingte Infrastrukturarbeit (Docker Swarm, Observability-Stack, CI/CD für Telemetry-Research) proportional auf APs? Welche Stunden sind förderfähig, welche nicht? Einen Entwurf-Verteilungsschlüssel als Diskussionsgrundlage für den Steuerberater erarbeiten — keine finale Empfehlung, Annahmen kennzeichnen.
2. Frascati-Sprachkonsistenz: Verwenden alle Vorhaben-Texte (bsfz-antrag-vorhaben.md) konsistent die drei kumulativen Kriterien (Neuartigkeit, Unwägbarkeit, Planmäßigkeit)? Gibt es Formulierungen, die nach „Feature-Beschreibung" oder „Gesetzesimplementierung" klingen?
3. Time-Zero-Verankerung: Ist die Time-Zero-Strategie (frühester relevanter ADR/Commit) für alle 4 Vorhaben konsistent? Gibt es Vorhaben, bei denen der Time-Zero problematisch ist (z.B. Vorhaben 4 — erst ab April 2026)?
4. Beweisketten-Integrität: Referenzieren alle APs auf existierende, auffindbare Belege (ADRs, Protokolle, Research-Docs)? Gibt es „verwaiste" Referenzen oder fehlende Belege?
5. Stundenerfassungs-Design: Ist das Hybrid-Modell (Papier + CSV + Git) praktisch umsetzbar für einen Solo-Founder? Gibt es bessere Alternativen?
6. Dokumentation-als-Beweis: Welche bestehenden Dokumente (ADRs, Protokolle, Specs) eignen sich als BSFZ-Anlagen, und welche brauchen redaktionelle Aufbereitung?
7. Konsistenz der Stundenschätzungen: Stimmen die Stundenzahlen zwischen funding-work-packages.md, STRATEGY_public-funding.md und bsfz-antrag-vorhaben.md überein?
8. Abgrenzungs-Konsistenz: Verwenden alle Vorhaben die gleiche Methodik zur Trennung von F&E vs. Standard-Engineering?
9. TODO-Felder: Welche [TODO]-Felder in bsfz-antrag-vorhaben.md (Verwertungshorizont, Start des Vorhabens, Tabellarischer Arbeitsplan) können bereits ausgefüllt werden? Welche blockieren auf externe Information (Steuerberater, Git-Chronologie)?

Erwartete Ergebnisse

• Konsistenz-Report mit konkreten Diskrepanzen und Korrekturvorschlägen
• Infrastruktur-Stunden-Verteilungsschlüssel als Tabelle (Entwurf, Berater-Vorbehalt)
• Redaktionelle Empfehlungen für BSFZ-Anlagen

Akzeptanzkriterien

• Konsistenz-Report listet jede Diskrepanz mit Quelldokument, Zeilennummer und konkretem Korrekturvorschlag
• Infrastruktur-Verteilungsschlüssel kennzeichnet explizit, welche Annahmen der Steuerberater validieren muss
• TODO-Felder-Audit: jedes TODO hat eine Handlungsempfehlung ("jetzt ausfüllen" / "blockiert auf X" / "Berater-Input nötig")

Offene Hypothesen (L1)

• 46 TODO-Zeilen in bsfz-antrag-vorhaben.md: 16× [TODO — Rohtext:] (inhaltlich vorhanden, aber als Rohtext markiert), 8× Titel/Verschlagwortung, 14× Arbeitsplan-Zeilen (je 2 TODO-Felder: Zeitraum + PM), 4× Verwertungshorizont, 4× Start-Datum. Die Rohtexte existieren — die meisten TODOs betreffen Finalisierung, nicht fehlenden Inhalt.
• 3 Frascati-Sprachkandidaten: (1) V1-Titel enthält "steuerrelevante Kostendaten" → klingt nach Gesetzesimplementierung. (2) V2 §3.3 "Kaskadierte Domain-Event-Pipelines" → Feature-Beschreibung. (3) V4-Titel "Datenschutzkonforme Kundendatenanalyse" → Feature.
• Infrastruktur-Stunden: Kein Verteilungsschlüssel existiert. funding-application-plan.md listet dies als offenen Nächsten Schritt mit Berater-Rücksprache.
• Time-Zero V4: Frühester V4-Commit 2026-04-17 (ADR-021). Prospektive Stunden (geplante F&E-Arbeit) sind FZulG-konform und müssen nicht rückwirkend belegt werden. Dennoch prüfen: GDPR-Strategy-Commit als alternativen, früheren Time-Zero verwenden?
• Stundenkonsistenz: Zahlen zwischen den drei Dokumenten konsistent. ✅

Randbedingungen

• Keine AP-inhaltlichen Änderungen — nur Querschnitts-Konsistenz
• Änderungen an bsfz-antrag-vorhaben.md nur nach Freigabe

---

L2-C: Risikobehandlung & Ablehnungsprävention

Scope

Querschnittliche Risikobehandlung und Audit-Verteidigung. Läuft nach L2-D/E/F und konsolidiert deren per-AP F&E-Splits und Gutachter-Einwände in Querschnittsmuster. Fokus auf Muster-Ebene (Argumentationsmuster, Gutachter-Typen, Audit-Szenarien).

NOTE

Q1 (Gutachter-Typen), Q5 (Audit-Verteidigung) und Q7 (Worst-Case) benötigen keine per-AP-Inputs und können zu Beginn der Session bearbeitet werden, auch wenn D/E/F-Ergebnisse noch einlaufen.

Nicht im Scope: Strategische Gesamtbewertung (→ L2-A), neue APs identifizieren (→ L2-G/H), per-AP Frascati-Scoring (→ L2-D/E/F).

Quelldokumente

• docs/supporting/reference/bsfz-ablehnungsrisiken.md
• docs/strategy/funding-work-packages.md
• docs/strategy/bsfz-antrag-vorhaben.md
• docs/supporting/reference/forschungszulagengesetz.md (Frascati-Kriterien)
• docs/supporting/STRATEGIC_BLIND_SPOTS.md (Unwägbarkeits-Belege)

Untersuchungsfragen

1. Gutachter-Typen-Analyse: Welche Gutachter-Profile (akademisch-technisch, praxisnah-ingenieurwissenschaftlich, bürokratisch-formalistisch) existieren, und wie muss die Sprache für jeden Typ kalibriert werden?
2. Argumentationsmuster-Validierung: Sind die vier Muster (A: Infrastruktur-Spannung, B: Cross-Tenant, C: Constraint-Satisfaction, D: Privacy-Spannung) aus bsfz-ablehnungsrisiken.md vollständig? Fehlt ein Muster für die neuen APs (AP24–AP26)?
3. Teilablehnungs-Strategie: Wenn ein AP innerhalb eines Vorhabens abgelehnt wird — wie reagiert man? Welche APs sind „verzichtbar" ohne das Vorhaben zu gefährden? Abhängigkeits-Karte erstellen.
4. Chronologie-Schwachstellen: Neben der bekannten SB-2/ADR-012-Lücke — gibt es weitere Git-Chronologie-Probleme in anderen APs? Systematischer Scan aller AP-Belege auf Datums-Konsistenz.
5. Audit-Verteidigung: Welche Finanzamt-Audit-Szenarien (bis 4 Jahre nach Auszahlung) erfordern Vorbereitung? Welche Dokumentation fehlt? Konkreten Dokumentations-Aufbewahrungsplan vorschlagen.
6. Proaktive Maßnahmen: Welche präventiven Schritte (z.B. zusätzliche ADRs schreiben, Code-Kommentare für Gutachter aufbereiten) stärken die Beweislage vor Einreichung? Priorisierte Maßnahmenliste.
7. Worst-Case-Szenarien: Was passiert bei Totalablehnung eines Vorhabens? Welche Nachbesserungs- und Widerspruchswege existieren? Zeitrahmen und Kosten abschätzen.

Erwartete Ergebnisse

• Aktualisierte bsfz-ablehnungsrisiken.md mit Gutachter-Typ-Kalibrierung und erweiterten Argumentationsmustern
• Teilablehnungs-Abhängigkeits-Karte (welche APs sind verzichtbar pro Vorhaben)
• Audit-Vorbereitungs-Checkliste mit Dokumentations-Aufbewahrungsplan
• Priorisierte Liste präventiver Maßnahmen vor Einreichung
• Worst-Case-Szenario-Plan (Totalablehnung, Widerspruch, Nachbesserung)

Akzeptanzkriterien

• Jeder Gutachter-Typ hat min. 1 konkreten Textbaustein pro Vorhaben (nicht generisch, sondern Vorhaben-spezifisch kalibriert)
• Teilablehnungs-Karte enthält pro Vorhaben eine "Minimal Viable Submission" (welche APs reichen allein?)
• Proaktive Maßnahmen sind priorisiert nach Aufwand/Wirkung mit konkretem Zeitbedarf

Offene Hypothesen (L1)

• SB-2/ADR-012 bleibt kritischste Chronologie-Schwachstelle. tax-engine.md erstellt 3 Tage vor SB-2-Dokumentation. Kein Git-Zustand existiert, in dem SB-2 als offenes Problem vorlag. Maßnahme in funding-application-plan.md §2.2 definiert, aber nicht durchgeführt.
• Argumentationsmuster-Lücke: 4 Muster (A–D) decken AP1–AP23 ab. AP24 passt in Muster B (konkrete technische Hürde: On-Device-ML im PWA-Kontext), AP25 braucht ggf. ein neues Muster (Adaptive Orchestrierung), AP26 passt in Muster A (Cross-Domain-Spannung).
• Risiko-Tiers: 2× 🔴 (AP1, AP3), 1× 🟡–🔴 (AP26), 15× 🟡, 8× 🟢. Die roten APs haben bereits ausführliche Wackelkandidat-Analysen. AP24–AP26 haben Einträge in der Risikoübersicht, aber keine detaillierten Analysen.
• STRATEGIC_BLIND_SPOTS.md enthält 14 Einträge, davon 4 mit AP-Kandidaten-Potenzial (SB-11 Multi-Leg Delay, SB-12 Manifest Size, SB-13 Partial Leg, SB-14 Telemetry Retention).

Randbedingungen

• Texte in der Sprache des Gutachters formulieren: klar, konkret, nicht akademisch aufgeblasen
• Die "ehrliche Abgrenzung"-Philosophie aus der Risiken-Doku beibehalten
• Per-AP F&E-/Engineering-Splits gehören in L2-D/E/F — hier nur Querschnittsmuster

---

L2-D: Detailanalyse Kern-APs (AP1–AP9)

Scope

Tiefenanalyse jedes validierten APs (✅) aus Vorhaben 1–3. Pro AP: Frascati-Konformität, Beweislage, Stundenschätzung, Forschungsfrage.

Nicht im Scope: Commerce-APs (→ L2-E), Kandidaten-APs (→ L2-F), Strategie-Ebene (→ L2-A).

Quelldokumente

• docs/strategy/funding-work-packages.md (AP-Definitionen)
• docs/strategy/bsfz-antrag-vorhaben.md (Antragsformulierungen)
• Pro AP die referenzierten Belege:
  • AP1: apps/api/docs/tax-engine.md, ADR-006, ADR-012, ADR-015
  • AP2: docs/protocols/offline-sync-protocol.md, ADR-017, docs/schemas/schema-operations.md
  • AP3: docs/supporting/reference/eu-561-compliance-research.md, docs/protocols/dispatch-availability-engine.md
  • AP4: ADR-004, ADR-019, docs/architecture/event-catalog.md, docs/architecture/workflow-orchestration.md
  • AP5: docs/architecture/ai.md, docs/protocols/mcp-agent-bridge.md, docs/architecture/validation-strategy.md, docs/protocols/notification-pipeline-protocol.md, docs/protocols/incident-broadcast-protocol.md, docs/supporting/plans/docs-hub.md (§Context-Engine, §Knowledge Graph)
  • AP6: ADR-006, docs/protocols/kalkulations-engine.md
  • AP7a: docs/protocols/notification-pipeline-protocol.md
  • AP8: docs/architecture/realtime-strategy.md, docs/schemas/schema-commerce.md
  • AP9: docs/strategy/agentic-led-company-spec.md, ADR-020

Untersuchungsfragen

Pro AP (AP1–AP6, AP7a, AP8–AP9):

1. Frascati-Scoring: Erfüllt die Forschungsfrage die drei kumulativen Kriterien? Welches Kriterium ist am schwächsten belegt?
2. Beweislücken: Existieren alle referenzierten Belege? Sind sie inhaltlich ausreichend, oder brauchen sie Ergänzung?
3. Stundenschätzung und F&E-Split: Ist der F&E-Anteil plausibel? Wie viel Prozent der geschätzten Stunden sind echte F&E vs. Standard-Engineering? (Diese Analyse liefert den Input für L2-C.)
4. Forschungsfrage: Ist die Formulierung „scharf" genug — d.h. beschreibt sie ein konkretes technisches Hindernis mit unbekanntem Lösungsweg?
5. Abhängigkeiten: Sind die dokumentierten AP-Abhängigkeiten innerhalb eines Vorhabens korrekt? Gibt es undokumentierte Abhängigkeiten?
6. Antragstext-Qualität: Sind die Rohtexte in bsfz-antrag-vorhaben.md (Ziel, Stand der Technik, Durchgeführte Arbeiten, Unsicherheiten) scharf, konkret und frei von Feature-Sprache?
7. Gutachter-Einwände: Für jeden AP: Wahrscheinlichster Ablehnungsgrund als konkreter Gutachter-Einwand und passender Verteidigungs-Textbaustein (max. 200 Zeichen).

Erwartete Ergebnisse

• Frascati-Scorecard (Tabelle: AP × Kriterium → Grün/Gelb/Rot)
• Pro AP: F&E-/Engineering-Split als Tabelle
• Pro AP: Gutachter-Einwand + Verteidigungstext
• Pro AP: Liste konkreter Verbesserungen für Forschungsfrage und Antragstext
• Beweislücken-Report mit Handlungsempfehlungen
• Stunden-Plausibilitäts-Tabelle

Akzeptanzkriterien

• Frascati-Scorecard deckt alle 3 Kriterien × alle 9 AP-Slots ab — kein Feld leer
• Jeder F&E-Split enthält eine Prozent-Angabe mit Begründung (nicht nur "geschätzt 60%")
• AP26 ↔ AP7a-Abgrenzung: L2-D verweist auf L2-E-Ergebnis, erstellt keine eigene

Offene Hypothesen (L1)

• AP1 ist der einzige AP mit explizitem F&E-Split (150–200h F&E / 200–250h Engineering). Alle anderen APs brauchen diese Analyse.
• AP5 ist mit 495h (345+50+100) der größte AP. 3 Scope-Erweiterungen in einem AP — ein Gutachter könnte das als Catch-All-Bucket wahrnehmen. Prüfen, ob die Buchungsmutationen-Erweiterung (+100h) als separater AP eingereicht werden sollte.
• AP6 hat eine explizite Warnung in der Risiken-Doku: "Isoliert dünn — hängt vollständig an AP1-Verzahnung." Darf nie ohne AP1-Kontext argumentiert werden.
• AP9 hat Status ⚪ (Entwurf). 383-Zeilen-Spec + ADR-020, aber kein Code. Die Forschungsfrage (Agentic Governance für Solo-Founder-SaaS) ist neuartig, aber die Beleglage ist rein spezifikativ.
• V1 Anlagen listen nicht price-matrix-variant-spec.md (AP6-Beleg). V2 Anlagen listen nicht ADR-019 (AP4-Beleg). V3 Anlagen referenzieren korrekt docs-hub.md.
• AP26 ↔ AP7a Abgrenzung: Die Abgrenzung schreibt L2-E (AP26 ist dort). L2-D verweist auf L2-E-Ergebnis für AP7a-Kontextbewertung.

Randbedingungen

• Nur Analyse und Empfehlungen — keine Direktänderungen an read-only-Dateien
• Empfehlungen müssen den Sprach-Check aus bsfz-ablehnungsrisiken.md bestehen (keine Gesetzesreferenz im Titel, keine Feature-Beschreibung, klare Sprache)

---

L2-E: Detailanalyse Commerce- & Kommunikations-APs (AP20-AP26)

Scope

Tiefenanalyse der sieben APs ausserhalb der Kern-Vorhaben 1-3 und der Kandidaten AP10-AP19:

• AP20-AP23 (Commerce Intelligence, Vorhaben 4) — alle Status 🟡, Codebasis-Validierung ausstehend
• AP24 (Field-Device Media Pipeline mit On-Device Quality Scoring & Consent Management) — Status ⚪
• AP25 (Adaptive Multi-Channel Feedback Engine mit Domain-Specific Sentiment Analysis) — Status ⚪
• AP26 (Proactive Lifecycle Communication Engine) — Status ⚪, Ablehnungsrisiko 🟡-🔴

Nicht im Scope: Kern-APs (→ L2-D), Kandidaten AP10-AP19 (→ L2-F).

Quelldokumente

• docs/strategy/funding-work-packages.md (§Commerce-Kandidaten + §AP24–AP26)
• docs/strategy/bsfz-antrag-vorhaben.md (Vorhaben 4)
• docs/supporting/reference/bsfz-ablehnungsrisiken.md (§Wackelkandidaten 5–6, §Muster D)
• docs/architecture/gdpr-strategy.md
• docs/architecture/communications.md (Kanal-Architektur für AP25/AP26)
• docs/architecture/workflow-orchestration.md (Event-Orchestrierung für AP26)
• docs/product/PRODUCT_differentiators-10-percent.md (§1 360° Customer Profile)
• docs/schemas/schema-operations.md (§Offline Photo Upload Protocol für AP24)
• ADR-021 (Customer Intelligence Context — EngagementScore, ChannelPreference)

Untersuchungsfragen

1. Codebasis-Validierung: Welche der sieben APs haben Codebasis-Artefakte (Schemas, Prototypen, ADRs)? Welche sind rein konzeptionell?
2. Vorhaben-Zuordnung AP24–AP26: Gehören die drei neuen APs in Vorhaben 4 (Privacy/Commerce-Bogen), bilden sie ein Vorhaben 5, oder verteilen sie sich auf bestehende Vorhaben (z.B. AP26 → Vorhaben 2 wegen Event-Orchestrierung, AP24 → Vorhaben 3 wegen On-Device-ML)?
3. Vorhaben-4-Kohärenz: Ist die übergreifende Forschungsfrage (Privacy vs. Datennutzung) stark genug für AP20–AP23? Falls AP24–AP26 dazukommen — hält der Bogen?
4. Privacy-Spannungs-Argumentation: Ist Muster D für alle APs tragfähig? AP24 hat eine Consent-Dimension (Recht am eigenen Bild), AP25 hat ChannelPreference-Privacy — passen sie in Muster D?
5. Stunden-Plausibilität: 640h (AP20–AP23) + 340h (AP24–AP26) = 980h für überwiegend konzeptionelle APs — realistisch?
6. Reife-Assessment: Welche APs sind reif für die Ersteinreichung? Welche verschieben sich auf Jahr 2+?
7. Fehlende Belege: Welche ADRs, Research-Docs oder Prototypen müssen vor Einreichung erstellt werden? AP24 warnt explizit: ohne On-Device-ML kein AP.
8. Abgrenzung zu Marketing/Trivialität: AP21 (AI-SEO), AP23 (Conversion Analytics), AP25 (Feedback-Engine) und AP26 (Lifecycle Communication) riskieren, als Standard-Marketing-Automatisierung wahrgenommen zu werden. Sind die technischen Argumentationen ausreichend?
9. Abhängigkeiten zwischen neuen APs: AP24 verwandt mit AP16 (Mobile OCR — gleiche Pipeline, anderer Input). AP25 konsumiert AP20-Daten (EngagementScore). AP26 ↔ AP7a Abgrenzung: L2-E hat den Lead — die Abgrenzung zwischen AP26 (Lifecycle Communication) und AP7a (Broadcast-Resilience) wird hier geschrieben, L2-D übernimmt das Ergebnis.

Erwartete Ergebnisse

• Reife-Matrix (AP20–AP26 × Dimension: Codebasis, Belege, Forschungsfrage, Stunden, Risiko)
• Pro AP: F&E-/Engineering-Split und Gutachter-Einwand + Verteidigungstext (Input für L2-C)
• Vorhaben-Zuordnungsempfehlung für AP24–AP26
• Go/No-Go-Empfehlung pro AP für Ersteinreichung
• Liste fehlender Artefakte, die vor Einreichung erstellt werden müssen
• Für AP24–AP26: Initiale Antragstext-Entwürfe im Format von bsfz-antrag-vorhaben.md (Ziel, Stand der Technik, Durchgeführte Arbeiten, Unsicherheiten) — diese APs haben noch keinen Antragstext
• Für AP20–AP23: Ggf. überarbeitete Forschungsfragen und Antragstext-Korrekturen
• AP26 ↔ AP7a Abgrenzungsdokument (wird von L2-D übernommen)

Akzeptanzkriterien

• Reife-Matrix enthält alle 7 APs × alle 5 Dimensionen — kein Feld leer oder "unklar"
• Go/No-Go pro AP enthält eine Begründung ≤3 Sätze
• AP24–AP26 Antragstext-Entwürfe bestehen den Frascati-Schnelltest (kein Feature-Vokabular, keine Gesetzesreferenzen)
• AP26 ↔ AP7a Abgrenzung ist als eigenständiger Abschnitt formuliert, nicht nur erwähnt

Offene Hypothesen (L1)

• V4 Time-Zero: Frühester V4-Commit 2026-04-17 (ADR-021). Prospektive F&E-Stunden sind FZulG-konform — die 640h müssen nicht alle vor Einreichung geleistet sein. Dennoch bewerten: Reicht die bisherige Beleglage für die Ersteinreichung, oder sollten weitere Artefakte vor Antragsstellung erstellt werden?
• AP25 → AP20 Abhängigkeit: AP25 konsumiert EngagementScore und ChannelPreference aus ADR-021. Ohne AP20 gibt es kein AP25. Muss in Vorhaben-Zuordnung berücksichtigt werden.
• AP24 hat eine harte Bedingung: On-Device Quality Scoring via TensorFlow.js/ONNX im PWA-Kontext. Falls nicht technisch realisierbar → Standard-Upload-Pipeline → kein AP.
• AP24–AP26 haben keine Wackelkandidat-Analyse in bsfz-ablehnungsrisiken.md (nur Einzeiler in der Risikoübersicht). L2-E muss detaillierte Analysen im Stil von Wackelkandidat 1–6 erarbeiten.
• bsfz-antrag-vorhaben.md enthält keine Texte für AP24–AP26. L2-E muss initiale Antragstext-Entwürfe erstellen.

Randbedingungen

• Ehrliche Bewertung der Reife — kein "Hochschreiben" konzeptioneller APs
• Empfehlung, ob Vorhaben 4 eingereicht, erweitert (AP24–AP26), aufgeteilt, oder auf Jahr 2 verschoben werden soll
• AP24: On-Device-ML muss real sein, sonst Standard-Upload-Pipeline
• AP26: 🟡–🔴 Ablehnungsrisiko — besondere Aufmerksamkeit bei der Forschungsfrage

---

L2-F: Triage Kandidaten-APs (AP10–AP19)

Scope

Systematische Bewertung aller 10 Kandidaten-APs auf Förderfähigkeit, Vorhaben-Zuordnung und Einreichungs-Priorisierung.

Nicht im Scope: Kern-APs (→ L2-D), Commerce-APs (→ L2-E), neue AP-Kandidaten (→ L2-G).

Quelldokumente

• docs/strategy/funding-work-packages.md (§Neue Kandidaten)
• docs/supporting/reference/bsfz-ablehnungsrisiken.md (§Risikoübersicht, §Muster A/B/C)
• Pro AP die referenzierten Belege:
  • AP10: Domain Model (CostingSheet.fx_risk_buffer)
  • AP11: Domain Model (Seat Re-Mapping)
  • AP12: TelemetryPoint, ADR-027
  • AP13: Domain Model (Border Manifests)
  • AP14: Domain Model (Dispatch Conflict)
  • AP15: docs/protocols/dispatch-availability-engine.md
  • AP16: Domain Model (ExpenseReceipt)
  • AP17: Domain Model (Reseller), ADR-016
  • AP18: Codebasis-Check erforderlich (CRDT vs. Last-Write-Wins)
  • AP19: Codebasis-Check erforderlich

Untersuchungsfragen

1. Codebasis-Validierung: Für jeden AP: Existiert Code oder Schema, das die Forschungsfrage stützt? Oder existiert nur ein Domain-Model-Eintrag?
2. Vorhaben-Zuordnung: Welche APs gehören in bestehende Vorhaben (1–4), welche bilden ein fünftes Vorhaben?
3. Go/No-Go: Für jeden AP: Einreichen (Jahr 1), verschieben (Jahr 2+), oder verwerfen?
4. Argumentationsmuster: Passt das in bsfz-ablehnungsrisiken.md vorgeschlagene Muster (A/B/C) für jeden AP, oder braucht es Anpassungen?
5. Kombinierbarkeit: Welche APs stärken sich gegenseitig, wenn sie im gleichen Vorhaben eingereicht werden (z.B. AP15 + AP3)?
6. Bedingungen: AP18 (CRDT) ist bedingt förderfähig. Welche anderen APs haben versteckte Bedingungen?
7. Stunden-Gesamtrahmen: Welches Volumen ergibt sich bei optimaler Selektion? Bleibt es innerhalb des 40h/Woche-Rahmens?

Erwartete Ergebnisse

• Triage-Tabelle (AP × Go/No-Go/Verschieben + Begründung)
• Vorhaben-Zuordnungsvorschlag für die aufgenommenen APs
• Aktualisierte Stundenübersicht
• Bedingungsliste (was muss vor Einreichung geklärt werden)

Akzeptanzkriterien

• Jeder der 10 APs hat eine Go/No-Go/Verschieben-Entscheidung mit Begründung ≤3 Sätze
• AP18 und AP19 haben einen Codebasis-Check-Befund (nicht nur "muss geprüft werden")
• Triage-Tabelle enthält Spalten: AP | Entscheidung | Begründung | Vorhaben | Stunden | Bedingungen

Offene Hypothesen (L1)

• AP15 → AP3 Integration empfohlen: bsfz-ablehnungsrisiken.md empfiehlt explizit: "Standalone-Risiko: 🔴 Hoch; integriert in AP3: 🟢 Niedrig." Die EU-561-Integration ist das Forschungselement, nicht der CSP-Solver an sich.
• AP18 CRDT-Bedingung: Nur förderfähig bei Yjs/Automerge-Implementierung. Bei Last-Write-Wins via Hasura: nicht beantragen. Codebasis-Prüfung in dieser L2-Session durchführen.
• AP19 Wallet-Bedingung: Standard-Wallet-Pass-Infrastruktur eliminiert die Forschungsfrage. Nur förderfähig bei Custom-Offline-Validierungsprotokoll.
• Beleglage heterogen: AP10–AP17 haben Domain-Model-Einträge, aber nur AP12 (ADR-027), AP15 (dispatch-availability-engine.md) und AP17 (ADR-016) haben formale Belege jenseits des Domain-Models.

Randbedingungen

• Konservative Bewertung bevorzugen — lieber weniger APs mit starker Beweislage als viele mit dünner Basis
• AP18 (CRDT) erfordert eine Codebasis-Prüfung, die in dieser Session durchgeführt werden soll

---

L2-G: Neue AP-Kandidaten — Codebasis- & Dokumentations-Mining

Scope

Systematische Suche nach förderfähiger Forschungsarbeit, die in der bestehenden Codebasis und Dokumentation existiert, aber noch in keinem AP erfasst ist. Läuft als erste Session — die Ergebnisse fließen in L2-A (Vorhaben-Clustering) und L2-D/E/F (AP-Zuordnung) ein.

Nicht im Scope: Bestehende APs verbessern (→ L2-D/E/F), marktbasierte Chancen (→ L2-H).

Quelldokumente

• docs/architecture/ (alle 18 Dateien)
• docs/protocols/ (alle 25 Protokoll-Spezifikationen)
• docs/schemas/ (schema-backoffice, schema-commerce, schema-operations, schema-pricing — Entity-Definitionen als Primärquelle für unmapped Domain-Logik)
• docs/product/PRODUCT_domain-model.md
• docs/product/PRODUCT_differentiators-10-percent.md
• docs/strategy/STRATEGY_platform-vision.md
• docs/strategy/STRATEGY_feature-subsets.md
• docs/strategy/STRATEGY_future-ideas.md (nur interne Bewertung — externe Marktchancen → L2-H)
• docs/supporting/architectural-decision-record/ (alle 30 ADRs)
• docs/supporting/STRATEGIC_BLIND_SPOTS.md (14 Einträge, davon 4 mit AP-Potenzial)
• apps/api/docs/ (API-interne Dokumentation)

Untersuchungsfragen

1. Architektur-Mining: Welche technischen Herausforderungen in docs/architecture/ (z.B. Realtime-Strategy, Workflow-Orchestration, Observability) enthalten förderfähige Forschungsfragen, die kein AP abdeckt?
2. Protokoll-Mining: Welche Protokoll-Spezifikationen dokumentieren Unsicherheiten oder Designentscheidungen unter Unwägbarkeit?
3. Domain-Model-Lücken: Gibt es Entities im Domain-Model, die technische Forschungsfragen aufwerfen, aber keinem AP zugeordnet sind?
4. ADR-Mining: Welche ADRs dokumentieren gescheiterte Ansätze oder offene Forschungsfragen, die noch nicht in APs abgebildet sind?
5. Feature-Subset-Gaps: Gibt es Feature-Subsets (z.B. „Crisis Management", „Digital Fulfillment"), deren technische Herausforderungen in keinem AP erfasst sind?
6. Infrastruktur als Forschung: Welche Infrastruktur-Arbeit (Multi-Tenant-Isolation, Observability-Stack, Edge Computing) qualifiziert eigenständig als Forschung?
7. Blind-Spot-Mining: Welche offenen Blind Spots (STRATEGIC_BLIND_SPOTS.md) enthalten eigenständige Forschungsfragen?
8. AP-Formulierung: Für jeden identifizierten Kandidaten: Forschungsfrage, Neuartigkeit, Belege, geschätzter Stundenaufwand im AP-Katalog-Format formulieren.

Erwartete Ergebnisse

• Liste neuer AP-Kandidaten im Format des AP-Katalogs
• Pro Kandidat: Vorhaben-Zuordnung, Risikobewertung, Argumentationsmuster
• Empfehlung, welche Kandidaten in die Ersteinreichung aufgenommen werden sollen
• Ggf. neue Vorhaben-Vorschläge, falls die Kandidaten nicht in bestehende Vorhaben passen

Akzeptanzkriterien

• Jeder Kandidat besteht den dreistufigen Frascati-Schnelltest (siehe Randbedingungen)
• Jeder Kandidat hat eine Forschungsfrage, min. 1 existierenden Beleg (Pfad angeben), und eine Stundenschätzung
• Alle 14 Blind Spots (SB-1–SB-14) klassifiziert: 4 mit AP-Potenzial (SB-11–SB-14) tiefengeprüft, die übrigen 10 explizit als resolved / product decision / kein F&E markiert
• Alle 30 ADRs in einer Abdeckungstabelle erfasst: 12 bereits in APs referenziert, 8 als unmapped tiefengeprüft (Go/No-Go), 10 ältere ADRs explizit klassifiziert (bestehender AP-Beleg / kein F&E / Planmäßigkeitsbeleg)
• Go/No-Go-Bewertung pro ADR/Blind-Spot verwendet drei Kategorien: (a) Go — eigenständiger AP-Kandidat mit Forschungsfrage, (b) Go — Beleg für bestehenden AP (kein eigener AP, aber wertvoller Zusatzbeleg), (c) No-Go — Standard-Engineering, keine Forschungsfrage identifizierbar

Offene Hypothesen (L1)

• 4 Blind Spots mit AP-Potenzial: SB-11 (Multi-Leg Delay Propagation), SB-12 (Driver App Manifest Size — verwandt mit AP2), SB-13 (Partial Leg Completion — State-Machine-Erweiterung), SB-14 (TelemetryPoint Data Retention — verwandt mit AP12). Die übrigen 10 Blind Spots (SB-1–SB-10) sind voraussichtlich resolved, product decision oder planned ohne eigenständige Forschungsfrage — L2-G muss das explizit bestätigen.
• 8 unmapped ADRs (tiefenprüfen): ADR-022 (Ubicloud Cutover), ADR-023 (Swarm Quorum), ADR-024 (LB Strategy), ADR-025 (Manager Failover DNS), ADR-028 (GDPR TTL), ADR-029 (Secrets/Encryption), ADR-030 (Subscription Tier Gating), ADR-031 (Immutable Infrastructure). Ob diese eigenständige Forschungsfragen enthalten, muss L2-G prüfen.
• 10 ältere ADRs (klassifizieren): ADR-001 (Boarding Point), ADR-002 (Financial Ledger), ADR-003 (Tenant Provisioning), ADR-005 (JWT Session), ADR-007 (Crew/Fleet/Subcontracting), ADR-008 (Vehicle Maintenance), ADR-010 (Input/Output VO Separation), ADR-011 (Input Rule Snapshotting), ADR-014 (Ticket Issuance), ADR-018 (ServiceLeg Creation). Keine davon erscheint in der unmapped-Liste oder als expliziter AP-Beleg. L2-G muss jede als Beleg für bestehenden AP oder kein F&E klassifizieren. Insbesondere ADR-002 (Financial Ledger) und ADR-007 (Crew/Fleet) könnten Forschungsrelevanz besitzen.
• ADR-027 (Cardinality Budget) ist bereits in AP12 referenziert und zählt nicht als unmapped.
• apps/api/docs/ enthält 4 Dateien (tax-engine.md, datev-integration.md, period-lock.md, storno-workflow.md). period-lock.md und storno-workflow.md könnten für AP1/AP6 relevante zusätzliche Belege enthalten.

Randbedingungen

• Nur Forschungsanteile identifizieren — keine Standard-Engineering-Aufgaben als AP verpacken
• Dreistufiger Frascati-Schnelltest für jeden Kandidaten:
  1. Wie-nicht-Was: Liegt die Schwierigkeit im Lösungsweg, nicht in der Aufgabenstellung?
  2. Unwägbarkeit: Gab es bei Projektstart keinen bekannten Lösungsansatz? (Wenn ein Standardverfahren existiert → kein F&E)
  3. Beleg: Existiert mindestens ein Artefakt (ADR, Protokoll, Code-Kommentar), das die Unsicherheit dokumentiert?
• Quellen-Pfade zu existierenden Belegen angeben
• Abgrenzung zu L2-H: STRATEGY_future-ideas.md und PRODUCT_differentiators-10-percent.md hier nur auf bereits existierende interne Artefakte prüfen — marktbasierte Chancen und externe Recherche gehören zu L2-H

---

L2-H: Markt- & Wissenschaftsanalyse — Chancen & Lücken

Scope

Externes Scanning: Welche förderfähigen Forschungsthemen ergeben sich aus dem Marktumfeld, akademischen Publikationen und technologischen Trends — die Busflow's Architektur adressieren könnte?

Nicht im Scope: Interne Dokumentation auswerten (→ L2-G), bestehende APs verbessern (→ L2-D/E/F).

Quelldokumente

• docs/product/PRODUCT_project-scope.md (Marktsegmente, Wettbewerber, Zielgruppen)
• docs/strategy/STRATEGY_platform-vision.md (Horizonte 2+3)
• docs/strategy/STRATEGY_future-ideas.md (visionäre Konzepte)
• docs/product/PRODUCT_differentiators-10-percent.md (§[future]-Features)
• docs/supporting/reference/bsfz-ablehnungsrisiken.md (§Muster A–D als Schablone)
• Externe Quellen: Web-Recherche zu Branchenlösungen, akademischen Publikationen, Technologie-Trends

Untersuchungsfragen

1. Wettbewerber-Analyse: Was bieten Kubus/Tourplan/Kuschick/Turista/SIO/RATIOsoftware, das technische Forschungsfragen aufwirft? Wo scheitern sie an Problemen, die Busflow als AP formulieren könnte?
2. Akademische Landschaft: Welche aktiven Forschungsfelder (z.B. Federated Learning, Machine Unlearning, GEO, Privacy-Preserving Analytics, Edge Computing, CRDTs) überlappen mit Busflows Architektur?
3. Technologie-Trends: Welche emergenten Technologien (Privacy Sandbox Evolution, WebGPU, Service Workers V2, Web Push V2) erzeugen neue Forschungsfragen für die Busflow-Plattform?
4. Branchenspezifische Lücken: Welche Probleme existieren in der Bus-Touristik-Branche, die kein Software-Anbieter löst und die als Forschungsfrage formulierbar sind?
5. Förderlandschafts-Scan (optional, falls Zeit): Gibt es neben FZulG weitere Förderprogramme (ZIM, INVEST, EXIST, EU-Programme), die für Busflow in Frage kommen? Wie interagieren sie mit der FZulG-Beantragung?
6. Chance-Bewertung: Für jede identifizierte Chance: Wie hoch ist der Aufwand zur AP-Formulierung, wie stark die Beweislage, wie groß das Ablehnungsrisiko?

Erwartete Ergebnisse

• Chancen-Katalog mit Bewertung (Aufwand × Ertrag × Risiko)
• Für die Top-5-Chancen: AP-Rohfassung im Katalog-Format
• Förderlandschafts-Übersicht mit Kompatibilitäts-Matrix
• Empfehlungen für Sofortmaßnahmen vs. langfristige Forschungsplanung

Akzeptanzkriterien

• Chancen-Katalog enthält min. 5 bewertete Chancen mit konkreter Aufwand/Ertrag/Risiko-Einschätzung
• Top-5-AP-Rohfassungen bestehen den Schnelltest: "Liegt die Schwierigkeit im Wie, nicht im Was?"
• Wettbewerber-Analyse basiert auf aktueller Web-Recherche, nicht auf Training-Wissen

Offene Hypothesen (L1)

• Wettbewerber-Landschaft: Direkte Legacy-Konkurrenten: Kuschick, Turista. Referenziert in Strategie/Produkt-Docs: Kubus, Tourplan, RATIOsoftware, SIO, Passolution (siehe PRODUCT_project-scope.md, PRODUCT_differentiators-10-percent.md). OTA-Referenzen: Bokun, GetYourGuide, Viator.
• 11 [future]-Features in Differentiators-Dok mit Forschungspotenzial: Algorithmic Feeder/Shuttle Manager (Clustering/Routing), Predictive Maintenance (IoT/OBD2), E-Mobility/ESG (EV-Routing mit Ladekurven, Topographie), Automated Bank Import (MT940/CAMT Matching), Computer Telephony Integration.
• Akademische Anknüpfungspunkte (aus AP-Katalog): Machine Unlearning (AP22), Federated Learning (AP20), GEO (AP21), CRDTs (AP18), Privacy-Preserving Analytics (AP23). Alle aktive Forschungsfelder mit SIGIR/VLDB/USENIX-Präsenz.

Randbedingungen

• Externe Recherche über Web-Suche durchführen — nicht auf veraltetes Training-Wissen vertrauen
• Chancen müssen zur Busflow-Architektur passen (Modular Monolith, Event-Driven, Multi-Tenant)
• Förderprogramm-Kompatibilität gegen Doppelförderungsverbot prüfen