AP-Katalog: Forschungszulage

Zweck: Vollständiger Katalog der F&E-Arbeitspakete mit Forschungsfragen und Belegen. Kanonische Referenz für alle FZulG-Dokumente. Bezugsdokumente: STRATEGY_public-funding.md (Vorhaben-Clustering), bsfz-ablehnungsrisiken.md (Risikobewertung).

Status-Legende

• ✅ Validiert: ADRs/Protokolle existieren, Stundenaufwand belegbar
• 🟡 Kandidat: Domänenartefakt vorhanden, Codebasis-Validierung ausstehend
• ⚪ Entwurf: Konzeptionell, noch nicht im Code

---

AP1 — Margenbesteuerung & Tax-Decomposition Engine ✅

• Forschungsfrage: Wie lässt sich die juristisch restriktive Margenbesteuerung algorithmisch über verteilte Systeme abbilden, wenn die tatsächlichen Fremdleistungskosten und finalen Passagierzahlen zum Zeitpunkt der Preisberechnung unbekannt sind — und eine fehlerhafte Per-Variante-Steuerberechnung eine "legal fiction" ohne Grundlage im Steuerrecht erzeugt?
• Neuartigkeit: Keine Branchenlösung für automatische Eigenleistung/Fremdleistung-Diskriminierung mit departure-level Tax-Aggregation. Per-Variante Tax-Split war ungelöst — ADR-012 dokumentiert explizites Deferral als Designentscheidung unter Unsicherheit. Zusätzlich: ratio-basierter Drittlands-Split (§ 25 Abs. 2) mit EU/THIRD_COUNTRY-Margen-Aufteilung (tax-engine.md §Algorithmus), Mixed-Strategy-Departures mit 1:N TaxLedgerEntry-Kardinalität (ADR-015).
• Belege: ADR-006, ADR-012 (gescheiterter v1/v2 Ansatz), ADR-015 (1:N Cardinalitätswechsel für Mixed-Strategy), apps/api/docs/tax-engine.md (§ 25 Abs. 2 Algorithmus, § 25 Abs. 5 GoBD-Persistenz-Pflichtfelder)
• Stundenaufwand: ~400h (davon ~150–200h F&E: Strategy-Resolution, Drittlands-Split, Deferral-Architektur, GoBD-Persistenz-Design; ~200–250h Standard-Engineering: DATEV-Mapping, Mollie-Integration, Invoice-Rendering, Valibot-Validierung)

IMPORTANT

ADR-009 (BookingConfirmed = DEPOSIT_PAID) ist eine juristische Auslegungsentscheidung (§ 651a BGB), keine technische Forschung. ADR-009 nur als Beleg für Planmäßigkeit (formelle Architekturentscheidungen mit Phase-Gates) verwenden, nie als Beleg für Forschungsneuartigkeit.

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 ungetestet ist, belegt laufende Unwägbarkeit — das FZulG fördert den Forschungsprozess, nicht abgeschlossene Ergebnisse. Im Antragstext als offene Forschungsfrage darstellen.

CAUTION

Git-Chronologie zeigt retrospektive Dokumentation. Die vollständige Timeline:

Datum	Commit	Inhalt
2026-04-07	f1ebd58	tax-engine.md erstellt — enthält bereits den vollständigen § 25 Algorithmus, Drittlands-Split und Deferral-Architektur
2026-04-10	5cba21c	STRATEGIC_BLIND_SPOTS.md erstellt — SB-2 erscheint bereits als ✅ Resolved. ADR-012 im gleichen Commit erstellt
2026-04-13	b4428f0	Verzeichnis-Umbenennung der ADRs

Es existiert kein Git-Zustand, in dem SB-2 als offenes Problem existierte. Die Lösung (tax-engine.md) existierte 3 Tage vor der Problem-Dokumentation. Die in ADR-012 beschriebenen gescheiterten v1/v2-Iterationen sind in Git nicht nachweisbar.

Maßnahmen vor BSFZ-Einreichung:

1. Ältere Commits auf PriceMatrix/Tax-Felder durchsuchen — falls Spuren der gescheiterten Per-Variante-Berechnung vor dem 07.04. existieren, als Beleg sichern
2. Falls nicht: im Antragstext ehrlich darstellen, dass die formelle Dokumentation retrospektiv erfolgte, und auf die inhaltliche Iteration (v1/v2 in ADR-012) als Beleg setzen statt auf Git-Timestamps
3. Alternativ: Code-Iterationen der Tax-Felder in Schema-Dateien als Beleg heranziehen

AP2 — Offline-First Sync Protocol with GoBD Conformance ✅

• Forschungsfrage: Wie synchronisiert ein dezentrales System komplexe relationale Daten (Ticket-Scans, Bordverkäufe, Schadensmeldungen), wenn Busse stundenlang in Funklöchern operieren — und gleichzeitig die GoBD-Unveränderbarkeitsanforderung (AO §146) gewahrt bleiben muss, die im architektonischen Widerspruch zur Eventual Consistency steht? Zwei Operations-spezifische Unterfragen verschärfen das Problem:
  • Boarding-Validation offline: Was passiert, wenn die Driver App offline ein Ticket per QR-Scan validiert, das serverseitig zwischenzeitlich storniert wurde? Die lokale Datenbank kennt die Stornierung nicht. Server-Wins Conflict Resolution reicht hier nicht — der Fahrgast steht physisch im Bus.
  • Offline-Payment-Orchestrierung: Bordverkäufe (OnboardSale) erzeugen Checkout-Sessions über Payment-Links, die eine Server-Rückkopplung erfordern (checkout_session_id). Bei fehlender Konnektivität muss das System den Verkauf lokal erfassen und die Payment-Verknüpfung deferred herstellen — ein Eventual-Consistency-Problem mit finanzieller Auswirkung.
• Neuartigkeit: Differenzielles Sync-Protokoll (RxDB + custom NestJS batch API), server-wins Conflict Resolution, Idempotency-Deduplizierung via sync_idempotency_log lösen den Grundwiderspruch ohne Branchenpräzedenz. Die Boarding-Validation- und Offline-Payment-Szenarien erzeugen zusätzliche Invarianten-Konflikte, die über Standard-Offline-Sync hinausgehen.
• Belege: ADR-017, SYNC-1/CE-1/CE-2 audit findings; offline-sync-protocol.md, change_events mit Scope-Enums, BoardingEvent (Offline-Scan gegen stornierte Buchung), OnboardSale (deferred Payment-Link-Verknüpfung), schema-operations.md
• Stundenaufwand: ~150h

