L2-D Ergebnis — Detailanalyse Kern-APs AP1–AP6, AP7a, AP8, AP9

Status

• Scope: AP1–AP6, AP7a, AP8, AP9.
• Einschränkung: Dokumentenbasierte Analyse; keine vollständige Code-/Commit-Prüfung.
• Ziel: Frascati-Score, F&E-Split, Antragstext-Hinweise und Input für L2-C.

Frascati-Scorecard und F&E-Splits

AP	Neuartigkeit	Unwägbarkeit	Planmäßigkeit	F&E %	Standard %	Empfehlung
AP1 Tax Engine	hoch	hoch, aber Chronologie-Risiko	mittel-hoch	45	55	einreichen, aber ehrlich Chronologie markieren
AP2 Offline Sync	hoch	hoch	hoch	70	30	starkes Kern-AP
AP3 EU-561	hoch	hoch	mittel	65	35	einreichen, Beraterreview sinnvoll
AP4 Event/Multi-Tenant	mittel	mittel	hoch	55	45	nur Event/Saga/Audit-Trail-Anteile betonen
AP5 KI/IDP	hoch	hoch	mittel-hoch	70	30	stark, aber Scope gegen Catch-All absichern
AP6 Kalkulation	mittel	mittel nur mit AP1	hoch	45	55	nie isoliert beantragen
AP7a Broadcast	mittel	mittel	mittel	55	45	nur Error-Classification/Event-Cascade, keine Standard-Infra
AP8 Seat Hold	hoch	hoch	mittel	65	35	starkes Concurrency-AP
AP9 Agentic Governance	hoch	mittel-hoch	mittel	60	40	einreichbar als prospektive F&E-/Governance-Spec, Risiko offenlegen

AP-spezifische Befunde

AP1

Stärkstes Argument ist der gescheiterte Per-Variante-/Deferral-Ansatz mit juristisch-technischer Unmöglichkeit. Schwäche ist die Git-Chronologie: Problem und Lösung sind retrospektiv dokumentiert. Antrag sollte nicht behaupten, Git belege alle Iterationen; stattdessen technische Fehlannahme und offene Phase-3-Validierung als laufende Unwägbarkeit formulieren.

AP2

Sehr gute Frascati-Passung: Offline-Feldgeräte, Eventual Consistency und GoBD-Immutability erzeugen echten Zielkonflikt. Standard-Sync/RxDB-Anteile abgrenzen.

AP3

Cross-Tenant-Paradox ist stark. Sliding Window und Tachograph-Import sind Standard; Forschungsanteil liegt in source-agnostic Compliance bei mandantenübergreifenden Freelancern.

AP4

Dual-Layer-Isolation allein ist Standard. Förderkern: Cross-Context-Sagas, polymorpher Audit Trail, Event-Korrelation und Routing-Entscheidungen.

AP5

Stark, solange auf Zuverlässigkeit nicht-deterministischer LLM-Ausgaben bei ACID-/sicherheitskritischen Prozessen fokussiert. Booking-Mutation-Layer separat kritisch prüfen; könnte als Geschäftsregel-Implementierung wirken.

AP6

Förderfähigkeit hängt an AP1. Nicht als „Pricing Engine“ oder DDD-Refactoring framen, sondern als Pre-Tax-Pipeline-Layer unter nachträglicher Kosten-/Steuerunsicherheit.

AP7a

Nur der resiliente Broadcast bei eventgetriebenen Providerfehlern ist relevant; Rate Limiting, Circuit Breaker, Wallet-Updates sind Standard und bereits korrekt ausgeschlossen.

AP8

Starker technischer Kern: Concurrent Hold über Kanäle, Offline-Bordverkauf, Fahrzeugtausch und Realtime-Subscriptions. Antrag muss Race Conditions konkret beschreiben.

AP9

Konzeptionell/spec-basiert, aber als planmäßige F&E zulässig, wenn Experimente/Failure Modes der Agenten-Pipeline definiert werden. Risiko: „Management-Konzept“ statt IT-Forschung.

Antragstext-Verbesserungen

• AP1: „Das System muss steuerrelevante Aufteilungen berechnen, obwohl die dafür nötigen Ist-Kosten erst nach Leistungserbringung vorliegen.“
• AP3: „Mehrere Datenquellen mit unterschiedlicher Genauigkeit müssen zu einer mandantenübergreifenden Compliance-Aussage zusammengeführt werden, ohne Mandantenisolation zu brechen.“
• AP5: „LLM-Ausgaben werden nicht als Textfeature behandelt, sondern als potenziell fehlerhafte Eingaben in rechtlich/finanziell relevante State Machines.“
• AP6: „Die Preisversionierung ist nur förderrelevant, soweit sie die spätere Steuer-/Kostenzerlegung aus AP1 robust vorbereitet.“

Input für L2-C

