284 lines
18 KiB
Markdown
284 lines
18 KiB
Markdown
---
|
||
doc_type: roadmap
|
||
audience: product_owner, developer
|
||
status: active
|
||
version: 2.8.0
|
||
context: "Aktuelle Planung für kommende Features (ab WP16), Release-Strategie und Historie der abgeschlossenen WPs."
|
||
---
|
||
|
||
# Mindnet Active Roadmap
|
||
|
||
**Aktueller Stand:** v2.8.0 (Post-WP20/WP76)
|
||
**Fokus:** Visualisierung, Exploration & Cloud-Resilienz.
|
||
|
||
## 1. Programmstatus
|
||
|
||
Wir haben mit der Implementierung des Graph Explorers (WP19), der Smart Edge Allocation (WP15) und der hybriden Cloud-Resilienz (WP20) die Basis für ein intelligentes, robustes System gelegt. Der nächste Schritt (WP19a) vertieft die Analyse, während WP16 die "Eingangs-Intelligenz" erhöht.
|
||
|
||
| Phase | Fokus | Status |
|
||
| :--- | :--- | :--- |
|
||
| **Phase A** | Fundament & Import | ✅ Fertig |
|
||
| **Phase B** | Semantik & Graph | ✅ Fertig |
|
||
| **Phase C** | Persönlichkeit | ✅ Fertig |
|
||
| **Phase D** | Interaktion & Tools | ✅ Fertig |
|
||
| **Phase E** | Maintenance & Visualisierung | 🚀 Aktiv |
|
||
|
||
---
|
||
|
||
## 2. Historie: Abgeschlossene Workpackages
|
||
|
||
Eine Übersicht der implementierten Features zum schnellen Auffinden von Funktionen. Details siehe `99_legacy_workpackages.md`.
|
||
|
||
| WP | Titel | Ergebnis / Kern-Feature |
|
||
| :--- | :--- | :--- |
|
||
| **WP-01** | Knowledge Design | Definition von `types.yaml` und Note-Typen (Project, Concept, etc.). |
|
||
| **WP-02** | Chunking Strategy | Implementierung von Sliding-Window und Hash-basierter Änderungserkennung. |
|
||
| **WP-03** | Import-Pipeline | Asynchroner Importer, der Markdown in Qdrant (Notes/Edges) schreibt. |
|
||
| **WP-04a**| Retriever Scoring | Hybride Suche: `Score = Semantik + GraphBonus + TypGewicht`. |
|
||
| **WP-04b**| Explanation Layer | Transparenz: API liefert "Reasons" (Warum wurde das gefunden?). |
|
||
| **WP-04c**| Feedback Loop | Logging von User-Feedback (JSONL) als Basis für Learning. |
|
||
| **WP-05** | RAG-Chat | Integration von Ollama (`phi3`) und Context-Enrichment im Prompt. |
|
||
| **WP-06** | Decision Engine | Hybrid Router unterscheidet Frage (`RAG`) vs. Handlung (`Interview`). |
|
||
| **WP-07** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-08** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-09** | Interview-Assistent | One-Shot Extraction: Erzeugt Markdown-Drafts aus User-Input. |
|
||
| **WP-10** | Web UI | Streamlit-Frontend als Ersatz für das Terminal. |
|
||
| **WP-10a**| Draft Editor | GUI-Komponente zum Bearbeiten und Speichern generierter Notizen. |
|
||
| **WP-11** | Backend Intelligence | `nomic-embed-text` (768d) und Matrix-Logik für Kanten-Typisierung. |
|
||
| **WP-15** | Smart Edge Allocation | LLM-Filter für Kanten in Chunks + Traffic Control (Semaphore) + Strict Chunking. |
|
||
| **WP-19** | Graph Visualisierung | **Frontend Modularisierung:** Umbau auf `ui_*.py`.<br>**Graph Engines:** Parallelbetrieb von Cytoscape (COSE) und Agraph.<br>**Tools:** "Single Source of Truth" Editor, Persistenz via URL. |
|
||
| **WP-20** | **Cloud Hybrid Mode & Resilienz** | **Ergebnis:** Integration von OpenRouter (Mistral 7B) & Gemini 2.5 Lite. Implementierung von WP-76 (Rate-Limit Wait) & Mistral-safe JSON Parsing. |
|
||
| **WP-21** | Semantic Graph Routing & Canonical Edges | Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?"). |
|
||
| **WP-22** | **Content Lifecycle & Registry** | **Ergebnis:** SSOT via `01_edge_vocabulary.md`, Alias-Mapping, Status-Scoring (`stable`/`draft`) und Modularisierung der Scoring-Engine. |
|
||
|
||
### 2.1 WP-22 Lessons Learned
|
||
* **Architektur:** Die Trennung von `retriever.py` und `retriever_scoring.py` war notwendig, um LLM-Context-Limits zu wahren und die Testbarkeit der mathematischen Formeln zu erhöhen.
|
||
* **Kanten-Validierung:** Die Edge Registry muss beim Start explizit initialisiert werden (Singleton), um "Lazy Loading" Probleme in der API zu vermeiden.
|
||
|
||
### 2.2 WP-20 Lessons Learned (Resilienz)
|
||
* **Quoten-Management:** Die Nutzung von Free-Tier Modellen (Mistral/OpenRouter) erfordert zwingend eine intelligente Rate-Limit-Erkennung (HTTP 429) mit automatisierten Wartezyklen, um Batch-Prozesse stabil zu halten.
|
||
* **Parser-Robustheit:** Cloud-Modelle betten JSON oft in technische Steuerzeichen (`<s>`, `[OUT]`) ein. Ein robuster Extraktor mit Recovery-Logik ist essentiell zur Vermeidung von Datenverlust.
|
||
|
||
---
|
||
|
||
## 3. Offene Workpackages (Planung)
|
||
|
||
### WP-08 – Self-Tuning v1/v2 (geplant)
|
||
Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
|
||
**Phase:** B/C
|
||
**Status:** 🟡 geplant (Nächster Fokus)
|
||
|
||
**Ziel:** Aufbau eines Self-Tuning-Mechanismus, der auf Basis von Feedback-Daten (WP-04c) Vorschläge für Retriever- und Policy-Anpassungen macht.
|
||
|
||
**Umfang:**
|
||
- Auswertung der JSONL-Feedback-Daten.
|
||
- Regel-basierte Anpassungs-Vorschläge für `retriever.yaml` und Typ-Prioritäten.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Hoch
|
||
- Komplexität: Hoch
|
||
|
||
### WP-09 – Vault-Onboarding & Migration (geplant)
|
||
|
||
**Phase:** B
|
||
**Status:** 🟡 geplant
|
||
|
||
**Ziel:** Sicherstellen, dass bestehende und neue Obsidian-Vaults schrittweise in mindnet installiert werden können – ohne Massenumbau.
|
||
|
||
**Umfang:**
|
||
- Tools zur Analyse des Vault-Status.
|
||
- Empfehlungen für minimale Anpassungen.
|
||
|
||
**Aufwand / Komplexität:**
|
||
- Aufwand: Mittel
|
||
- Komplexität: Niedrig/Mittel
|
||
|
||
### WP-15b – Candidate-Based Edge Validation & Inheritance
|
||
**Phase:** B/E (Refactoring & Semantic)
|
||
**Status:** 🚀 Startklar (Ersatz für WP-15 Logik)
|
||
**Ziel:** Ablösung der fehleranfälligen "Open-End-Extraktion" durch eine KI-gestützte Validierung menschlicher Vorarbeit zur Steigerung von Speed, Integrität und semantischer Tiefe.
|
||
|
||
**Herausforderung:**
|
||
Der bisherige WP-15 Ansatz litt unter Halluzinationen (erfundene Kantentypen), hohem Token-Verbrauch und dem Verlust physikalisch gesetzter Kanten bei der Chunk-Verteilung.
|
||
|
||
**Anforderungen & Strategie:**
|
||
1. **Hard-Link Integrity:** Kanten, die im Markdown-Text eines Chunks stehen, werden zwingend und ohne LLM-Prüfung gesetzt (`provenance: explicit`).
|
||
2. **Edge Inheritance:** Kanten, die auf Dokument-Ebene (Frontmatter) oder Sektions-Ebene (Heading) definiert sind, werden automatisch an alle zugehörigen Sub-Chunks vererbt, wenn ein semantischer Block aufgrund von Größengrenzen geteilt wurde.
|
||
3. **Candidate Pool Extraction:** Definition eines "Edge-Pools" pro Dokument. Dieser speist sich aus dem Frontmatter und einer speziellen Sektion (z. B. `### Unzugeordnete Kanten`).
|
||
4. **Semantic Validation Gate:** Das LLM fungiert als binärer Validator. Es prüft ausschließlich Kanten aus dem Kandidaten-Pool gegen den konkreten Chunk-Inhalt UND eine Zusammenfassung der Ziel-Note (Inhalt, Typ, Kanten-Typ).
|
||
5. **Registry Enforcement:** Strikte Blockade von Halluzinationen. Nur Kanten, die im Pool definiert UND im `edge_vocabulary.md` vorhanden sind, werden zugelassen.
|
||
|
||
**Lösungsskizze:**
|
||
* **Parser-Update:** `extract_candidate_pool` zur Identifikation aller im Dokument beabsichtigten Links.
|
||
* **Chunker-Update:** Implementierung einer `propagate_edges`-Logik für "by_heading" und "sliding_window" Strategien.
|
||
* **Ingestion-Update:** Umstellung von `_perform_smart_edge_allocation` auf einen binären Validierungs-Prompt (VALID/INVALID).
|
||
|
||
### WP-19a – Graph Intelligence & Discovery (Sprint-Fokus)
|
||
**Status:** 🚀 Startklar
|
||
**Ziel:** Vom "Anschauen" zum "Verstehen". Deep-Dive Werkzeuge für den Graphen.
|
||
* **Discovery Screen:** Neuer Tab für semantische Suche ("Finde Notizen über Vaterschaft") und Wildcard-Filter.
|
||
* **Filter-Logik:** "Zeige nur Wege, die zu `type:decision` führen".
|
||
* **Chunk Inspection:** Umschaltbare Granularität (Notiz vs. Chunk) zur Validierung des Smart Chunkers.
|
||
|
||
### WP-14 – Review / Refactoring / Dokumentation
|
||
**Status:** 🟡 Laufend (Phase E)
|
||
**Ziel:** Technische Schulden abbauen, die durch schnelle Feature-Entwicklung (WP15/WP19) entstanden sind.
|
||
* **Refactoring `chunker.py`:** Die Datei ist monolithisch geworden (Parsing, Strategien, LLM-Orchestrierung).
|
||
* *Lösung:* Aufteilung in ein Package `app/core/chunking/` mit Modulen (`strategies.py`, `orchestration.py`, `utils.py`).
|
||
* **Dokumentation:** Kontinuierliche Synchronisation von Code und Docs (v2.8 Stand).
|
||
|
||
### WP-16 – Auto-Discovery & Intelligent Ingestion
|
||
**Status:** 🟡 Geplant
|
||
**Ziel:** Das System soll "dumme" Textdateien beim Import automatisch analysieren, strukturieren und anreichern, bevor sie gespeichert werden.
|
||
**Kern-Features:**
|
||
1. **Smart Link Enricher:** Automatisches Erkennen von fehlenden Kanten in Texten ohne explizite Wikilinks. Ein "Enricher" scannt Text vor dem Import, findet Keywords (z.B. "Mindnet") und schlägt Links vor (`[[Mindnet]]`).
|
||
2. **Structure Analyzer (Auto-Strategy):**
|
||
* *Problem:* Manuelle Zuweisung von `chunking_profile` in `types.yaml` ist starr.
|
||
* *Lösung:* Vorschalten einer Analysestufe im Importer (`chunker.py`), die die Text-Topologie prüft und die Strategie wählt.
|
||
* *Metrik 1 (Heading Density):* Verhältnis `Anzahl Überschriften / Wortanzahl`. Hohe Dichte (> 1/200) -> Indikator für `structured_smart_edges`. Niedrige Dichte -> `sliding_smart_edges`.
|
||
* *Metrik 2 (Variance):* Regelmäßigkeit der Abstände zwischen Headings.
|
||
3. **Context-Aware Hierarchy Merging:**
|
||
* *Problem:* Leere Zwischenüberschriften (z.B. "Tier 2") gingen früher als bedeutungslose Chunks verloren oder wurden isoliert.
|
||
* *Lösung:* Generalisierung der Logik aus WP-15, die leere Eltern-Elemente automatisch mit dem ersten Kind-Element verschmilzt ("Tier 2 + MP1"), um den Kontext für das Embedding zu wahren.
|
||
|
||
### WP-17 – Conversational Memory (Gedächtnis)
|
||
**Status:** 🟡 Geplant
|
||
**Ziel:** Echte Dialoge statt Request-Response.
|
||
* **Tech:** Erweiterung des `ChatRequest` DTO um `history`.
|
||
* **Logik:** Token-Management (Context Window Balancing zwischen RAG-Doks und Chat-Verlauf).
|
||
|
||
### WP-18 – Graph Health & Maintenance
|
||
**Status:** 🟡 Geplant (Prio 2)
|
||
**Ziel:** Konsistenzprüfung ("Garbage Collection").
|
||
* **Feature:** Cronjob `check_graph_integrity.py`.
|
||
* **Funktion:** Findet "Dangling Edges" (Links auf gelöschte Notizen) und repariert/löscht sie.
|
||
|
||
### WP-13 – MCP-Integration & Agenten-Layer
|
||
**Status:** 🟡 Geplant
|
||
**Ziel:** mindnet als MCP-Server bereitstellen, damit Agenten (Claude Desktop, OpenAI) standardisierte Tools nutzen können.
|
||
* **Umfang:** MCP-Server mit Tools (`mindnet_query`, `mindnet_explain`, etc.).
|
||
|
||
### WP-21 – Semantic Graph Routing & Canonical Edges
|
||
**Status:** 🟡 Geplant
|
||
**Ziel:** Transformation des Graphen von statischen Verbindungen zu dynamischen, kontextsensitiven Pfaden. Das System soll verstehen, *welche* Art von Verbindung für die aktuelle Frage relevant ist ("Warum?" vs. "Was kommt danach?").
|
||
**Problem:**
|
||
1. **Statische Gewichte:** Aktuell ist `caused_by` immer gleich wichtig (z.B. 1.2), egal ob der User nach Ursachen oder Definitionen fragt.
|
||
2. **Vokabular-Zwang:** Der Nutzer muss exakte System-Begriffe (`caused_by`) verwenden. Natürliche Synonyme (`führt_zu`, `ausgelöst_durch`) werden als unbekannte Kanten ignoriert oder nicht speziell gewichtet.
|
||
|
||
**Lösungsansätze & Kern-Features:**
|
||
1. **Canonical Edge Mapping (Middleware):**
|
||
* Einführung einer Mapping-Schicht (z.B. in `edges.yaml`).
|
||
* *Funktion:* Normalisiert User-Vokabular (`leads_to`, `triggers`, `starts`) automatisch auf System-Typen (`caused_by`).
|
||
* *Benefit:* Maximale Schreibfreiheit für den Nutzer bei gleichzeitiger System-Konsistenz.
|
||
2. **Dynamic Intent Boosting (Query-Time):**
|
||
* Erweiterung der `Decision Engine`.
|
||
* *Funktion:* Der Router erkennt den Intent der Frage (z.B. `EXPLANATION` für "Warum-Fragen") und injiziert temporäre `edge_weights` in den Retriever.
|
||
* *Beispiel:* Bei "Warum ist das passiert?" wird `caused_by` von 1.2 auf 2.5 geboostet, während `related_to` auf 0.1 sinkt.
|
||
3. **Graph Reasoning:**
|
||
* Der Retriever priorisiert Pfade, die dem semantischen Muster der Frage entsprechen, nicht nur dem Text-Match.
|
||
|
||
### WP-22 – Content Lifecycle & Meta-Configuration
|
||
**Status:** ✅ Fertig (v2.7.0)
|
||
**Ziel:** Professionalisierung der Datenhaltung durch Einführung eines Lebenszyklus und "Docs-as-Code" Konfiguration.
|
||
**Lösungsansätze:**
|
||
1. **Status-Logik (Frontmatter):** `stable` vs. `draft` Scoring Modifier.
|
||
2. **Single Source of Truth (SSOT):** Die Registry nutzt `01_edge_vocabulary.md` als führende Konfiguration.
|
||
3. **Self-Learning Loop:** Protokollierung unbekannter Kanten in `unknown_edges.jsonl`.
|
||
|
||
### WP-23: Agentic Multi-Stream Reasoning (Mindnet 2025)
|
||
|
||
#### 1. Zielsetzung & Problemstellung
|
||
Das bisherige System basiert auf einem globalen Scoring-Modell, bei dem Notizen unterschiedlicher Typen (z. B. `insight` vs. `belief`) in einem einzigen Retrieval-Topf konkurrieren. Dies führt dazu, dass leiser gewichtete, aber fundamentale Identitätsmerkmale oft durch hochgewichtete aktuelle Erkenntnisse verdrängt werden. Ziel dieses Pakets ist die Einführung einer parallelen **Stream-Architektur**, um die Vielschichtigkeit menschlicher Entscheidungsprozesse (Werte + Erfahrung + Absicht) im LLM-Kontext zu garantieren.
|
||
|
||
#### 2. Funktionsbeschreibung: Die Streams
|
||
Die Daten aus der `types.yaml` werden in drei logische Verarbeitungseinheiten unterteilt:
|
||
|
||
##### A. Identity Stream (Die Wahrheitsebene)
|
||
* **Inhalt:** `value`, `belief`, `trait`, `principle`, `need`, `boundary`, `bias`.
|
||
* **Zweck:** Definition des moralischen Kompasses, der psychologischen Grundbedürfnisse und kognitiven Muster.
|
||
* **Wirkung:** Liefert das "Warum" hinter jeder Handlung.
|
||
|
||
##### B. History Stream (Die Evidenzebene)
|
||
* **Inhalt:** `experience`, `event`, `source`, `journal`, `person`.
|
||
* **Zweck:** Bereitstellung empirischer Belege aus der Vergangenheit und sozialer Kontexte.
|
||
* **Wirkung:** Verankert die Antwort in real erlebten Mustern und Fakten.
|
||
|
||
##### C. Action Stream (Die Dynamikebene)
|
||
* **Inhalt:** `project`, `decision`, `goal`, `task`, `risk`, `motivation`, `habit`, `state`.
|
||
* **Zweck:** Analyse der aktuellen Richtung, geplanter Vorhaben und des gegenwärtigen Zustands.
|
||
* **Wirkung:** Liefert den Kontext für die Umsetzung und zukünftige Ziele.
|
||
|
||
|
||
#### 3. Technische Wirkungsweise (Solution Sketch)
|
||
|
||
##### Schritt 1: Query-Decomposition
|
||
Ein initialer Klassifizierungs-Agent analysiert die Nutzeranfrage und bestimmt, welcher Stream primär angesprochen werden muss (z. B. "Wie soll ich mich entscheiden?" boostet den Identity Stream).
|
||
|
||
##### Schritt 2: Parallel Stream Retrieval
|
||
Anstelle einer Suche werden drei unabhängige Vektor-Suchen mit Typ-Filtern durchgeführt:
|
||
* **Search_A (Identity):** Top-5 Ergebnisse aus Identitäts-Notizen.
|
||
* **Search_B (History):** Top-5 Ergebnisse aus biografischen/externen Notizen.
|
||
* **Search_C (Action):** Top-5 Ergebnisse aus operativen/strategischen Notizen.
|
||
|
||
##### Schritt 3: Agentic Synthesis (The Reasoning)
|
||
Ein Synthese-Agent (LLM) erhält die aggregierten Ergebnisse in getrennten Sektionen. Die Anweisung lautet:
|
||
1. **Prüfung:** Steht das aktuelle Vorhaben (Action) im Einklang mit den Werten (Identity)?
|
||
2. **Abgleich:** Welche vergangenen Erfahrungen (History) stützen oder widersprechen diesem Weg?
|
||
3. **Korrektur:** Identifiziere mögliche Biases oder Grenzüberschreitungen (Boundary).
|
||
|
||
|
||
|
||
#### 4. Erwartete Ergebnisse
|
||
* **Höhere Resonanz:** Antworten wirken authentischer, da sie explizit auf das Wertesystem des Nutzers Bezug nehmen.
|
||
* **Widerspruchs-Erkennung:** Das System kann den Nutzer aktiv warnen, wenn ein Projekt gegen seine `principles` oder `needs` verstößt.
|
||
* **Robustes Retrieval:** Wichtige Identitäts-Informationen gehen nicht mehr im "Rauschen" von hunderten Journal-Einträgen verloren.
|
||
---
|
||
|
||
### WP-24 – Proactive Discovery & Agentic Knowledge Mining
|
||
**Status:** 🚀 In Planung (Nächster Architektur-Sprung)
|
||
**Ziel:** Transformation von Mindnet von einem reaktiven Archiv zu einem aktiven Denkpartner. Das System soll aktiv Wissenslücken schließen und verborgene Querverbindungen in großen Vaults sowie in Chat-Dialogen aufspüren.
|
||
|
||
**Herausforderung:**
|
||
1. **Silo-Effekt:** Bei wachsenden Vaults vergisst der Nutzer existierende Notizen und erstellt redundante Inhalte ohne Verknüpfung.
|
||
2. **Insight-Verlust:** Im Chat entstehen wertvolle Synthesen, die momentan im flüchtigen Chat-Log vergraben bleiben.
|
||
|
||
**Lösungsskizze & Strategie:**
|
||
|
||
#### A. Proactive Discovery (Vault-Scanning)
|
||
Das System nutzt die existierende `candidate_pool` Logik aus WP-15b, befüllt diese jedoch automatisiert:
|
||
* **Vector Similarity Search**: Beim Import einer Note (oder als periodischer Hintergrundprozess) sucht der neue `RecommenderService` in Qdrant nach den Top-X semantisch ähnlichsten Chunks im gesamten Vault.
|
||
* **Auto-Injection**: Diese Funde werden automatisch als `related_to` Kandidaten in den `candidate_pool` der neuen Note injiziert.
|
||
* **WP-15b Filter**: Das LLM validiert diese Vorschläge im zweiten Pass der Ingestion gegen den Kontext. Nur was semantisch wirklich passt, wird als Kante im Graphen persistiert.
|
||
|
||
#### B. Agentic Knowledge Mining (Chat-to-Vault)
|
||
Integration von Informationen aus dem Dialog direkt in den Graphen:
|
||
* **Intent Detection**: Das Chat-Backend erkennt „notierwürdige“ Informationen (z.B. neue Prinzipien, Strategie-Entwürfe oder Werte-Anpassungen).
|
||
* **Auto-Drafting**: Das LLM nutzt das `interview_template`, um aus dem Chat-Fragment eine valide Markdown-Datei mit Frontmatter (Status: `draft`) zu generieren.
|
||
* **Real-Time Linking**: Die neue Datei wird sofort dem „Discovery-Lauf“ (Teil A) unterzogen, um sie mit dem bestehenden Wissensschatz zu vernetzen.
|
||
* **User Review**: Die generierte Notiz erscheint im `00_Inbox` Ordner. Der Nutzer muss lediglich den Status auf `stable` setzen, um die Entdeckungen final zu integrieren.
|
||
|
||
**Erwartete Ergebnisse:**
|
||
* Eliminierung von Wissens-Silos durch automatische Vernetzung.
|
||
* Nahtloser Übergang von der Exploration (Chat) zur Konsolidierung (Vault).
|
||
* Vermeidung von Dubletten durch Ähnlichkeits-Warnungen beim Import.
|
||
## 4. Abhängigkeiten & Release-Plan
|
||
|
||
```mermaid
|
||
graph TD
|
||
WP19(Graph Viz) --> WP19a(Discovery)
|
||
WP19a --> WP17(Memory)
|
||
WP15(Smart Edges) --> WP16(Auto-Discovery)
|
||
WP15 --> WP14(Refactoring)
|
||
WP15(Smart Edges) --> WP15b(Candidate Validation)
|
||
WP15b --> WP24(Proactive Discovery)
|
||
WP03(Import) --> WP18(Health Check)
|
||
WP03 --> WP13(MCP)
|
||
WP04 --> WP13(MCP)
|
||
WP06(Decision Engine) --> WP21(Semantic Routing)
|
||
WP03(Import Pipeline) --> WP21
|
||
WP21 --> WP22(Lifecycle & Registry)
|
||
WP22 --> WP14
|
||
WP15(Smart Edges) --> WP21
|
||
WP20(Cloud Hybrid) --> WP15b
|
||
WP24 --> WP23(Multi-Stream Reasoning)
|
||
``` |