AP3 — EU-561 Compliance Engine & Dispatch Availability ✅

• Forschungsfrage: Wie berechnet man echtzeitfähig die hochkomplexen EU-561 Lenk- und Ruhezeiten (6 ineinandergreifende Regeln über gleitende 14-Tage-Fenster), wenn ein Fahrer als Freelancer für mehrere Betreiber fährt und die gesetzliche Ruhezeitbilanz mandantenübergreifend ist — das Multi-Tenant-Datenmodell aber nur die Daten eines einzigen Betreibers sieht?
• Neuartigkeit: Cross-Tenant-Freelancer-Problem ist branchenweit ungelöst. DutyActivity-Abstraktion mit polymorpher Quellenunterscheidung (TACHOGRAPH_IMPORT, SELF_DECLARATION, TOUR_LEG) und source-agnostic ComplianceEvaluator Domain Service als architektonische Antwort.
• Belege: eu-561-compliance-research.md §3.2 (drei ungelöste Lösungsansätze), dispatch-availability-engine.md
• Stundenaufwand: ~200h

AP4 — Event-Driven Multi-Tenant Architecture ✅

• Forschungsfrage: Wie koordiniert man Cross-Context-Sagas (z.B. Fahrzeugtausch über Operations + Commerce) mit lückenloser Audit-Trail-Korrelation, wenn vier strikt isolierte Bounded Contexts jeweils eigene change_events-Tabellen führen?
• Neuartigkeit: Dual-Layer Tenant Isolation (Hasura RBAC + Postgres RLS, fail-closed) kombiniert mit Cross-Context-Sagas, polymorphem Audit-Trail mit Correlation-IDs und Subscription-Multiplexing für Echtzeit-Dispatch architektonisch unerprobt bei Projektstart.
• Belege: ADR-004, ADR-019; change_events polymorphic model; event-catalog.md (40+ formal spezifizierte Domain Events über 4 Bounded Contexts mit Payload-Contracts und Cascade-Chains, z.B. VehicleSwapped → IncidentCreated → Communications broadcast); workflow-orchestration.md (4-Layer-Architektur: Hasura Events → XState → n8n → BullMQ mit expliziten Routing-Regeln — die Kombination und die Routing-Entscheidungslogik war bei Projektstart offen)
• Stundenaufwand: ~150h (vollständig Vorhaben 2)

NOTE

Ursprünglich 200h geschätzt. Reduziert auf 150h: Multi-Tenant-Grundlagenarbeit (RLS-Policies, RBAC-Matrix) ist Standard-Engineering. Die förderfähigen Anteile (Cross-Context-Sagas, polymorphes Audit-Trail-Design nach ADR-019, Event-Driven-Orchestrierung) sind in den 150h enthalten. AP4 gehört vollständig zu Vorhaben 2 (nicht mehr auf V1/V2 gesplittet).

AP5 — KI-gestützte Verarbeitung und Generierung domänenkritischer Inhalte ✅

• Forschungsfrage: Wie orchestriert man nicht-deterministische Sprachmodelle für Geschäftsprozesse, bei denen fehlerhafte Ausgaben rechtliche oder finanzielle Konsequenzen haben — über zwei Anwendungskontexte mit unterschiedlichen Fehlercharakteristiken: strukturelle Halluzinationen bei buchungskritischen Datenbankeinträgen und inhaltliche Halluzinationen bei sicherheitskritischen Passagiernachrichten?
• Neuartigkeit: LLM-Orchestrierung (Vercel AI SDK / LangChain.js) integriert mit Hasura Event Triggers für domain-spezifische Workflows. Halluzinationsrate in buchungskritischen Kontexten bei Projektstart unbekannt. Human-in-the-Loop-Mechanismus für sicherheitskritische Krisennachrichten.
• Belege: docs/architecture/ai.md, mcp-agent-bridge.md; validation-strategy.md (3-Layer Defense-in-Depth: Valibot als Anti-Corruption-Layer validiert untyped/unpredictable LLM-JSON vor ACID-Insertion — explizit für LLM-Safety entworfen); docs-hub.md §Context-Engine (Prototyp und Machbarkeitsstudie für spätere Product-AI: RAG-Pipeline-Evolution docs-assistant Nuxt-Monolith → context-engine Standalone-Server — 2 verworfene Architekturansätze dokumentiert; Gemini Embeddings + Claude SSE Streaming + Qdrant Vector Search); notification-pipeline-protocol.md, incident-broadcast-protocol.md (Krisennachrichten-Generierung)
• Stundenaufwand: ~345h (300h Dokumentenverarbeitung + 45h Krisennachrichten-Generierung, ex-AP7b)

NOTE

AP7b integriert: Die LLM-Krisennachrichten-Generierung (45h, ursprünglich Teil von AP7) teilt den Kern „LLM → strukturierte domänenkritische Ausgabe → Validierung" mit der Dokumentenverarbeitung. Unterschied ist der Fehlertyp (strukturell vs. inhaltlich), was die Forschungsfrage stärkt.

NOTE

[SCOPE-ERWEITERUNG] Knowledge-Graph-RAG (+50h): Phase-2-Vision in docs-hub.md §Knowledge Graph: Erweiterung von Flat-Vector-Search zu relationship-aware Knowledge Graph mit NER-Extraction, Community-Detection (Leiden/Louvain) und Graph-enriched RAG (BFS depth-1 Nachbar-Expansion). Algorithmisch neuartig — kein Standard-RAG-System.

NOTE

[SCOPE-ERWEITERUNG] Taxonomy-Aware Retrieval (+60h): Untersuchung von PARA-Kategorien (para_category: project|area|resource|archive) als maschinenlesbares Metadatensignal zur Steuerung von LLM-Retrieval-Qualität. Die context-engine speichert para_category bereits als Qdrant-Payload — nutzt das Signal aber nicht für Retrieval-Entscheidungen. Forschungsfrage: Wie disambiguiert ein RAG-System zwischen autoritativen Spezifikationen (resource) und archivierten Entwürfen (archive), wenn beide im Embedding-Raum ähnliche Vektoren erzeugen? Drei offene Strategien: harte Filter (nur resource-Chunks für Spec-Fragen), weiche Score-Multiplikatoren (PARA-Boost auf Similarity-Score), oder Kontextfenster-Ordnung (autoritative Chunks priorisiert im LLM-Prompt). Die Interaktion zwischen semantischer Ähnlichkeit und kategorialer Autorität hat keine Referenzimplementierung. Stärkt gleichzeitig AP9 (Agentic Governance): Agenten müssen unterscheiden, ob ein Dokument ein aktives Projekt (actionable) oder eine archivierte Entscheidung (Kontext) darstellt. Belege: context-engine/src/indexer/walker.ts (frontmatter-Extraktion), context-engine/src/search/vector-store.ts (Qdrant-Payload enthält frontmatter), context-engine/src/chat/rag.ts (Metadata-Injection in System-Prompt ohne Priorisierung), PARA-Frontmatter in 50+ Dokumenten.