AP	Go/No-Go	F&E %	Standard-Engineering %	schwächstes Frascati-Kriterium	Haupteinwand	Verteidigung	Beweislücke	Abhängigkeiten / Teilablehnungsrelevanz
AP1	Go mit Beraterreview	45	55	Planmäßigkeit/Chronologie	Lösung retrospektiv dokumentiert	Technische Fehlannahme und Phase-3-Deferral zeigen laufende Unwägbarkeit	frühere Code-/Schema-Spuren gescheiterter Ansätze	V1-Kern. Wenn AP1 fällt, AP6 nicht isoliert verteidigen; V1 müsste stark reduziert/neugefasst werden.
AP2	Go	70	30	keine starke Schwäche	Offline Sync ist bekannt	GoBD-Immutability plus physische Boarding-/Payment-Konflikte gehen über Standard-Sync hinaus	konkrete Konfliktfälle/Tests	V2-Kern; kann ohne AP3/AP7a bestehen und dient als Kohärenzanker für Offline-/Realtime-Konflikte.
AP3	Go mit Beraterreview	65	35	Neuartigkeit	EU-561-Regeln sind bekannt	Cross-Tenant-Freelancer-Paradox trotz Mandantenisolation ist ungelöst	Beispiel-Datensätze/Simulation	V2-Kern/Stütze; AP15 sollte nur als AP3-Erweiterung laufen, nicht standalone.
AP4	Go reduziert	55	45	Neuartigkeit	Multi-Tenant/RLS bekannt	Förderkern sind Cross-Context-Sagas und korrelierter Audit Trail	Saga-Prototyp/Failure Cases	V2-Stütze; bei Teilablehnung Standard-RLS/RBAC herausnehmen, Saga-/Audit-Anteile behalten.
AP5	Go	70	30	Scope-Schärfe	LLM-Integration ist verbreitet	Domänenkritische LLM-Ausgaben werden vor ACID-/Sicherheitsfolgen validiert	Messung Halluzination/Validierungsfehler	V3-Kern; AP9/AP27 dürfen AP5 nicht als Management-/Organisationskonzept verwässern.
AP6	Go nur mit AP1	45	55	Neuartigkeit	Pricing/DDD ist Standard	AP6 löst Pre-Tax-Pipeline für AP1, nicht isolierte Preislogik	Verzahnung AP1 im Antrag	Abhängig von AP1. Nicht isoliert beantragen; bei AP1-Schwäche AP6 kürzen oder als Standardanteil ausweisen.
AP7a	Go reduziert	55	45	Neuartigkeit	Broadcast/Retry ist Standard	Provider-spezifische Error-Klassifikation in Event-Cascades ist Forschungsanteil	Fehlerklassifikationsmatrix	Abgrenzung zu AP26 aus L2-E beachten: AP7a Zustellresilienz/Providerfehler, AP26 Trigger-/Timing-Semantik.
AP8	Go	65	35	Planmäßigkeit	Seat Holds sind bekannt	Offline/Online-Kanal- und Vehicle-Swap-Konflikte machen Race Conditions domänenspezifisch	Last-/Conflict-Tests	V2-Kern neben AP2; bei Teilablehnung AP2/AP4 als Minimum behalten.
AP9	Go mit Risiko	60	40	Planmäßigkeit/Belegreife	klingt nach Managementkonzept	Agenten-Pipeline mit Blast-Radius, MCP-Zugriff und Review-Gates ist IT-Systemforschung	Experimentplan, Metriken	V3-Stütze/prospektiv; AP27 setzt AP9 voraus, aber AP9 sollte nicht von AP27 abhängig gemacht werden.

Quellen- und Nachweisstatus D

Claim	Nachweisstatus
AP1/AP6 Tax-/Pricing-Verzahnung	bestehende Quellen: ADR-006, ADR-012, ADR-015; Antragstext V1 bsfz-antrag-vorhaben.md:22-87; AP-Katalog AP1/AP6 in funding-work-packages.md vor Zeile 122. Exakte Code-/Commit-Spuren fehlen noch.
AP2 Offline Sync	bestehende Quellen: ADR-017 und docs/3-resources/protocols/offline-sync-protocol.md; Formular V2 bsfz-antrag-vorhaben.md:98-166.
AP3 EU-561/Cross-Tenant	bestehende Quellen: docs/3-resources/reference/eu-561-compliance-research.md, docs/3-resources/protocols/dispatch-availability-engine.md; Beraterreview empfohlen.
AP4 Event/Multi-Tenant	bestehende Quellen: ADR-004, ADR-019, docs/3-resources/events/event-catalog.md; Standard-RLS/RBAC-Anteile sind inferred Standard-Engineering.
AP5/AP9 KI/Agentic Governance	bestehende Quellen: docs/2-areas/architecture/ai.md, ADR-020, docs/3-resources/protocols/mcp-agent-bridge.md, Formular V3 bsfz-antrag-vorhaben.md:177-253. Experiment-/Metrikplan fehlt.
AP7a Broadcast	bestehende Quelle: docs/3-resources/protocols/notification-pipeline-protocol.md; AP26-Abgrenzung siehe L2-E-result.md Abschnitt „AP26↔AP7a-Abgrenzung“.
AP8 Seat Hold	bestehende Quellen: ADR-013, docs/2-areas/architecture/realtime-strategy.md, docs/3-resources/schemas/schema-commerce.md; Last-/Conflict-Tests fehlen.

Validierungsbedarf

• AP1/AP3 rechtlich-fachlich durch FZulG-Berater prüfen.
• AP9 mit Experimentplan/Proof-of-Concept unterfüttern.
• Für AP5 Scope-Erweiterungen entscheiden, was Jahr 1 wirklich beantragt wird.