L2-G Ergebnis — Neue AP-Kandidaten / Dokumentations-Mining
Status
- Ausgeführt: Ja, als dokumentenbasierter Schnell-Drilldown auf Basis der vorhandenen Funding-, ADR-, Protokoll- und Architekturdateien.
- Einschränkung: Keine vollständige Codehistorie-/Commit-Forensik und keine vollständige inhaltliche Tiefenprüfung aller ADRs; die Bewertung ist konservativ und als Vorstufe für Detaildrilldowns D/E/F zu verstehen.
- ADR-Zählung korrigiert: Im aktuellen Repository wurden 30 ADR-Dateien unter
docs/3-resources/decisions/adr-*.mdgefunden.adr-026fehlt; die frühere Angabe „31 ADRs“ war nicht durch die Dateiliste gedeckt. - Primäre Quellen:
funding-work-packages.md,STRATEGY_public-funding.md,bsfz-ablehnungsrisiken.md, ADR-Liste unterdocs/3-resources/decisions/, Protokolle/Schemas unterdocs/3-resources/.
ADR-/Dokumentations-Scan — wichtigste Funde
| Fund | Einordnung | Förderrelevanz |
|---|---|---|
| ADR-027 Cardinality-Budget-Contract | stärkt AP12 | Belegt konkrete technische Hürde statt generischem Telemetry-Thema. |
| ADR-021 Customer Intelligence Context | stärkt AP20/AP25 | Belegt V4-Privacy-/Engagement-Kontext. |
| ADR-028 GDPR TTL Retention | stärkt AP20/AP22/AP23/AP27 | Privacy-/Löschsemantik als technische Unwägbarkeit. |
| ADR-023/024/025/031 Swarm/Infra | eher Standard-Engineering | Nur förderfähig, wenn messbare Forschungshypothese zu Resilienz/Cardinality/Observability vorliegt; sonst nicht als AP aufnehmen. |
| ADR-029 Secrets/Encryption | Standard-Security | Eher Beleg für Planmäßigkeit/Compliance, nicht eigener AP. |
| ADR-030 Subscription Tier Gating | Produkt-/Businesslogik | Nicht als F&E-AP empfehlen. |
Kandidatenbewertung
| Kandidat | Go/No-Go | Begründung | Empfehlung |
|---|---|---|---|
| AP10 FX Risk Engine | 🟡 Bedingt | Domain-Spannung plausibel, aber FX-Hedging ist bekannt. | Nur als Jahr-2-Kandidat oder eng mit Pricing/Costing koppeln. |
| AP11 Seat Re-Mapping | 🟢 Go | CSP mit bus-spezifischen Heuristiken und Vehicle-Swap-Kontext plausibel. | In V2 oder Folge-Vorhaben aufnehmen, falls Belege im Domain Model/Schema ausgebaut werden. |
| AP12 Telemetry Pipeline | 🟡 Go mit Einschränkung | ADR-027 macht technische Hürde konkret; Time-Series an sich Standard. | Als Infrastruktur-F&E nur mit Cardinality-Budget/Hasura-Reaktivitätsziel beantragen. |
| AP13 Border Manifests | 🟡 Bedingt | Risiko Template-/Compliance-Wahrnehmung. | Nur aufnehmen, wenn dynamische Mehrländer-Regelauflösung belegbar ist. |
| AP14 Dispatch Conflict | 🟢 Go | Verwandt mit V2-Concurrency; konkrete Race Conditions gut erklärbar. | Eher in V2 integrieren statt neues Vorhaben. |
| AP15 Crew Solver | 🟢 integriert / 🔴 standalone | CSP allein bekannt; EU-561-Integration stark. | In AP3/V2 integrieren. |
| AP16 Mobile Receipt OCR | 🟡 Bedingt | OCR Standard; Verification-State-Machine und Feldqualität können Forschung tragen. | Nur mit eigener Konfidenz-/Rejection-Loop-Argumentation. |
| AP17 Reseller Settlement | 🟡 Bedingt | Payment-Primitives bekannt; Clawback über Booking-State-Machine potenziell neu. | Eher Folgejahr, Belege aus Commerce-State-Machine sichern. |
| AP18 CRDT Planning | 🟡 nur falls CRDT | Ohne Yjs/Automerge o.ä. kein AP. | Bis Implementierungsentscheidung blockiert. |
| AP19 Passenger Offline Validation (CBOR/CWT/COSE) | 🟡 Bedingt/Go | Forschungsrichtung CBOR/CWT/COSE entschärft Wallet-Trivialisierung; AP2-Abhängigkeit stärkt V2-Kohärenz. | V2 optional; ADR + CWT-Claim-Schema-Spike ausstehend. |
| AP24 Field-Device Media Pipeline | 🟡 Bedingt | On-Device-ML ist harter Gate; sonst Upload-Pipeline. | Nur mit Edge-Quality-Scoring als AP. |
| AP25 Adaptive Feedback Engine | 🟡 Bedingt | Channel-Routing kann wie Geschäftsregel wirken; Sentiment domänenspezifisch stärker. | In V4 als Teil Customer Intelligence prüfen. |
| AP26 Lifecycle Communication | 🟡–🔴 Bedingt | „automatische E-Mails“ Risiko; Cross-Context-Orchestrierung ist Kern. | Nur als V2/V4-Brücke mit Event-Orchestrierung beantragen. |
| AP27 Domain-State PARA Derivation | 🟡 Go mit Scope-Klarheit | Neue maschinelle Taxonomie-Ableitung aus Entity-Lifecycles plausibel, aber PARA bekannt. | V3/AP9-nah aufnehmen; nicht als Organisationsmethodik framen. |
Input für L2-A
| Kandidat | empfohlenes Vorhaben | Alternative/fünftes Vorhaben | Clustering-Auswirkung | Stunden | Risiko | Jahr-1-Empfehlung |
|---|---|---|---|---|---|---|
| AP11 | V2 | Folge-Vorhaben Operations | stärkt V2-Concurrency, erhöht Breite moderat | 100 | niedrig-mittel | optional aufnehmen, wenn V2 nicht überladen wirkt |
| AP12 | V2/Infra-Querschnitt | Folge-Vorhaben Platform Reliability | kann V2 weiter überladen | 150 | mittel | eher zurückstellen oder als Beleg-Infrastruktur nutzen |
| AP14 | V2 | — | passt sehr gut zu V2 | 80 | niedrig | aufnehmen, falls V2-Stunden tragbar |
| AP15 | V2/AP3 | — | stärkt AP3 statt eigenes AP | 150 | niedrig integriert | in AP3 integrieren, nicht standalone |
| AP20–AP23 | V4 | — | V4 bleibt kohärent | 640 | mittel | als V4 nur mit Privacy-Kern einreichen |
| AP24 | V2 oder V4 | Folge-Vorhaben B2B2C Content | neue Operations→Commerce-Brücke | 120 | mittel | nur bei On-Device-ML |
| AP25 | V4 | Folge-Vorhaben Communications Intelligence | stärkt V4 Engagement | 100 | mittel | optional, wenn Sentiment-Forschung konkretisiert wird |
| AP26 | V2/V4 | fünftes Communications-Orchestration-Vorhaben | Brücke kann V2/V4 verwässern | 120 | mittel-hoch | zurückstellen oder nur mit starker Event-Orchestrierung |
| AP27 | V3 | — | stärkt V3/AP9 | 100 | mittel | aufnehmen als AP9-nahe Erweiterung |
ADR-Coverage-Tabelle
| ADR-Datei | Scan-Status | AP-Linkage / Kandidatenimplikation |
|---|---|---|
adr-001-boarding-point-strategy.md | gesichtet | Boarding-/Operations-Kontext; möglicher Beleg für AP2/AP19, kein eigener AP. |
adr-002-financial-ledger-strategy.md | gesichtet | Financial-Ledger-Kontext für AP1/AP6; stärkt Planmäßigkeit, kein neuer Kandidat. |
adr-003-tenant-provisioning.md | gesichtet | Tenant-Lifecycle/Provisioning; überwiegend Standard-Engineering. |
adr-004-tenant-isolation-strategy.md | gesichtet | Beleg für AP4/AP3-Mandantenisolation; Standardanteile abgrenzen. |
adr-005-multi-tenant-jwt-session.md | gesichtet | Security/Auth-Beleg; eher Standard, kein eigenständiger AP. |
adr-006-costing-pricing-separation.md | gesichtet | Stützt AP1/AP6 Costing/Pricing-Trennung. |
adr-007-crew-fleet-subcontracting-strategy.md | gesichtet | Stützt AP3/AP15 Crew-/Subcontracting-Kontext. |
adr-008-vehicle-maintenance-ownership.md | gesichtet | Fleet-Kontext; derzeit kein neuer AP. |
adr-009-booking-confirmed-trigger.md | gesichtet | Event-/Booking-Trigger; Beleg für AP4/AP26, allein Standard. |
adr-010-input-output-vo-separation.md | gesichtet | Pricing-Regel-Snapshot/VO-Kontext; stützt AP6. |
adr-011-input-rule-snapshotting.md | gesichtet | PriceMatrix-Snapshotting; stützt AP6/AP10, kein eigener AP. |
adr-012-toms-tax-deferral.md | gesichtet | Kritischer AP1-Beleg und Chronologie-Risiko. |
adr-013-seat-hold-ttl-alignment.md | gesichtet | Stützt AP8 und AP11 Seat-/Hold-Konflikte. |
adr-014-ticket-issuance-trigger.md | gesichtet | Ticket-/Trigger-Beleg; AP2/AP26-Kontext, allein Standard. |
adr-015-tax-ledger-entry-cardinality.md | gesichtet | Stützt AP1 TaxLedger-Cardinality. |
adr-016-incident-lifecycle-state-machine.md | gesichtet | Incident/Broadcast-Kontext; stützt AP7a/AP26-Abgrenzung. |
adr-017-offline-sync-protocol.md | gesichtet | Starker AP2-Beleg; AP19-Bezug durch CBOR/CWT/COSE-Credential-Versionierung gegen AP2-Manifest als Revocation-Orakel. |
adr-018-serviceleg-creation-ownership.md | gesichtet | Operations-/Leg-Kontext; möglicher AP14/AP15-Beleg. |
adr-019-change-events-polymorphic-audit-trail.md | gesichtet | Stützt AP4 Event-/Audit-Trail-Forschungsanteil. |
adr-020-agentic-company-governance.md | gesichtet | Stützt AP9 und AP27; Belegreife für Experimente fehlt. |
adr-021-customer-intelligence-context.md | gesichtet | Stützt AP20/AP25/V4. |
adr-022-ubicloud-postgres-cutover.md | gesichtet | Infrastruktur/Deployment; Standard-Engineering, kein AP. |
adr-023-swarm-quorum-topology.md | gesichtet | Infrastruktur; nur als Beleg/Planmäßigkeit, kein eigener AP ohne Hypothese. |
adr-024-swarm-lb-strategy.md | gesichtet | Infrastruktur/LB; Standardanteil, kein eigener AP. |
adr-025-swarm-manager-failover-dns.md | gesichtet | Infrastruktur/Failover; überwiegend Standard. |
adr-027-cardinality-budget-contract.md | gesichtet | Stützt AP12; konkrete technische Hürde Cardinality-Budget. |
adr-028-gdpr-ttl-retention.md | gesichtet | Stützt AP20/AP22/AP23/AP27 Privacy-/Retention-Semantik. |
adr-029-secrets-and-encryption.md | gesichtet | Security/Secrets; Standard-Security, kein F&E-AP. |
adr-030-subscription-tier-gating.md | gesichtet | Produkt-/Businesslogik; kein F&E-AP. |
adr-031-immutable-infrastructure-policy.md | gesichtet | Infrastruktur/Remote Access; Beleg für Planmäßigkeit, kein eigener AP. |
Abdeckungslücke: Alle 30 ADR-Dateien wurden als Dateiliste erfasst und grob klassifiziert. Der Status „gesichtet“ bedeutet keine vollständige Tiefenlektüre mit Zeilennachweisen. Für Hauptdokument-Edits sind die betroffenen ADRs pro AP nochmals line-genau zu zitieren.
Empfehlungen
- Keine pauschale Erweiterung auf alle Kandidaten. Das Maximum von ~4.270h ist als Obergrenze nutzbar, aber die Jahr-1-Submission sollte konservativ bleiben.
- V2 ist der Engpass. AP11/AP12/AP14/AP15/AP24/AP26 können V2 zu einem Sammelbecken machen. L2-A sollte V2-Split oder Integrationslogik explizit prüfen.
- AP27 ist stärkster neuer Kandidat aus G. Er ist bereits im AP-Katalog sauber abgegrenzt und passt zu V3/AP9.
- Infrastruktur-ADRs sind Belege, keine eigenen APs. Swarm/DNS/Secrets/Immutable Infrastructure sollten nur planmäßigkeits- oder unterstützend genutzt werden.
Validierungsbedarf
- Steuerberater/FZulG-Berater: Förderfähigkeit von Infrastrukturanteilen und prospektiven Kandidaten.
- Fachvalidierung: tatsächliche Implementierungsentscheidung für AP18/AP24. AP19-Forschungsrichtung (CBOR/CWT/COSE) identifiziert — ADR + Spike ausstehend.
- Code-/Git-Forensik: Belegstärke für Kandidaten mit „Codebasis-Validierung ausstehend“.