NOTE

[SCOPE-ERWEITERUNG] Booking-Mutation-Layer (+100h): Policy-Enforcement-Layer zwischen LLM/Customer und Booking-State-Machine (Stornierungsfristen, Refund-Policies, Anzahlungsregeln). Erhöht das BSFZ-Risiko, weil es nach Geschäftsregel-Implementierung klingt. Separat beantragt nur, wenn die Argumentation als informationstechnologische Herausforderung (State-Machine-Invarianten-Enforcement über LLM-getriebene Mutationen) trägt. Andernfalls weglassen.

AP6 — Two-Phase Kalkulations- & Preisgestaltungs-Engine ✅ ⚠️

• Forschungsfrage: Wie entwirft man eine zustandslose Pricing-Engine, die dynamisch in Millisekunden Echtzeit-Kosten (Maut, Fremdleistungen) gegen unvorhersehbare Passagieränderungen aufrechnet — bei strikter Trennung von Costing (Fakten) und Pricing (Strategie) als unabhängige Entity-Lifecycles mit Immutable-Append-Versionierung?
• Neuartigkeit: Costing↔Pricing-Trennung mit Immutable-Append-Versionierung auf PriceMatrix, N:1 Channel-Preismatrizen mit applied_conditions[] Audit-Trail, automatische Contribution-Margin-Validation. ADR-006 dokumentiert gescheiterten JSONB-Hack als Erstversuch.
• Belege: ADR-006 (gescheiterter JSONB-Hack Erstversuch), ADR-009 (nur Planmäßigkeit, nicht Neuartigkeit); kalkulations-engine.md, price-matrix-variant-spec.md
• Stundenaufwand: ~200h

WARNING

Isoliert dünn — AP1-Abhängigkeit. AP6 allein ist ein DDD-Refactoring (Entity-Trennung) mit Immutable-Append-Versionierung — beides Lehrbuchwissen. ADR-006 als einziger Beleg reicht nicht. Die Förderfähigkeit hängt vollständig an der Verzahnung mit AP1: Eine versionierte Preis-Entity, die korrekte Verkaufspreise liefern muss, obwohl die Tax-Decomposition zum Generierungszeitpunkt nicht berechenbar ist. AP6 darf nie ohne AP1-Kontext eingereicht werden. Im Antragstext AP6 als „Pre-Tax-Pipeline-Layer" framen, nicht als eigenständige Kalkulations-Engine.

AP7 — Crisis Communication Pipeline & Wallet Pass Updates ✅ [AUFGELÖST]

WARNING

AP7 wurde aufgelöst. Die Forschungsanteile verteilen sich wie folgt:

• AP7b → AP5 (45h, Vorhaben 3): LLM-Krisennachrichten-Generierung, Halluzinationsschutz, Human-in-the-Loop. Integriert in AP5 als zweiter Anwendungskontext.
• AP7a (65h, Vorhaben 2): Event-Driven Broadcast-Resilience — provider-spezifische Error Classification (transient vs. permanent), Event-Cascade-Orchestrierung über mandantenübergreifende Infrastruktur.
• Nicht beantragt (40h): Standard-Infrastruktur (Token-Bucket Rate Limiting, Circuit Breaker, Wallet Pass Updates) — bewusst als nicht förderfähig klassifiziert.

• Ursprüngliche Forschungsfrage: Wie orchestriert man nicht-deterministische LLMs in sicherheitskritischen Krisenszenarien (Verspätungs-Broadcasts an Hunderte Fahrgäste), ohne dass der KI-Agent halluziniert, DSGVO-Verstöße begeht oder autonome Entscheidungen ohne Human-in-the-Loop durchschleust?
• Belege: notification-pipeline-protocol.md, incident-broadcast-protocol.md, CPaaS adapter error classification table
• Stundenaufwand: 150h → 110h beantragt (65h AP7a + 45h in AP5)

AP8 — Real-Time Seat Map with Concurrent Hold Management ✅

• Forschungsfrage: Wie sperrt und verwaltet eine relationale Datenbank physische Ressourcen (spezifische Sitzplätze), wenn Hunderte Nutzer gleichzeitig auf ein Widget zugreifen, parallel ein Fahrer offline Bordverkäufe tätigt, und im Hintergrund ein Flottentausch stattfinden könnte — und wie garantiert man konfliktfreie Neuzuweisung über Subscription-basierte Echtzeit-Synchronisation?
• Neuartigkeit: Concurrent Seat-Hold-Synchronisation über heterogene Verkaufskanäle (Web, Telefon, Driver App) via Hasura GraphQL Subscriptions mit optimistic UI reconciliation. Offline-First Driver App muss Bordverkäufe und Sitzzuweisungen ohne Konnektivität abwickeln.
• Belege: realtime-strategy.md, schema-commerce.md (capacity hold model), ADR-013 (Seat Hold TTL alignment)
• Stundenaufwand: ~150h

AP9 — Agentic Company Governance ⚪

• Forschungsfrage: Kann ein Solo-Founder ein SaaS-Unternehmen operativ mit KI-Agenten statt menschlichen Mitarbeitern führen — und wie verhindert man, dass sich Fehler in einer mehrstufigen Agenten-Pipeline (Self-Review → Supervisor → Founder) kaskadierend ausbreiten, wenn kein vergleichbares Referenzsystem existiert?
• Neuartigkeit: Governance-Modell für AI-Agents als "virtual workforce" über Engineering, Product, Marketing, Strategie. Bounded-Context-scoped Agent Access Control via MCP, dreistufige Review-Pipeline, Blast-Radius-Klassifikation, cross-session Domain Knowledge via .knowledge.md. Kein vergleichbares System existiert.
• Belege: agentic-led-company-spec.md (383-line spec), ADR-020, mcp-agent-bridge.md
• Stundenaufwand: ~100h

