diff --git a/docs/06_Roadmap/06_active_roadmap.md b/docs/06_Roadmap/06_active_roadmap.md
index 46ce660..55f9440 100644
--- a/docs/06_Roadmap/06_active_roadmap.md
+++ b/docs/06_Roadmap/06_active_roadmap.md
@@ -90,6 +90,26 @@ Diese Features stehen als nächstes an oder befinden sich in der Umsetzung.
 - 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.
@@ -233,4 +253,5 @@ graph TD
     WP03(Import Pipeline) --> WP21
     WP21 --> WP22(Lifecycle & Registry)
     WP22 --> WP14
-    WP15(Smart Edges) --> WP21
\ No newline at end of file
+    WP15(Smart Edges) --> WP21
+    WP20(Cloud Hybrid) --> WP15b
\ No newline at end of file