---

Neue Kandidaten (Codebasis-Validierung ausstehend)

AP10 — Multi-Currency FX Risk Engine 🟡

• Forschungsfrage: Wie modelliert man FX-Volatilitätspuffer für Touristikpakete, wenn Verkauf, Lieferantenzahlung und Endabrechnung Monate auseinanderliegen?
• Neuartigkeit: Touren in Nicht-Euro-Ländern (Tschechien, UK, Schweiz) erfordern Hedging-Strategien für Lieferantenzahlungen in Fremdwährung. Keine Branchenreferenz für Touristik-spezifisches Multi-Currency-Hedging.
• Belege: CostingSheet.fx_risk_buffer, Allotment.currency (Domain Model erwähnt explizit)
• Stundenaufwand: ~150h

AP11 — Seat Re-Mapping Algorithm 🟡

• Forschungsfrage: Wie weist man N Reservierungen mit Präferenzinvarianten (Fenster, Gang, Familiengruppen, Barrierefreiheit) algorithmisch konfliktfrei einem neuen Sitzplan zu, wenn ein Fahrzeugtausch erfolgt?
• Neuartigkeit: Constraint-Satisfaction-Problem mit Multi-Constraint-Optimierung. Domain-spezifische Heuristiken für Bus-Layouts (vs. Flugzeug-Layouts).
• Belege: Domain Model: "When a vehicle swap occurs, reservations are re-mapped to equivalent seat positions"
• Stundenaufwand: ~100h

AP12 — High-Frequency Telemetry Pipeline 🟡

• Forschungsfrage: Wie kombiniert man hochfrequente Zeitreihen-Ingestion (~30M GPS-Datenpunkte/Tag bei 100 Fahrzeugen) mit Hasura-Subscription-Reaktivität, ohne PostgreSQL-Cardinality zu sprengen?
• Neuartigkeit: TimescaleDB-Integration mit Hasura ist nicht trivial; Echtzeit-Dispatch-Subscriptions parallel zu langfristiger Analytics-Speicherung mit unterschiedlichen Konsistenzanforderungen.
• Belege: TelemetryPoint Entity, RouteWaypoint ETA tracking; ADR-027 Cardinality-Budget-Contract (Custom-CI-Linter: jede Prometheus-Metrik muss cardinality_budget-Annotation tragen, promtool check rules + check_metric_cardinality.py lehnen unkontrollierte Metriken auf PR-Ebene ab — Hardcap ≤80.000 active series, 4.000 Tenants × 20 series)
• Stundenaufwand: ~150h

AP13 — Cross-Border Compliance Manifests 🟡

• Forschungsfrage: Wie generiert man routenabhängig länderspezifische Compliance-Manifeste, wenn jedes Zielland eigene Datenanforderungen hat und sich diese ad-hoc ändern (Brexit, neue Schengen-Regeln)?
• Neuartigkeit: Routenabhängige Konfiguration der Pflichtdaten mit länderspezifischen Format- und Sprachanforderungen. Keine Branchenlösung für Mehrländer-Compliance.
• Belege: Domain Model unterscheidet Primary Billing Contact vs. Accompanying Travelers explizit für Border Manifests
• Stundenaufwand: ~100h

AP14 — Concurrent Dispatch Conflict Resolution 🟡

• Forschungsfrage: Wie löst man gleichzeitige Ressourcen-Allokation in einem Subscription-basierten UI mit lokalem Optimismus, ohne den User mit Datenbank-Constraint-Errors zu konfrontieren?
• Neuartigkeit: Optimistic-UI-Reconciliation mit Domain-Event-Replay statt naivem Constraint-Error-Handling.
• Belege: Domain Model: "multi-dispatcher conflict resolution" via assigned_at timestamp
• Stundenaufwand: ~80h

AP15 — Crew Workforce Constraint Solver 🟡

• Forschungsfrage: Wie löst man Crew-Assignment unter sechs gleichzeitigen Hard/Soft-Constraints (EU-561, Qualifikationen, Abwesenheiten, Präferenzen, Ruhezeiten, Verfügbarkeit)?
• Neuartigkeit: Constraint-Satisfaction-Solver mit EU-561-Awareness. Bei Reframing als "EU-561-aware Solver" enge Verbindung zu AP3 — möglicherweise dort integriert beantragen.
• Belege: dispatch-availability-engine.md (210 Zeilen Spec)
• Stundenaufwand: ~150h

AP16 — Mobile Receipt OCR Pipeline 🟡

• Forschungsfrage: Wie extrahiert man strukturierte Buchungsdaten (Netto, USt-Satz, Lieferant) aus mobilen Belegfotos heterogener Quellen mit produktionstauglicher Konfidenzbewertung?
• Neuartigkeit: Mobile-Capture mit schlechter Bildqualität, mehrsprachigen Tankquittungen aus 8+ Ländern, BullMQ-Worker-Pipeline mit Dispatcher-Verification-Loop. Distinkt von AP5 (das Dokumente verarbeitet, nicht Fotos).
• Belege: ExpenseReceipt Entity mit OCR-Pipeline (PENDING → PARSED → VERIFIED), replaces_receipt_id für Rejection-Loop
• Stundenaufwand: ~120h

AP17 — Reseller Multi-Party Settlement 🟡

• Forschungsfrage: Wie modelliert man konditionale Refund-Clawbacks über Multi-Party-Settlements, wenn die ursprüngliche Zahlung bereits an mehrere Parteien (Operator, Agentur, Plattform) ausgekehrt wurde?
• Neuartigkeit: Mollie Marketplaces liefert Primitives, aber Orchestrierung über Booking-State-Machine mit konditionalen Clawback-Semantiken nicht trivial.
• Belege: Domain Model: Reseller, Mollie-Marketplaces-Integration; XState-Booking-State-Machine (idle → selecting → confirming → paid → ticketed) mit formalisiertem Lifecycle — Clawback-Semantiken operieren auf State-Transitions (ADR-016 Incident-Lifecycle-Pattern übertragbar)
• Stundenaufwand: ~100h

AP18 — CRDT-Based Collaborative Trip Planning 🟡

• Forschungsfrage: Wie integriert man Conflict-free Replicated Data Types (Loro/Yjs) in eine Multi-Tenant-SaaS-Architektur für kollaborative Reiseplanung, wenn die Lösung gleichzeitig (1) eine konsistente relationale Projektion aus opakem CRDT-Zustand ableiten, (2) referentielle Integrität (FK-Constraints) in einem konfliktfreien Merge-Modell erzwingen, (3) einen GoBD-konformen Audit-Trail aus einem DAG gleichzeitiger Operationen derivieren, (4) den Übergang von kontinuierlichem CRDT-Zustand zu diskreten Geschäfts-Lifecycles (Entwurf → Veröffentlicht → Gesperrt) ermöglichen und (5) semantische Konflikte (gleichzeitige Umordnung, Löschen-während-Bearbeitung) für nicht-technische Disponenten verständlich darstellen muss?
• Neuartigkeit: Kein CRDT-Framework adressiert die Kombination aus Multi-Tenant-Isolation (Mandantenisolation auf Operationsebene), relationaler Projektion mit FK-Validierung und GoBD-Audit-Trail. Akademische CRDT-Forschung (Kleppmann et al., IEEE TPDS 2022) löst Tree-Move-Operationen, aber nicht die Integration in mandantenübergreifende SaaS-Architekturen mit gesetzlichen Aufbewahrungspflichten.
• Unwägbarkeiten:
  1. Projektionsservice: Debounced doc.toJSON() → JSON-Diff → transaktionaler SQL-Write. Offene Fragen: Write-Amplification bei hochfrequenten Edits, Drift-Erkennung zwischen CRDT-Blob und relationaler Projektion, Verhalten bei Projektionsfehler (Stale-State-Recovery)
  2. FK-Constraint-Validierung: Der CRDT speichert Lieferanten-Referenzen als UUID-Strings ohne Integritätsprüfung. Kaskadierung (Lieferant gelöscht während CRDT-Dokument aktiv bearbeitet wird) ist ein offenes Problem
  3. GoBD-Audit über CRDT: Audit-Einträge werden aus dem Projektions-Diff (nicht aus Roh-CRDT-Operationen) abgeleitet. Attributionsmodell für Merge-Events (mehrere Nutzer → ein Diff-Eintrag) erfordert ein Operations-Journal im Gateway
  4. Versionierungslifecycle: CRDTs kennen kein "fertig". Die Brücke zwischen kontinuierlichem Merge und diskretem Publish (Loro frontiers()-Checkpoints) hat keine Referenzimplementierung
  5. Semantische Konflikt-UX: CRDTs lösen Datenkonflikte, nicht Intentionskonflikte. Domain-spezifische Konfliktszenarios (gleichzeitige Stop-Umordnung, Löschen-während-Bearbeitung) erfordern UX-Forschung
• Belege: ADR-032 Collaborative Trip Planning (Dual-Layer-Architektur, Technologiebewertung Loro/Yjs/Automerge, Projektionsservice, Versionierungslifecycle, GoBD-Auditmodell), ADR-004 (Mandantenisolation), ADR-019 (Audit-Trail-Pattern), Kleppmann et al. "A highly-available move operation for replicated trees" (IEEE TPDS, 2022)
• Stundenaufwand: ~220h (Phase 1 Spike: 40h, Phase 2 Multi-Tenant + Projektion: 80h, Phase 3 Versionierung + GoBD: 60h, Phase 4 Semantische Konflikt-UX: 40h)

IMPORTANT

Vorhaben-2-Integration: AP18 gehört zu V2 (Datenkonsistenz über Vertrauensgrenzen). Die Forschungsfrage teilt V2's Kernthema (verteilte Datenkonsistenz), nutzt aber einen fundamental anderen Mechanismus (mathematischer CRDT-Merge statt Server-Wins-Konfliktlösung). ADR-032 dokumentiert den Hasura-LWW-Ansatz als Produkt-Fallback — die CRDT-Architektur ist ein explizites Forschungsrisiko.

AP19 — Passenger-Side Offline Credential Validation (CBOR/CWT/COSE) 🟡

• Forschungsfrage: Wie lassen sich IETF-standardisierte kryptographische Credentials (CBOR/CWT/COSE — RFC 8949, RFC 9052, RFC 8392), die im EU Digital COVID Certificate für statische Zertifikate erprobt wurden, auf mutable Buchungszustände in Offline-First-Touristik-Operationen erweitern — wenn sowohl Credential-Inhaber (Passagier) als auch Verifier (Fahrer) unter intermittierender Konnektivität operieren und die Buchung (Sitz, Fahrzeug, Leistungen) nach Credential-Ausstellung serverseitig mutieren kann?
• Neuartigkeit: EU DCC bewies den CBOR/CWT/COSE-Stack für statische Gesundheitszertifikate. Busflow-Buchungen sind mutable State Machines — der Credential-Inhalt (Sitz, Fahrzeug, Leistungsumfang) ändert sich nach Ausstellung. Ein mutationsgewahres CWT-Lifecycle-Management mit Credential-Versionierung, gekoppelt an ein offline-synchronisiertes Fahrermanifest (AP2) als Revocation-Orakel, hat keine Referenzimplementierung in Tourismus/Transport. Distinkt zu AP2 (write-heavy Driver-Side Sync) und AP7a (Event-Driven Broadcast-Resilience).
• Belege: IETF RFC 8392 (CWT), RFC 9052/9053 (COSE), RFC 8949 (CBOR); EU DCC Architektur als Precedent für statische Credentials; offline-sync-protocol.md (AP2-Manifest als Revocation-Orakel); W3C Bitstring Status List (alternatives Revocation-Modell)
• Stundenaufwand: ~120h

IMPORTANT

Vorhaben-2-Integration: AP19 gehört thematisch zu V2 (Datenkonsistenz über Vertrauensgrenzen) als passagierseitiges Gegenstück zu AP2 (fahrerseitig). Die credential_version-Abgleichung gegen das AP2-Manifest schafft eine direkte technische Abhängigkeit. Kernunsicherheiten: (1) optimale CWT-TTL für Mehrtagestouren unter intermittierender Konnektivität, (2) „Double-Offline"-Konsistenzproblem wenn sowohl Credential als auch Manifest veraltet sind, (3) CWT-JS-Ökosystem-Reife (@auth0/cose + cbor-x, aber kein dominantes CWT-Library), (4) QR-Code-Kapazität unter Feldbedingungen bei vollem Buchungszustands-Claimset.

---

Commerce-Kandidaten (Vorhaben 4)

Ablehnungsrisiken und Argumentationsmuster siehe bsfz-ablehnungsrisiken.md §Wackelkandidaten 5–6 und §Muster D.

AP20 — Privacy-First 360° Customer Profile 🟡

• Forschungsfrage: Wie aggregiert man ein verhaltensbasiertes Kundenprofil (Buchungsfrequenz, Lifetime Value, Sitzpräferenz, Churn-Risk) aus event-sourced Signalen vier unabhängiger Bounded Contexts — bei gleichzeitiger DSGVO-Konformität (Zweckbindung, Datensparsamkeit, Löschkaskaden) — ohne dass die Anonymisierung die analytische Nutzbarkeit zerstört?
• Neuartigkeit: Kein Standard-CDP passt auf Bus-Touristik (Multi-Tenant, branchenspezifische Metriken). Der architektonische Widerspruch (GDPR Art. 5(1)(c) Datensparsamkeit ↔ analytische Vollständigkeit) hat keine Branchenreferenz. Das bestehende Tombstone-Pattern (GDPR-Strategy) löst Löschung operativer Daten, aber das Verhalten eines aggregierten BehaviorAggregate nach Löschkaskaden bleibt offen — ein gelöschter Passagier beeinflusst weiterhin trainierte Modelle und Kohorten-Statistiken.
• Belege: ADR-021 (Customer Intelligence Context), gdpr-strategy.md (Tombstone-Architektur), Differentiators §1 (360° Customer Profile)
• Stundenaufwand: ~250h

AP21 — AI-SEO / Generative Engine Optimization 🟡

• Forschungsfrage: Wie strukturiert man dynamisch generierte Reise-Landingpages so, dass sie sowohl von klassischen Crawlern (Googlebot, schema.org) als auch von LLM-basierten Retrieval-Systemen (AI Overviews, Perplexity Citations) korrekt indiziert und zitiert werden — wenn die beiden Paradigmen widersprüchliche Anforderungen an Content-Granularität und Markup stellen?
• Neuartigkeit: GEO (Generative Engine Optimization) ist ein akademisch aktives Forschungsfeld (Aggarwal et al., 2023). Dual-optimierte Landingpages aus strukturierten Tourdaten (CostingSheet → PriceMatrix → Landing Page) erfordern eine Content-Pipeline mit ungelösten Qualitätsfragen. Branchenspezifische Schema.org-Erweiterungen (BusTrip, TouristTrip) in LLM-Retrieval-Kontexten ungetestet.
• Belege: Codebasis-Validierung ausstehend
• Stundenaufwand: ~120h

AP22 — Consent-Aware Recommendation Engine 🟡

• Forschungsfrage: Wie trainiert man ein kollaboratives Empfehlungssystem ("Passagiere, die Nordsee buchten, buchten auch Ostsee") auf Multi-Tenant-Daten, wenn jeder Mandant eigene Consent-Policies hat, Passagiere jederzeit widerrufen können, und das Modell bei Widerruf nicht einfach "vergessen" kann — weil der Beitrag eines einzelnen Nutzers in einem trainierten Modell nicht isolierbar ist? Zusätzlich erfordern demographisch-adaptive Empfehlungen (Altersstruktur, Mobilitätseinschränkungen, Gruppenkomposition) domänenspezifische Feature-Engineering-Entscheidungen ohne Branchenreferenz.
• Neuartigkeit: Machine Unlearning ist ein aktives Forschungsfeld (Bourtoule et al., "Machine Unlearning", IEEE S&P 2021). Kein Touristik-System hat ein Consent-Aware-Recommendation-System. Die Multi-Tenant-Dimension (Operator A hat Consent, Operator B nicht) fügt eine in der Literatur nicht adressierte Schicht hinzu. Cold-Start-Problem im B2B2C-Tourismus-Nischensegment: die Datenbasis für klassische Collaborative-Filtering-Ansätze ist zu dünn, und demographisch-adaptive Empfehlungen (Altersstruktur 60+, Mobilitätseinschränkungen, Gruppenkomposition) erfordern domänenspezifisches Feature Engineering.
• Belege: Codebasis-Validierung ausstehend
• Stundenaufwand: ~150h

AP23 — Privacy-Preserving Conversion Analytics 🟡

• Forschungsfrage: Wie misst und optimiert man einen Buchungs-Funnel (Impression → Checkout → Confirmation) ohne Third-Party-Cookies und ohne Cross-Site-Tracking — wenn Privacy-Sandbox-APIs (Topics, Attribution Reporting) noch instabil sind und die Busflow-Booking-Widgets als iFrames auf Operator-Websites eingebettet laufen?
• Neuartigkeit: Das Widget-auf-Drittseite-Problem (Same-Origin-Policy, ITP, Storage-Partitioning) erzeugt informationstechnologische Unsicherheit. First-Party-Analytics in einem embeddable Widget mit Multi-Tenant-Isolation hat keine Referenzimplementierung. Privacy-Sandbox-APIs ändern sich quartalsweise — die Architektur muss API-agnostisch bleiben.
• Belege: Codebasis-Validierung ausstehend
• Stundenaufwand: ~120h

AP24 — Field-Device Media Pipeline mit On-Device Quality Scoring & Consent Management 🗃️ [BACKLOG]

• Forschungsfrage: Wie nutzt man Feldgeräte (Driver Hub PWA) als Quelle für Produktimpressionen und Reisedokumentation, wenn die Bildqualität auf mobilen Endgeräten unter Feldbedingungen variiert, die DSGVO-konforme Einwilligung (Recht am eigenen Bild) pro Aufnahme inline erfasst werden muss, und die resultierenden Assets automatisiert in Produktbeschreibungen und Kommunikationskanäle fließen?
• Neuartigkeit: On-Device Quality Scoring (TensorFlow.js/ONNX im PWA-Kontext) für Feldgeräte unter Zeitdruck. Personen-Erkennung → DSGVO-Consent-Abfrage inline im Capture-Prozess. Multi-Channel Content-Syndikation: ein Foto → Produktbeschreibungs-Update, Kommunikationskanal-Assets, Social-Media-Entwürfe. Verwandt mit AP16 (Mobile Receipt OCR), aber distinkte Pipeline (Marketing-Assets statt Buchungsbelege).
• Belege: IssueReport.attachments (Photo-Upload-Pipeline existiert), Nhost Storage, Driver Hub PWA, schema-operations.md §Offline Photo Upload Protocol
• Stundenaufwand: ~120h

NOTE

🗃️ BACKLOG (2026-05-04): AP24 wurde bewusst zurückgestellt. Der Ansatz bleibt interessant, aber die harte Abhängigkeit zu On-Device ML (TensorFlow.js/ONNX im PWA-Kontext) erfordert einen dedizierten Feasibility-Spike, bevor das AP in die aktive Pipeline zurückkehren kann. Ohne Edge-Quality-Scoring reduziert sich das AP auf eine Standard-Upload-Pipeline ohne F&E-Relevanz. Wiederaufnahme frühestens nach erfolgreicher Technologieentscheidung und Prototyp-Validierung.

AP25 — Adaptive Multi-Channel Feedback Engine mit Domain-Specific Sentiment Analysis ⚪

• Forschungsfrage: Wie stellt ein automatisierter Dienst sicher, dass Post-Trip-Feedback über den effektivsten Kanal zugestellt wird — wenn die Zielgruppe (überwiegend 60+) heterogene digitale Kompetenzen aufweist, die Kanalpräferenz pro Kontakt variiert, und das System ohne manuellen Dispatcher-Eingriff den Zugang garantieren muss? Wie korreliert man die resultierenden Feedback-Daten mit Buchungs- und Operationsdaten, um domänenspezifische Insights (Fahrer-Bewertung, Unterkunft, Programm) zu generieren?
• Neuartigkeit: Adaptive Channel-Routing: automatische Kanal-Selektion (WhatsApp, E-Mail, Wallet-Pass-Push, SMS, Briefpost) basierend auf gelernter ChannelPreference, Informationstyp und Demografie — ohne manuellen Dispatcher-Eingriff. Domain-spezifische Sentiment-Analyse über Freitextantworten mit touristik-spezifischen Kategorien (Fahrer, Unterkunft, Reiseprogramm). Closed-Loop-Integration: Survey → EngagementScore → automatische Re-Engagement-Trigger.
• Belege: ADR-021 (EngagementScore, ChannelPreference), Communications-Kontext (NotificationTemplate), STRATEGY_future-ideas.md
• Stundenaufwand: ~100h

AP26 — Communication Decision Engine (Cross-Context Event Conflict Resolution) ⚪

• Forschungsfrage: Wie trifft ein ereignisgesteuertes Kommunikationssystem deterministische Zustellentscheidungen, wenn geplante Trigger (Cron-basierte Erinnerungen, Commerce-Sweeps) und reaktive Ereignisse (Operations-Vorfälle, Fahrzeugwechsel, Stornierungen) aus vier isolierten Bounded Contexts zeitlich kollidieren — ohne die Kontextgrenzen des modularen Monolithen aufzulösen und ohne einen dedizierten Orchestrierungsserver (Temporal/Camunda) einzusetzen?
• Neuartigkeit: Zwei Kern-Primitiven und eine bedingte Erweiterung für die Kommunikationssteuerung in kontextisolierten Systemen ohne dedizierten Orchestrierungsserver: (1) Supersession Rule [Forschungskern] — Verdrängungslogik mit Ereignis-Prioritätshierarchie (Storno > Incident > Verspätung > Erinnerung), die ausstehende Zustellungen annulliert und deren Kontext in die verdrängende Nachricht überträgt. Erfordert cross-workflow state awareness, BullMQ-Job-Annullierungs-Atomarität und Kontextweiterleitung — kein Standardmuster existiert. (2) Freshness Gate — kontextübergreifende Gültigkeitsprüfung vor Zustellung geplanter Nachrichten. Forschungsrelevant nur für 2 von 7 Szenarien (C5, C12), bei denen echte Cross-BC-Lesezugriffe erforderlich sind; die übrigen 5 sind Standard-Engineering. (3) Coalescing Window [bedingt] — zeitfensterbasierte Zusammenführung semantisch zusammengehöriger Ereignisse; nur relevant falls der einfachere domänenseitige Ansatz (composite rebookPassenger Action) nicht ausreicht.
• Belege: adr-033-communication-decision-engine.md (Architekturentscheidung), notification-pipeline-protocol.md (4-Layer-Architektur, 22 Trigger Events), incident-broadcast-protocol.md (Edge State E-1), event-catalog.md (53 Domain Events über 4 BCs), booking-lifecycle-protocol.md (Booking-Zustandsmaschine), cancellation-protocol.md (Storno-Saga), vehicle-swap-protocol.md (VehicleSwapped Event), workflow-orchestration.md (Boundary Rules — n8n/Temporal-Einschränkungen)
• Stundenaufwand: 95–115h (4 Phasen: Supersession Rule Spike 45h, Freshness Gate 35h, Coalescing Window 20h bedingt, Integration Testing 15h)

NOTE

Frascati-Bewertung nach Forschungssession (2026-05-04): Neuartigkeit 🟢 (drei benannte Primitiven ohne Referenzimplementierung); Unwägbarkeit 🟢 (fünf konkrete technische Unsicherheiten: BC-Isolation vs. Frischeprüfung, Zeitfenster-Dimensionierung, Informationsverlust bei Verdrängung, BullMQ-Job-Annullierungs-Atomarität, Auditierbarkeit negativer Entscheidungen); Planmäßigkeit 🟢 (ADR-033, Konflikt-Testmatrix mit 5 Szenarien, 4-Phasen-Meilensteinplan, Evaluationsmetriken). Vorheriges Ablehnungsrisiko 🟡–🔴 entschärft durch Fokussierung auf Cross-Context-Konfliktauflösung statt "automatische E-Mails." Empfehlung: Jahr-2-Pipeline mit V2-Zuordnung (Distributed Data Consistency).

AP27 — Domain-State PARA Derivation für KI-Kontextpriorisierung ⚪

• Forschungsfrage: Wie leitet ein KI-System aus den domäneneigenen Lifecycle-Zuständen einer Multi-Tenant-Touristik-Plattform automatisch eine Wissenstaxonomie (PARA: Projects, Areas, Resources, Archive) ab, die LLM-Retrieval-Priorisierung und Agenten-Routing steuert — wenn die Zuordnungsregeln entitätsübergreifend, kontextabhängig und durch gesetzliche Aufbewahrungspflichten (GoBD) verkompliziert sind?
• Neuartigkeit: PARA (Forte, 2017) existiert als manuelle Wissensmanagement-Methodik für Individuen. Die automatische Ableitung von PARA-Kategorien aus domäneneigenen Entity-Lifecycle-Zuständen (TourDeparture.PUBLISHED → Project, TourTemplate.ACTIVE → Resource, FinancialLedger.CLOSED → Archive) zur Steuerung von LLM-Kontext-Priorisierung hat keine Referenzimplementierung. Drei offene Probleme: (1) Duale Kategorie-Zugehörigkeit — ein TourTemplate ist gleichzeitig Resource (als Planungsblaupause) und Container für Projects (seine zukünftigen Departures); (2) Übergangs-Timing — wann wird ein Departure zu Archive: bei COMPLETED-Status, bei FinancialLedger.CLOSED, oder bei Ablauf der GoBD-Aufbewahrungsfrist?; (3) Cross-Entity-PARA-Vererbung — ein Booking auf einer abgeschlossenen Departure ist Archive, aber der verknüpfte PassengerProfile bleibt Area (laufendes CRM), und das BoardingEvent speist aktive BehaviorAggregates in Customer Intelligence.
• Belege: PRODUCT_domain-model.md (Entity-Lifecycle-Definitionen über vier Bounded Contexts: TourDeparture.status, Booking.status, TourTemplate.status, PriceMatrix.status, FinancialLedger.status, Incident.status), agentic-led-company-spec.md §4 (Proactive Task Surfacing — Agenten müssen aktive von archivierten Entitäten unterscheiden), gdpr-strategy.md (Tombstone-Architektur beeinflusst Archive-Semantik), workflow-orchestration.md (Event-Trigger-Routing operiert auf Lifecycle-Transitions)
• Stundenaufwand: ~100h

NOTE

Abgrenzung zu AP5 Taxonomy-Aware Retrieval: AP5-TAR nutzt para_category-Frontmatter in Dokumentation für RAG-Retrieval-Priorisierung. AP27 leitet PARA-Kategorien aus Produkt-Daten-Lifecycles ab — der KI-Agent fragt nicht "welches Dokument ist autoritativ?", sondern "welche Geschäftsentität ist aktuell handlungsrelevant?". AP27 setzt AP9 (Agentic Governance) voraus: Agenten benötigen eine priorisierte Weltsicht, um proaktiv Aufgaben zu identifizieren (§4 Proactive Task Surfacing).

WARNING

BSFZ-Ablehnungsrisiko: 🟡. Die Forschungsfrage muss auf die informationstechnologische Herausforderung fokussieren (automatische Taxonomie-Ableitung aus Entity-Zustandsmaschinen, Cross-Entity-Vererbungslogik, GoBD-beeinflusste Archive-Semantik), nicht auf PARA als Organisationsmethodik. Der Gutachter könnte PARA als bekannte Methodik abtun — die Argumentation muss zeigen, dass die maschinelle Ableitung und Konsumption der Taxonomie aus verteilten Domain-Zuständen das Forschungsproblem ist, nicht die Taxonomie selbst.

---

Stundenübersicht

Status	APs	Stunden
✅ Validiert (Kern V1–V3)	AP1, AP2, AP3, AP4, AP5 (inkl. AP7b), AP6, AP7a, AP8, AP9	1.760h
✅ + Scope-Erweiterung	AP5 Booking Mutations	+100h
✅ + Scope-Erweiterung	AP5 Knowledge-Graph-RAG	+50h
✅ + Scope-Erweiterung	AP5 Taxonomy-Aware Retrieval	+60h
🟡 Kandidaten (Operations/Infra)	AP10–AP17, AP19 + AP18 (ADR-032)	1.290h
🟡 Kandidaten (Commerce/V4)	AP20–AP23	640h
⚪ Neue Kandidaten (Operations/Comms)	AP25–AP26	220h
🗃️ Backlog	AP24	120h
⚪ Neuer Kandidat (AI/V3)	AP27	100h
Maximum/Obergrenze		~4.340h

IMPORTANT

~4.340h ist die kanonische Maximum-Obergrenze aller APs inkl. Scope-Erweiterungen, AP27 und AP24–AP26. Sie ist nicht die empfohlene Jahr-1-Submission. Für Jahr 1 bilden die Kern-Vorhaben V1–V3 (1.660h–2.170h) die belastbare Basis. Kandidaten und Scope-Erweiterungen jenseits dieses Kerns bilden die Folgejahres-Pipeline und dienen als Gesprächsgrundlage für den Steuerberater, damit dieser den Gesamtumfang des F&E-Vorhabens einschätzen kann. Falls der Berater neue Erkenntnisse liefert, können APs zwischen Jahr 1 und Folgejahren verschoben werden. AP18 (220h statt zuvor 150h) trägt +70h bei.

NOTE

Kern-Stunden V1–V3: AP1(400) + AP2(150) + AP3(200) + AP4(150) + AP5(345, inkl. 45h ex-AP7b) + AP6(200) + AP7a(65) + AP8(150) + AP9(100) = 1.760h. AP4 auf 150h (Multi-Tenant-Grundlagen Standard-Engineering, Event-Driven-Orchestrierung Forschungsanteil). AP7 aufgelöst: LLM-Anteil (45h) in AP5 integriert, Broadcast-Resilience (65h) als AP7a, 40h Standard-Infra bewusst nicht beantragt. AP9 ist konzeptionell (⚪), aber die Spezifikationsarbeit (383-Zeilen-Spec, ADR-020, MCP-Protokoll) ist eigenständige F&E-Planungsleistung. Scope-Erweiterungen AP5: Booking Mutations (+100h), Knowledge-Graph-RAG (+50h), Taxonomy-Aware Retrieval (+60h). AP27 (Domain-State PARA Derivation, 100h) als eigenständiges AP unter V3 — leitet PARA-Kategorien aus Entity-Lifecycle-Zuständen ab. Commerce-Kandidaten (AP20–AP23, 640h) als Vorhaben 4. AP24–AP26 (340h) adressieren die B2B2C-Dimension: Field-Device Media Pipeline (Operations), Adaptive Feedback Engine (Communications/Customer Intelligence), Proactive Lifecycle Communication (Cross-Cutting). Vorhaben-Zuordnung offen.

NOTE

Infrastruktur-Stunden: Forschungsbedingt notwendige Infrastrukturarbeit (Multi-Tenant-Isolation, Observability-Stack, Docker-Swarm-Architektur für verteilte Systeme) wird proportional auf die APs verteilt, die diese Infrastruktur voraussetzen (AP2, AP4, AP7a, AP8, AP12). Abgrenzung zu allgemeiner DevOps durch Berater klären.

Vorhaben-Zuordnung und finanzielle Erwartung siehe STRATEGY_public-funding.md.