diff --git a/docs/00_General/00_glossary.md b/docs/00_General/00_glossary.md
index ae2a13e..449ae61 100644
--- a/docs/00_General/00_glossary.md
+++ b/docs/00_General/00_glossary.md
@@ -2,8 +2,8 @@
 doc_type: glossary
 audience: all
 status: active
-version: 2.9.3
-context: "Zentrales Glossar für Mindnet v2.9.3. Enthält Definitionen zu Hybrid-Cloud Resilienz, WP-14 Modularisierung, WP-15b Two-Pass Ingestion, WP-15c Multigraph-Support, WP-25 Agentic Multi-Stream RAG und Mistral-safe Parsing."
+version: 3.0.0
+context: "Zentrales Glossar für Mindnet v3.0.0. Enthält Definitionen zu Hybrid-Cloud Resilienz, WP-14 Modularisierung, WP-15b Two-Pass Ingestion, WP-15c Multigraph-Support, WP-25 Agentic Multi-Stream RAG, WP-25a Mixture of Experts (MoE) und Mistral-safe Parsing."
 ---
 
 # Mindnet Glossar
@@ -54,4 +54,9 @@ context: "Zentrales Glossar für Mindnet v2.9.3. Enthält Definitionen zu Hybrid
 * **Circular Import Registry (WP-14):** Entkopplung von Kern-Logik (wie Textbereinigung) in eine neutrale `registry.py`, um Abhängigkeitsschleifen zwischen Diensten und Ingestion-Utilities zu verhindern.
 * **Deep-Link / Section-basierter Link:** Ein Link wie `[[Note#Section]]`, der auf einen spezifischen Abschnitt innerhalb einer Note verweist. Seit v2.9.1 wird dieser in `target_id="Note"` und `target_section="Section"` aufgeteilt, um "Phantom-Knoten" zu vermeiden und Multigraph-Support zu ermöglichen.
 * **Atomic Section Logic (v3.9.9):** Chunking-Verfahren, das Sektions-Überschriften und deren Inhalte atomar in Chunks hält (Pack-and-Carry-Over). Verhindert, dass Überschriften über Chunk-Grenzen hinweg getrennt werden.
-* **Registry-First Profiling (v2.13.12):** Hierarchische Auflösung des Chunking-Profils: Frontmatter > types.yaml Typ-Config > Global Defaults. Stellt sicher, dass Note-Typen automatisch das korrekte Profil erhalten.
\ No newline at end of file
+* **Registry-First Profiling (v2.13.12):** Hierarchische Auflösung des Chunking-Profils: Frontmatter > types.yaml Typ-Config > Global Defaults. Stellt sicher, dass Note-Typen automatisch das korrekte Profil erhalten.
+* **Mixture of Experts (MoE) - WP-25a:** Profilbasierte Experten-Architektur, bei der jede Systemaufgabe (Synthese, Ingestion-Validierung, Routing, Kompression) einem dedizierten Profil zugewiesen wird, das Modell, Provider und Parameter unabhängig von der globalen Konfiguration definiert.
+* **LLM-Profil:** Zentrale Definition in `llm_profiles.yaml`, die Provider, Modell, Temperature und Fallback-Profil für eine spezifische Aufgabe festlegt (z.B. `synthesis_pro`, `tech_expert`, `ingest_validator`).
+* **Fallback-Kaskade (WP-25a):** Rekursive Fallback-Logik, bei der bei Fehlern automatisch auf das `fallback_profile` umgeschaltet wird, bis der terminale Endpunkt (`identity_safe`) erreicht wird. Schutz gegen Zirkel-Referenzen via `visited_profiles`-Tracking.
+* **Pre-Synthesis Kompression (WP-25a):** Asynchrone Verdichtung überlanger Wissens-Streams vor der Synthese, um Token-Verbrauch zu reduzieren und die Synthese zu beschleunigen. Nutzt `compression_profile` (z.B. `compression_fast`).
+* **Profilgesteuerte Validierung (WP-25a):** Semantische Kanten-Validierung in der Ingestion erfolgt zwingend über das MoE-Profil `ingest_validator` (Temperature 0.0 für Determinismus), unabhängig von der globalen Provider-Konfiguration.
\ No newline at end of file
diff --git a/docs/02_concepts/02_concept_ai_personality.md b/docs/02_concepts/02_concept_ai_personality.md
index 633f443..d074523 100644
--- a/docs/02_concepts/02_concept_ai_personality.md
+++ b/docs/02_concepts/02_concept_ai_personality.md
@@ -1,10 +1,10 @@
 ---
 doc_type: concept
 audience: architect, product_owner
-scope: ai, router, personas, resilience, agentic_rag
+scope: ai, router, personas, resilience, agentic_rag, moe
 status: active
-version: 2.9.3
-context: "Fachkonzept der hybriden KI-Persönlichkeit, Agentic Multi-Stream RAG, Provider-Kaskade und kognitiven Resilienz (Deep Fallback)."
+version: 3.0.0
+context: "Fachkonzept der hybriden KI-Persönlichkeit, Agentic Multi-Stream RAG, WP-25a Mixture of Experts (MoE), Provider-Kaskade und kognitiven Resilienz (Deep Fallback)."
 ---
 
 # Konzept: KI-Persönlichkeit & Router
@@ -59,13 +59,45 @@ Jeder Treffer wird mit `stream_origin` markiert, um Feedback-Optimierung pro Wis
 
 ---
 
-## 2. Die hybride LLM-Landschaft (Resilienz-Kaskade)
+## 2. Mixture of Experts (MoE) Architektur (WP-25a)
 
-Ein intelligenter Zwilling muss jederzeit verfügbar sein. Mindnet v2.8.1 nutzt eine **dreistufige Kaskade**, um Intelligenz, Kosten und Verfügbarkeit zu optimieren:
+Seit WP-25a nutzt MindNet eine **profilbasierte Experten-Steuerung** statt einer globalen Provider-Konfiguration. Jede Systemaufgabe wird einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig definiert.
 
-1.  **Stufe 1: Cloud-Speed (Turbo-Mode):** Primäre Wahl für komplexe Extraktionsaufgaben und schnelle RAG-Antworten mittels OpenRouter (Mistral-7B) oder Google Gemini (2.5-flash-lite).
+### 2.1 Experten-Profile
+
+**Zentrale Registry (`llm_profiles.yaml`):**
+* **`synthesis_pro`:** Hochwertige Synthese für Chat-Antworten (Cloud)
+* **`tech_expert`:** Fachspezialist für Code & Technik (Claude 3.5 Sonnet)
+* **`compression_fast`:** Schnelle Kompression & Routing (Mistral 7B)
+* **`ingest_validator`:** Deterministische Validierung (Temperature 0.0)
+* **`identity_safe`:** Lokaler Anker (Ollama/Phi-3) für maximale Privacy
+
+**Vorteile:**
+* **Aufgabenspezifische Optimierung:** Jede Aufgabe nutzt das optimale Modell
+* **Hardware-Optimierung:** Lokaler Anker für kleine Hardware-Umgebungen
+* **Wartbarkeit:** Zentrale Konfiguration statt verstreuter ENV-Variablen
+
+### 2.2 Rekursive Fallback-Kaskade
+
+Die Profile implementieren eine **automatische Fallback-Logik**:
+
+1. **Primäres Profil:** System versucht das angeforderte Profil (z.B. `synthesis_pro`)
+2. **Fallback-Level 1:** Bei Fehler → `fallback_profile` (z.B. `synthesis_backup`)
+3. **Fallback-Level 2:** Bei weiterem Fehler → nächster Fallback (z.B. `identity_safe`)
+4. **Terminaler Endpunkt:** `identity_safe` hat keinen Fallback (lokales Modell als letzte Instanz)
+
+**Schutzmechanismen:**
+* **Zirkuläre Referenzen:** `visited_profiles`-Tracking verhindert Endlosschleifen
+* **Background-Semaphore:** Parallele Tasks werden gedrosselt
+
+### 2.3 Die hybride LLM-Landschaft (Legacy & MoE)
+
+Ein intelligenter Zwilling muss jederzeit verfügbar sein. Seit WP-25a wird die Resilienz durch die **MoE Fallback-Kaskade** gewährleistet:
+
+1.  **Stufe 1: Cloud-Experten:** Spezialisierte Profile für verschiedene Aufgaben (z.B. `synthesis_pro`, `tech_expert`)
 2.  **Stufe 2: Quoten-Resilienz:** Erkennt das System eine Drosselung durch Cloud-Provider (HTTP 429), pausiert es kontrolliert (`LLM_RATE_LIMIT_WAIT`), führt automatisierte Retries durch und schützt so den laufenden Prozess.
-3.  **Stufe 3: Deep Fallback & lokale Souveränität (Ollama):** * **Technischer Fallback:** Schlagen alle Cloud-Versuche fehl, übernimmt das lokale Modell (Phi-3).
+3.  **Stufe 3: Lokale Souveränität (Ollama):** 
+    * **Technischer Fallback:** Schlagen alle Cloud-Versuche fehl, übernimmt das lokale Modell (Phi-3) via `identity_safe` Profil.
     * **Kognitiver Fallback (v2.11.14):** Liefert die Cloud zwar technisch eine Antwort, verweigert aber inhaltlich die Verarbeitung (Silent Refusal/Policy Violation), wird ein **Deep Fallback** erzwungen, um die Datenintegrität lokal zu retten.
 
 
diff --git a/docs/03_Technical_References/03_tech_chat_backend.md b/docs/03_Technical_References/03_tech_chat_backend.md
index 7c865af..bb6e2e3 100644
--- a/docs/03_Technical_References/03_tech_chat_backend.md
+++ b/docs/03_Technical_References/03_tech_chat_backend.md
@@ -1,10 +1,10 @@
 ---
 doc_type: technical_reference
 audience: developer, architect
-scope: backend, chat, llm_service, traffic_control, resilience, agentic_rag
+scope: backend, chat, llm_service, traffic_control, resilience, agentic_rag, moe
 status: active
-version: 2.9.3
-context: "Technische Implementierung des FastAPI-Routers, des hybriden LLMService (v3.4.2), WP-25 Agentic Multi-Stream RAG und WP-20 Resilienz-Logik."
+version: 3.0.0
+context: "Technische Implementierung des FastAPI-Routers, des hybriden LLMService (v3.5.2), WP-25 Agentic Multi-Stream RAG, WP-25a Mixture of Experts (MoE) und WP-20 Resilienz-Logik."
 ---
 
 # Chat Backend & Agentic Multi-Stream RAG
@@ -28,7 +28,31 @@ Der Router nutzt einen **Hybrid-Modus** mit Keyword-Fast-Path und LLM-Slow-Path:
     * Wenn unklar: Anfrage an `DecisionEngine._determine_strategy()` zur LLM-basierten Klassifizierung.
     * Nutzt `intent_router_v1` Prompt aus `prompts.yaml`.
 
-### 1.2 Prompt-Auflösung (Bulletproof Resolution)
+### 1.2 Mixture of Experts (MoE) Architektur (WP-25a)
+
+Seit WP-25a nutzt MindNet eine **profilbasierte Experten-Steuerung** statt einer globalen Provider-Konfiguration. Jede Systemaufgabe wird einem dedizierten Profil zugewiesen:
+
+**Profil-Registry (`llm_profiles.yaml`):**
+* **`synthesis_pro`:** Hochwertige Synthese für Chat-Antworten
+* **`tech_expert`:** Fachspezialist für Code & Technik
+* **`compression_fast`:** Schnelle Kompression & Routing
+* **`ingest_validator`:** Deterministische Validierung (Temperature 0.0)
+* **`identity_safe`:** Lokaler Anker (Ollama/Phi-3) für maximale Privacy
+
+**Rekursive Fallback-Kaskade:**
+Der `LLMService` (v3.5.2) implementiert eine automatische Fallback-Logik:
+1. Versucht primäres Profil (z.B. `synthesis_pro`)
+2. Bei Fehler → `fallback_profile` (z.B. `synthesis_backup`)
+3. Bei weiterem Fehler → nächster Fallback (z.B. `identity_safe`)
+4. Schutz gegen Zirkel-Referenzen via `visited_profiles`-Tracking
+
+**Integration:**
+* **Intent-Routing:** Nutzt `router_profile` (z.B. `compression_fast`)
+* **Stream-Kompression:** Nutzt `compression_profile` pro Stream
+* **Synthese:** Nutzt `llm_profile` aus Strategie-Konfiguration
+* **Ingestion:** Nutzt `ingest_validator` für binäre Validierungen
+
+### 1.3 Prompt-Auflösung (Bulletproof Resolution)
 
 Um Kompatibilitätsprobleme mit verschachtelten YAML-Prompts zu vermeiden, nutzt der Router die Methode `llm.get_prompt()`. Diese implementiert eine **Provider-Kaskade**:
 * **Spezifischer Provider:** Das System sucht zuerst nach einem Prompt für den aktiv konfigurierten Provider (z.B. `openrouter`).
@@ -36,7 +60,7 @@ Um Kompatibilitätsprobleme mit verschachtelten YAML-Prompts zu vermeiden, nutzt
 * **Basis-Fallback:** Als letzte Instanz wird das `ollama`-Template geladen.
 * **String-Garantie:** Die Methode garantiert die Rückgabe eines Strings (selbst bei verschachtelten YAML-Dicts), was 500-Fehler bei String-Operationen wie `.replace()` oder `.format()` verhindert.
 
-### 1.2 Multi-Stream Retrieval (WP-25)
+### 1.4 Multi-Stream Retrieval (WP-25)
 
 Anstelle einer einzelnen Suche führt die `DecisionEngine` nun **parallele Abfragen** in spezialisierten Streams aus:
 
@@ -57,7 +81,22 @@ Anstelle einer einzelnen Suche führt die `DecisionEngine` nun **parallele Abfra
 * **Stream-Tracing:** Jeder Treffer wird mit `stream_origin` markiert für Feedback-Optimierung.
 * **Fehlerbehandlung:** Einzelne Stream-Fehler blockieren nicht die gesamte Anfrage.
 
-### 1.3 Wissens-Synthese (WP-25)
+### 1.5 Pre-Synthesis Kompression (WP-25a)
+
+Wissens-Streams, die den Schwellenwert (`compression_threshold`) überschreiten, werden **asynchron verdichtet**, bevor sie die Synthese erreichen:
+
+**Kompression-Logik:**
+* **Schwellenwert:** Konfigurierbar pro Stream (z.B. 2500 Zeichen für Values Stream)
+* **Profil:** Nutzt `compression_profile` (z.B. `compression_fast` für schnelle Zusammenfassung)
+* **Parallelisierung:** Mehrere Streams können gleichzeitig komprimiert werden
+* **Fehlerbehandlung:** Kompressions-Fehler blockieren nicht die Synthese (Original-Content wird verwendet)
+
+**Vorteile:**
+* Reduziert Token-Verbrauch bei langen Streams
+* Beschleunigt Synthese durch kürzere Kontexte
+* Erhält Relevanz durch intelligente Zusammenfassung
+
+### 1.6 Wissens-Synthese (WP-25/25a)
 
 Die Zusammenführung der Daten erfolgt über spezialisierte Templates in der `prompts.yaml`:
 
@@ -66,20 +105,29 @@ Die Zusammenführung der Daten erfolgt über spezialisierte Templates in der `pr
 * **Pre-Initialization:** Alle möglichen Stream-Variablen werden vorab initialisiert (verhindert KeyErrors).
 * **Provider-spezifische Templates:** Separate Versionen für Ollama, Gemini und OpenRouter.
 
-**Synthese-Strategien:**
-* **FACT_WHAT/FACT_WHEN:** Kombiniert Fakten, Biographie und Technik.
-* **DECISION:** Wägt Fakten gegen Werte ab, evaluiert Risiken.
-* **EMPATHY:** Fokus auf Biographie und Werte.
-* **CODING:** Technik und Fakten.
+**Synthese-Strategien (Profil-gesteuert):**
+* **FACT_WHAT/FACT_WHEN:** Nutzt `synthesis_pro` - Kombiniert Fakten, Biographie und Technik.
+* **DECISION:** Nutzt `synthesis_pro` - Wägt Fakten gegen Werte ab, evaluiert Risiken.
+* **EMPATHY:** Nutzt `synthesis_pro` - Fokus auf Biographie und Werte.
+* **CODING:** Nutzt `tech_expert` - Spezialisiertes Modell für Code & Technik.
 
-### 1.4 RAG Flow (Technisch)
+**Profil-Auflösung:**
+Jede Strategie kann ein individuelles `llm_profile` definieren. Fehlt diese Angabe, wird `synthesis_pro` als Standard verwendet.
+
+### 1.7 RAG Flow (Technisch - WP-25a)
 
 Wenn der Intent nicht `INTERVIEW` ist, wird folgender Flow ausgeführt:
 
-1.  **Intent Detection:** Hybrid Router klassifiziert die Anfrage.
+1.  **Intent Detection:** Hybrid Router klassifiziert die Anfrage via `router_profile` (z.B. `compression_fast`).
 2.  **Multi-Stream Retrieval:**
     * Parallele Abfragen in spezialisierten Streams via `DecisionEngine._execute_parallel_streams()`.
     * Jeder Stream nutzt individuelle Filter, Edge-Boosts und Query-Templates.
+3.  **Pre-Synthesis Kompression (WP-25a):**
+    * Streams über `compression_threshold` werden via `compression_profile` verdichtet.
+    * Parallelisierung über `asyncio.gather()` für mehrere Streams gleichzeitig.
+4.  **Wissens-Synthese:**
+    * Strategie-spezifisches `llm_profile` (z.B. `tech_expert` für CODING) steuert die finale Antwortgenerierung.
+    * Fallback-Kaskade bei Fehlern (automatisch via LLMService).
 3.  **Context Formatting:**
     * Stream-Ergebnisse werden in formatierte Kontext-Strings umgewandelt.
     * **Ollama Context-Throttling:** Kontext wird auf `MAX_OLLAMA_CHARS` begrenzt (Standard: 10.000).
diff --git a/docs/03_Technical_References/03_tech_configuration.md b/docs/03_Technical_References/03_tech_configuration.md
index 1951594..fb35a5f 100644
--- a/docs/03_Technical_References/03_tech_configuration.md
+++ b/docs/03_Technical_References/03_tech_configuration.md
@@ -1,10 +1,10 @@
 ---
 doc_type: technical_reference
 audience: developer, admin
-scope: configuration, env, registry, scoring, resilience, modularization, agentic_rag
+scope: configuration, env, registry, scoring, resilience, modularization, agentic_rag, moe
 status: active
-version: 2.9.3
-context: "Umfassende Referenztabellen für Umgebungsvariablen (inkl. Hybrid-Cloud & WP-76), YAML-Konfigurationen, Edge Registry Struktur und WP-25 Multi-Stream RAG unter Berücksichtigung von WP-14."
+version: 3.0.0
+context: "Umfassende Referenztabellen für Umgebungsvariablen (inkl. Hybrid-Cloud & WP-76), YAML-Konfigurationen, Edge Registry Struktur, WP-25 Multi-Stream RAG und WP-25a Mixture of Experts (MoE) unter Berücksichtigung von WP-14."
 ---
 
 # Konfigurations-Referenz
@@ -329,6 +329,80 @@ Alle möglichen Stream-Variablen werden vorab initialisiert (verhindert KeyError
 **Provider-spezifische Templates:**
 Separate Versionen für Ollama, Gemini und OpenRouter.
 
+---
+
+## 6. LLM Profile Registry (`llm_profiles.yaml` v1.3.0)
+
+Seit WP-25a nutzt MindNet eine **Mixture of Experts (MoE)** Architektur mit profilbasierter Experten-Steuerung. Jede Systemaufgabe (Synthese, Ingestion-Validierung, Routing, Kompression) wird einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig von der globalen Konfiguration definiert.
+
+### 6.1 Profil-Struktur
+
+Jedes Profil definiert:
+* **`provider`:** Cloud-Provider (`openrouter`, `gemini`, `ollama`)
+* **`model`:** Spezifisches Modell (z.B. `mistralai/mistral-7b-instruct:free`)
+* **`temperature`:** Kreativität/Determinismus (0.0 = deterministisch, 1.0 = kreativ)
+* **`fallback_profile`:** Optional: Name des Fallback-Profils bei Fehlern
+* **`dimensions`:** Optional: Für Embedding-Profile (z.B. 768 für nomic-embed-text)
+
+**Beispiel:**
+```yaml
+synthesis_pro:
+  provider: "openrouter"
+  model: "gemini-1.5-mistralai/mistral-7b-instruct:free"
+  temperature: 0.7
+  fallback_profile: "synthesis_backup"
+```
+
+### 6.2 Verfügbare Experten-Profile
+
+| Profil | Provider | Modell | Temperature | Fallback | Zweck |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| **`synthesis_pro`** | openrouter | gemini-1.5-mistralai/mistral-7b-instruct:free | 0.7 | `synthesis_backup` | Hochwertige Synthese (Chat-Antworten) |
+| **`synthesis_backup`** | openrouter | mistralai/mistral-large | 0.5 | `identity_safe` | Backup-Cloud-Experte (Resilienz) |
+| **`tech_expert`** | openrouter | anthropic/claude-3.5-sonnet | 0.3 | `synthesis_pro` | Fachspezialist für Code & Technik |
+| **`compression_fast`** | openrouter | mistralai/mistral-7b-instruct:free | 0.1 | `identity_safe` | Schnelle Kompression & Routing |
+| **`ingest_extractor`** | openrouter | mistralai/mistral-7b-instruct:free | 0.2 | `synthesis_backup` | Extraktion komplexer Datenstrukturen |
+| **`ingest_validator`** | openrouter | mistralai/mistral-7b-instruct:free | 0.0 | `compression_fast` | Binäre Prüfungen (YES/NO, deterministisch) |
+| **`identity_safe`** | ollama | phi3:mini | 0.2 | *(kein Fallback)* | Lokaler Anker & Privacy (terminaler Endpunkt) |
+| **`embedding_expert`** | ollama | nomic-embed-text | - | - | Embedding-Modell (dimensions: 768) |
+
+### 6.3 Fallback-Kaskade (WP-25a)
+
+Die Profile implementieren eine **rekursive Fallback-Kaskade**:
+
+1. **Primäres Profil:** System versucht das angeforderte Profil (z.B. `synthesis_pro`)
+2. **Fallback-Level 1:** Bei Fehler → `fallback_profile` (z.B. `synthesis_backup`)
+3. **Fallback-Level 2:** Bei weiterem Fehler → nächster Fallback (z.B. `identity_safe`)
+4. **Terminaler Endpunkt:** `identity_safe` hat keinen Fallback (lokales Modell als letzte Instanz)
+
+**Schutzmechanismen:**
+* **Zirkuläre Referenzen:** `visited_profiles`-Tracking verhindert Endlosschleifen
+* **Background-Semaphore:** Parallele Tasks werden gedrosselt (konfigurierbar via `BACKGROUND_LIMIT`)
+
+### 6.4 Integration in Decision Engine
+
+Die `decision_engine.yaml` referenziert Profile über:
+* **`router_profile`:** Profil für Intent-Erkennung (z.B. `compression_fast`)
+* **`llm_profile`:** Profil für Strategie-spezifische Synthese (z.B. `tech_expert` für CODING)
+* **`compression_profile`:** Profil für Stream-Kompression (z.B. `compression_fast`)
+
+**Stream-Konfiguration:**
+```yaml
+values_stream:
+  llm_profile: "identity_safe"  # Lokales Modell für Privacy
+  compression_profile: "identity_safe"
+  compression_threshold: 2500
+```
+
+### 6.5 Environment-Variablen
+
+| Variable | Default | Beschreibung |
+| :--- | :--- | :--- |
+| `MINDNET_LLM_PROFILES_PATH` | `config/llm_profiles.yaml` | Pfad zur Profil-Registry |
+
+**Hinweis:** Die `.env` Variablen `MINDNET_LLM_PROVIDER`, `MINDNET_LLM_MODEL` etc. dienen nur noch als Fallback, wenn kein Profil angegeben wird.
+
+---
 
 Auszug aus der decision_engine.yaml
 ```yaml
diff --git a/docs/03_Technical_References/03_tech_ingestion_pipeline.md b/docs/03_Technical_References/03_tech_ingestion_pipeline.md
index 4d29518..00497cc 100644
--- a/docs/03_Technical_References/03_tech_ingestion_pipeline.md
+++ b/docs/03_Technical_References/03_tech_ingestion_pipeline.md
@@ -1,10 +1,10 @@
 ---
 doc_type: technical_reference
 audience: developer, devops
-scope: backend, ingestion, smart_edges, edge_registry, modularization
+scope: backend, ingestion, smart_edges, edge_registry, modularization, moe
 status: active
-version: 2.13.12
-context: "Detaillierte technische Beschreibung der Import-Pipeline, Two-Pass-Workflow (WP-15b) und modularer Datenbank-Architektur (WP-14). Integriert Mistral-safe Parsing und Deep Fallback."
+version: 2.14.0
+context: "Detaillierte technische Beschreibung der Import-Pipeline, Two-Pass-Workflow (WP-15b), modularer Datenbank-Architektur (WP-14) und WP-25a profilgesteuerte Validierung. Integriert Mistral-safe Parsing und Deep Fallback."
 ---
 
 # Ingestion Pipeline & Smart Processing
@@ -50,9 +50,11 @@ Der Prozess ist **asynchron**, **idempotent** und wird nun in zwei logische Durc
     * Bei Änderungen löscht `purge_artifacts()` via `app.core.ingestion.ingestion_db` alle alten Chunks und Edges der Note.
     * Die Namensauflösung erfolgt nun über das modularisierte `database`-Paket.
 10. **Chunking anwenden:** Zerlegung des Textes basierend auf dem ermittelten Profil (siehe Kap. 3).
-11. **Smart Edge Allocation & Semantic Validation (WP-15b):**
+11. **Smart Edge Allocation & Semantic Validation (WP-15b / WP-25a):**
     * Der `SemanticAnalyzer` schlägt Kanten-Kandidaten vor.
-    * **Validierung:** Jeder Kandidat wird durch das LLM semantisch gegen das Ziel im **LocalBatchCache** geprüft.
+    * **Validierung (WP-25a):** Jeder Kandidat wird durch das LLM semantisch gegen das Ziel im **LocalBatchCache** geprüft.
+    * **Profilgesteuerte Validierung:** Nutzt das MoE-Profil `ingest_validator` (Temperature 0.0 für maximale Determinismus).
+    * **Fallback-Kaskade:** Bei Fehlern erfolgt automatischer Fallback via `fallback_profile` (z.B. `compression_fast` → `identity_safe`).
     * **Traffic Control:** Nutzung der neutralen `clean_llm_text` Funktion zur Bereinigung von Steuerzeichen (<s>, [OUT]).
     * **Deep Fallback (v2.11.14):** Erkennt "Silent Refusals". Liefert die Cloud keine verwertbaren Kanten, wird ein lokaler Fallback via Ollama erzwungen.
 12. **Inline-Kanten finden:** Parsing von `[[rel:...]]` und Callouts.
@@ -60,7 +62,9 @@ Der Prozess ist **asynchron**, **idempotent** und wird nun in zwei logische Durc
     * Jede Kante wird via `EdgeRegistry` normalisiert (z.B. `basiert_auf` -> `based_on`).
     * Unbekannte Typen werden in `unknown_edges.jsonl` protokolliert.
 14. **Default- & Strukturkanten:** Anwendung der `edge_defaults` und Erzeugung von Systemkanten (`belongs_to`, `next`, `prev`).
-15. **Embedding (Async):** Generierung der Vektoren via `nomic-embed-text` (768 Dimensionen).
+15. **Embedding (Async - WP-25a):** Generierung der Vektoren via `embedding_expert` Profil aus `llm_profiles.yaml`.
+    * **Profil-Auflösung:** Das `EmbeddingsClient` lädt Modell und Dimensionen direkt aus dem Profil (z.B. `nomic-embed-text`, 768 Dimensionen).
+    * **Konsolidierung:** Entfernung der Embedding-Konfiguration aus der `.env` zugunsten zentraler Profil-Registry.
 16. **Database Sync (WP-14):** Batch-Upsert aller Points in die Collections `{prefix}_chunks` und `{prefix}_edges` über die zentrale Infrastruktur.
 
 ---
@@ -189,4 +193,6 @@ Kanten werden nach Vertrauenswürdigkeit (`provenance`) priorisiert. Die höhere
 
 **2. Mistral-safe Parsing:** Automatisierte Bereinigung von LLM-Antworten in `ingestion_validation.py`. Stellt sicher, dass semantische Entscheidungen ("YES"/"NO") nicht durch technische Header verfälscht werden.
 
+**3. Profilgesteuerte Validierung (WP-25a):** Die semantische Kanten-Validierung erfolgt zwingend über das MoE-Profil `ingest_validator` (Temperature 0.0 für Determinismus). Dies gewährleistet konsistente binäre Entscheidungen (YES/NO) unabhängig von der globalen Provider-Konfiguration.
+
 **3. Purge Integrity:** Validierung, dass vor jedem Upsert alle assoziierten Artefakte in den Collections `{prefix}_chunks` und `{prefix}_edges` gelöscht wurden, um Daten-Duplikate zu vermeiden.
\ No newline at end of file
diff --git a/docs/04_Operations/04_admin_operations.md b/docs/04_Operations/04_admin_operations.md
index 96f7b1b..b8f8bbb 100644
--- a/docs/04_Operations/04_admin_operations.md
+++ b/docs/04_Operations/04_admin_operations.md
@@ -1,10 +1,10 @@
 ---
 doc_type: operations_manual
 audience: admin, devops
-scope: deployment, maintenance, backup, edge_registry
+scope: deployment, maintenance, backup, edge_registry, moe
 status: active
-version: 2.7.0
-context: "Installationsanleitung, Systemd-Units und Wartungsprozesse für Mindnet v2.7."
+version: 3.0.0
+context: "Installationsanleitung, Systemd-Units und Wartungsprozesse für Mindnet v3.0.0 inklusive WP-25a Mixture of Experts (MoE) Konfiguration."
 ---
 
 # Admin Operations Guide
@@ -46,7 +46,7 @@ Um Abstürze der Vektordatenbank bei einer hohen Anzahl an Collections (z. B. du
 Hintergrund: Qdrant öffnet für jedes Segment einer Collection mehrere Dateien. Ohne diese Erhöhung führt das Standard-Linux-Limit (1024) zum Absturz mit dem Fehler os error 24 (Too many open files).
 
 ### 1.3 Ollama (Modelle)
-**Wichtig:** Seit v2.4 ist `nomic-embed-text` Pflicht für Embeddings.
+**Wichtig:** Seit v2.4 ist `nomic-embed-text` Pflicht für Embeddings. Seit WP-25a wird die Modell-Konfiguration zentral über `llm_profiles.yaml` gesteuert.
 
 ```bash
 # Modelle laden
@@ -57,6 +57,14 @@ ollama pull nomic-embed-text
 curl http://localhost:11434/api/generate -d '{"model": "phi3:mini", "prompt":"Hi"}'
 ```
 
+**WP-25a: LLM-Profil-Konfiguration**
+Die LLM-Steuerung erfolgt nun primär über `config/llm_profiles.yaml` statt ENV-Variablen:
+* **Zentrale Registry:** Alle Experten-Profile (Synthese, Validierung, Kompression) sind in einer Datei definiert
+* **Fallback-Kaskade:** Automatische Resilienz bei Provider-Fehlern
+* **ENV-Variablen:** `MINDNET_LLM_PROVIDER`, `MINDNET_LLM_MODEL` etc. dienen nur noch als Fallback
+
+Siehe [Konfigurations-Referenz](../03_Technical_References/03_tech_configuration.md#6-llm-profile-registry-llm_profilesyaml-v130) für Details.
+
 ---
 
 ## 2. Deployment (Systemd Services)
diff --git a/docs/05_Development/05_developer_guide.md b/docs/05_Development/05_developer_guide.md
index 0f8e5a2..cd8a4df 100644
--- a/docs/05_Development/05_developer_guide.md
+++ b/docs/05_Development/05_developer_guide.md
@@ -393,13 +393,24 @@ Mindnet lernt nicht durch Training (Fine-Tuning), sondern durch **Konfiguration*
       edge_defaults: ["blocks"]    # Automatische Kante
       detection_keywords: ["gefahr", "risiko"]
     ```
-2.  **Strategie (`config/decision_engine.yaml` v3.1.6, WP-25):**
+2.  **Strategie (`config/decision_engine.yaml` v3.2.2, WP-25/25a):**
     ```yaml
     DECISION:
       use_streams: ["values_stream", "facts_stream", "risk_stream"]  # WP-25: Multi-Stream
+      llm_profile: "synthesis_pro"  # WP-25a: MoE-Profil für Synthese
       inject_types: ["value", "risk"]  # Legacy: Fallback für nicht-Stream-Typen
     ```
-    *Ergebnis (WP-25):* Wenn der Intent `DECISION` erkannt wird, führt das System parallele Abfragen in Values, Facts und Risk Streams aus und synthetisiert die Ergebnisse.
+    *Ergebnis (WP-25/25a):* Wenn der Intent `DECISION` erkannt wird, führt das System parallele Abfragen in Values, Facts und Risk Streams aus, komprimiert überlange Streams via `compression_profile` und synthetisiert die Ergebnisse mit dem `synthesis_pro` Profil.
+
+3.  **LLM-Profil (`config/llm_profiles.yaml` v1.3.0, WP-25a):**
+    ```yaml
+    synthesis_pro:
+      provider: "openrouter"
+      model: "gemini-1.5-mistralai/mistral-7b-instruct:free"
+      temperature: 0.7
+      fallback_profile: "synthesis_backup"
+    ```
+    *Ergebnis (WP-25a):* Zentrale Steuerung von Provider, Modell und Temperature pro Aufgabe. Automatische Fallback-Kaskade bei Fehlern.
 
 ### Workflow B: Graph-Farben ändern
 1.  Öffne `app/frontend/ui_config.py`.
diff --git a/docs/06_Roadmap/06_active_roadmap.md b/docs/06_Roadmap/06_active_roadmap.md
index cb61b71..0ff199f 100644
--- a/docs/06_Roadmap/06_active_roadmap.md
+++ b/docs/06_Roadmap/06_active_roadmap.md
@@ -194,7 +194,10 @@ Der bisherige WP-15 Ansatz litt unter Halluzinationen (erfundene Kantentypen), h
 3.  **Self-Learning Loop:** Protokollierung unbekannter Kanten in `unknown_edges.jsonl`.
 
 ### WP-25: Agentic Multi-Stream RAG Orchestration
-**Status:** ✅ Fertig (v2.9.3)
+**Status:** ✅ Fertig (v3.0.0)
+
+### WP-25a: Mixture of Experts (MoE) & Fallback-Kaskade
+**Status:** ✅ Fertig (v3.0.0)
 
 **Ergebnis:** Transformation von Mindnet von einer klassischen, linearen RAG-Architektur zu einer **Agentic Multi-Stream Engine**. Das System agiert nun als intelligenter Orchestrator, der Nutzeranfragen analysiert, in parallele Wissens-Streams aufteilt und diese zu einer kontextreichen, wertebasierten Antwort synthetisiert.
 
@@ -212,8 +215,26 @@ Der bisherige WP-15 Ansatz litt unter Halluzinationen (erfundene Kantentypen), h
 - decision_engine.yaml v3.1.6: Multi-Stream Konfiguration
 - prompts.yaml v3.1.2: Stream-Templates
 
-**Ausblick (WP-25a):**
-- Pre-Synthesis: LLM-basierte Komprimierung überlanger Streams
+**Ergebnis (WP-25a):** Transformation von MindNet von einer provider-basierten Steuerung auf eine **profilbasierte Experten-Architektur (Mixture of Experts)**. Jede Systemaufgabe wird einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig definiert.
+
+**Kern-Features:**
+1. **Experten-Steuerung:** Zentrale Profile-Registry (`llm_profiles.yaml`) für alle LLM-Aufgaben
+2. **Rekursive Fallback-Kaskade:** Automatische Resilienz bei Provider-Fehlern mit Schutz gegen Zirkel-Referenzen
+3. **Pre-Synthesis Kompression:** Asynchrone Verdichtung überlanger Wissens-Streams vor der Synthese
+4. **Profilgesteuerte Ingestion:** Deterministische Validierung via `ingest_validator` (Temperature 0.0)
+5. **Embedding-Konsolidierung:** Zentrale Steuerung des Embedding-Modells über `embedding_expert` Profil
+6. **Startup-Schutz:** Validierung der YAML-Konfigurationen beim Booten
+
+**Technische Details:**
+- LLM Service v3.5.2: Rekursive Fallback-Kaskade
+- Decision Engine v1.2.1: Profile-Driven Orchestration
+- Ingestion Processor v2.14.0: Profilgesteuerte Validierung
+- Embeddings Client v2.6.0: Profil-basierte Modell-Auflösung
+- llm_profiles.yaml v1.3.0: Zentrale Experten-Registry
+- decision_engine.yaml v3.2.2: Decoupled MoE Logic
+
+**Ausblick (WP-25b):**
+- Prompt-Orchestration & Model-Specific Tuning
 - Kontext-Budgeting: Intelligente Token-Verteilung
 - Stream-specific Provider: Unterschiedliche KI-Modelle pro Wissensbereich
 ---
diff --git a/docs/99_Archive/WP25a_merge_commit.md b/docs/99_Archive/WP25a_merge_commit.md
new file mode 100644
index 0000000..24bdda7
--- /dev/null
+++ b/docs/99_Archive/WP25a_merge_commit.md
@@ -0,0 +1,103 @@
+# Branch Merge Commit: WP-25a
+
+**Branch:** `WP25a`  
+**Target:** `main`  
+**Version:** v3.1.0  
+**Date:** 2026-01-02
+
+---
+
+## Commit Message
+
+```
+feat: Mixture of Experts (MoE) & Fallback-Kaskade (v3.0.0)
+
+### Mixture of Experts (MoE) Architektur
+- Übergang von provider-basierter zu profilbasierter Experten-Steuerung
+- Zentrale Experten-Registry (`llm_profiles.yaml` v1.3.0)
+- Aufgabenspezifische Profile: synthesis_pro, tech_expert, compression_fast, ingest_validator, identity_safe, embedding_expert
+- Hardware-Optimierung: Lokaler Anker (Ollama/Phi-3) für maximale Privacy
+
+### Rekursive Fallback-Kaskade
+- Implementierung in `app/services/llm_service.py` (v3.5.2)
+- Automatische Fallback-Logik bei Provider-Fehlern
+- Schutz gegen Zirkel-Referenzen via `visited_profiles`-Tracking
+- Background-Semaphore für parallele Tasks
+
+### Pre-Synthesis Kompression (Module A)
+- Asynchrone Verdichtung überlanger Wissens-Streams
+- Konfigurierbare Schwellenwerte pro Stream (`compression_threshold`)
+- Profil-gesteuerte Kompression via `compression_profile`
+- Parallelisierung über `asyncio.gather()`
+
+### Profilgesteuerte Ingestion
+- Semantische Kanten-Validierung via `ingest_validator` (Temperature 0.0)
+- Embedding-Konsolidierung über `embedding_expert` Profil
+- Entfernung der Embedding-Konfiguration aus `.env`
+
+### Startup-Schutz & Audit-Fixes
+- Validierung von `llm_profiles.yaml` und `decision_engine.yaml` beim Booten
+- Behebung der Sicherheitslücke in `DecisionEngine` (Fallback-Aufrufe nutzen nun `profile_name`)
+- Circular Import Fix: Ingestion-Module nutzen neutrale `app.core.registry`
+
+### Code-Komponenten
+- `app/services/llm_service.py`: v3.5.2 (Rekursive Fallback-Kaskade)
+- `app/core/retrieval/decision_engine.py`: v1.2.1 (Profile-Driven Orchestration)
+- `app/core/ingestion/ingestion_processor.py`: v2.14.0 (Profilgesteuerte Validierung)
+- `app/core/ingestion/ingestion_validation.py`: v2.13.0 (MoE-Profil Integration)
+- `app/services/embeddings_client.py`: v2.6.0 (Profil-basierte Modell-Auflösung)
+- `app/main.py`: v1.1.0 (Startup-Validierung)
+
+### Konfiguration
+- `config/llm_profiles.yaml`: v1.3.0 (Zentrale Experten-Registry)
+- `config/decision_engine.yaml`: v3.2.2 (Decoupled MoE Logic, compression_thresholds)
+
+### Dokumentation
+- `03_tech_configuration.md`: llm_profiles.yaml Dokumentation
+- `03_tech_chat_backend.md`: MoE Architektur und Fallback-Kaskade
+- `02_concept_ai_personality.md`: Mixture of Experts Konzept
+- `03_tech_ingestion_pipeline.md`: Profilgesteuerte Validierung
+- `00_glossary.md`: Neue Begriffe (MoE, Profile, Fallback-Kaskade)
+- `05_developer_guide.md`: Teach-the-AI mit Profilen
+- `04_admin_operations.md`: Konfigurations-Updates
+- `06_active_roadmap.md`: WP25a als abgeschlossen markiert
+
+### Breaking Changes
+- Keine Breaking Changes für Endbenutzer
+- ENV-Variablen `MINDNET_LLM_PROVIDER`, `MINDNET_LLM_MODEL` etc. dienen nur noch als Fallback
+- Neue Konfigurationsdatei `llm_profiles.yaml` ist erforderlich (Startup-Validierung)
+
+### Migration
+- Administratoren müssen `config/llm_profiles.yaml` erstellen
+- System startet nicht, wenn `llm_profiles.yaml` fehlt oder ungültig ist
+- ENV-Variablen bleiben als Fallback erhalten
+
+---
+
+**Status:** ✅ WP-25a ist zu 100% implementiert und audit-geprüft.  
+**Nächster Schritt:** WP-25b (Prompt-Orchestration & Model-Specific Tuning).
+```
+
+---
+
+## Zusammenfassung
+
+Dieser Merge führt die **Mixture of Experts (MoE) Architektur** in MindNet ein. Das System nutzt nun eine profilbasierte Experten-Steuerung statt einer globalen Provider-Konfiguration. Jede Systemaufgabe wird einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig definiert.
+
+**Kern-Features:**
+- Zentrale Experten-Registry (`llm_profiles.yaml`)
+- Rekursive Fallback-Kaskade mit Schutz gegen Zirkel-Referenzen
+- Pre-Synthesis Kompression für überlange Wissens-Streams
+- Profilgesteuerte Ingestion mit deterministischer Validierung
+- Startup-Schutz und Audit-Fixes
+
+**Technische Integrität:**
+- Alle LLM-Aufrufe nutzen nun die Profilsteuerung
+- Startup-Validierung verhindert fehlerhafte Konfigurationen
+- Circular Import Fix verbessert Wartbarkeit
+
+**Dokumentation:**
+- Vollständige Aktualisierung aller relevanten Dokumente
+- Neue Begriffe im Glossar
+- Konfigurations-Referenz erweitert
+- Developer Guide aktualisiert
diff --git a/docs/99_Archive/WP25a_release_notes.md b/docs/99_Archive/WP25a_release_notes.md
new file mode 100644
index 0000000..175b527
--- /dev/null
+++ b/docs/99_Archive/WP25a_release_notes.md
@@ -0,0 +1,186 @@
+# MindNet v3.0.0 - Release Notes: WP-25a
+
+**Release Date:** 2026-01-02 
+**Type:** Feature Release - Mixture of Experts (MoE) & Fallback-Kaskade  
+**Version:** 3.1.0 (WP-25a)
+
+---
+
+## 🎯 Überblick
+
+Mit WP-25a wurde MindNet von einer provider-basierten Steuerung auf eine **profilbasierte Experten-Architektur (Mixture of Experts)** umgestellt. Jede Systemaufgabe (Synthese, Ingestion-Validierung, Routing, Kompression) wird nun einem dedizierten Profil zugewiesen, das Modell, Provider und Parameter unabhängig von der globalen Konfiguration definiert.
+
+Diese Version markiert einen fundamentalen Architektur-Sprung: Von einer monolithischen LLM-Konfiguration hin zu einer modularen, aufgabenspezifischen Experten-Steuerung mit automatischer Resilienz.
+
+---
+
+## ✨ Neue Features
+
+### 1. Mixture of Experts (MoE) Architektur
+
+**Zentrale Experten-Steuerung (`llm_profiles.yaml` v1.3.0):**
+* Einführung von Experten-Profilen für spezifische Aufgaben:
+  * `synthesis_pro`: Hochwertige Synthese für Chat-Antworten
+  * `tech_expert`: Fachspezialist für Code & Technik (Claude 3.5 Sonnet)
+  * `compression_fast`: Schnelle Kompression & Routing (Mistral 7B)
+  * `ingest_validator`: Deterministische Validierung (Temperature 0.0)
+  * `identity_safe`: Lokaler Anker (Ollama/Phi-3) für maximale Privacy
+  * `embedding_expert`: Zentrale Steuerung des Embedding-Modells
+
+**Vorteile:**
+* **Aufgabenspezifische Optimierung:** Jede Aufgabe nutzt das optimale Modell
+* **Hardware-Optimierung:** Lokaler Anker für kleine Hardware-Umgebungen
+* **Wartbarkeit:** Zentrale Konfiguration statt verstreuter ENV-Variablen
+
+### 2. Rekursive Fallback-Kaskade
+
+**Implementierung (`app/services/llm_service.py` v3.5.2):**
+* Automatische Fallback-Logik bei Provider-Fehlern:
+  1. Versucht primäres Profil (z.B. `synthesis_pro`)
+  2. Bei Fehler → `fallback_profile` (z.B. `synthesis_backup`)
+  3. Bei weiterem Fehler → nächster Fallback (z.B. `identity_safe`)
+  4. Terminaler Endpunkt: `identity_safe` hat keinen Fallback (lokales Modell)
+
+**Schutzmechanismen:**
+* **Zirkuläre Referenzen:** `visited_profiles`-Tracking verhindert Endlosschleifen
+* **Background-Semaphore:** Parallele Tasks werden gedrosselt (konfigurierbar via `BACKGROUND_LIMIT`)
+
+### 3. Pre-Synthesis Kompression (Module A)
+
+**Implementierung (`app/core/retrieval/decision_engine.py` v1.2.1):**
+* Wissens-Streams, die den Schwellenwert (`compression_threshold`) überschreiten, werden **asynchron verdichtet**, bevor sie die Synthese erreichen
+* **Konfigurierbar pro Stream:** Z.B. 2500 Zeichen für Values Stream, 3500 für Facts Stream
+* **Profil-gesteuert:** Nutzt `compression_profile` (z.B. `compression_fast` für schnelle Zusammenfassung)
+* **Parallelisierung:** Mehrere Streams können gleichzeitig komprimiert werden
+
+**Vorteile:**
+* Reduziert Token-Verbrauch bei langen Streams
+* Beschleunigt Synthese durch kürzere Kontexte
+* Erhält Relevanz durch intelligente Zusammenfassung
+
+### 4. Profilgesteuerte Ingestion (Wissens-Gatekeeper)
+
+**Implementierung:**
+* `app/core/ingestion/ingestion_processor.py` v2.14.0
+* `app/core/ingestion/ingestion_validation.py` v2.13.0
+
+**Features:**
+* Semantische Kanten-Validierung erfolgt zwingend über das MoE-Profil `ingest_validator` (Temperature 0.0 für Determinismus)
+* **Embedding-Konsolidierung:** Der `EmbeddingsClient` (v2.6.0) bezieht Modellvorgaben und Dimensionen direkt aus dem Profil `embedding_expert`
+* Entfernung der Embedding-Konfiguration aus der `.env` zugunsten zentraler Profil-Registry
+
+### 5. Startup-Schutz & Audit-Fixes
+
+**Implementierung (`app/main.py` v1.1.0):**
+* Verifiziert beim Booten die Existenz und Validität von `llm_profiles.yaml` und `decision_engine.yaml`
+* **Audit-Fix:** Behebung einer Sicherheitslücke in der `DecisionEngine`, durch die Fallback-Aufrufe bei Template-Fehlern die Profilsteuerung umgangen hätten
+* **Circular Import Fix:** Ingestion-Module nutzen nun die neutrale `app.core.registry` für Text-Bereinigung und Registry-Lookups
+
+---
+
+## 🔧 Technische Änderungen
+
+### Konfigurationsdateien
+
+**Neue Datei:**
+* `config/llm_profiles.yaml` v1.3.0: Zentrale Experten-Registry
+
+**Aktualisierte Dateien:**
+* `config/decision_engine.yaml` v3.2.2: Decoupled MoE Logic, Integration von `compression_thresholds`
+
+### Code-Komponenten
+
+| Komponente | Version | Änderungen |
+| :--- | :--- | :--- |
+| `app/services/llm_service.py` | v3.5.2 | Rekursive Fallback-Kaskade, Profil-Auflösung |
+| `app/core/retrieval/decision_engine.py` | v1.2.1 | Profile-Driven Orchestration, Pre-Synthesis Kompression |
+| `app/core/ingestion/ingestion_processor.py` | v2.14.0 | Profilgesteuerte Validierung |
+| `app/core/ingestion/ingestion_validation.py` | v2.13.0 | MoE-Profil `ingest_validator` |
+| `app/services/embeddings_client.py` | v2.6.0 | Profil-basierte Modell-Auflösung |
+| `app/main.py` | v1.1.0 | Startup-Validierung der YAML-Dateien |
+
+### Environment-Variablen
+
+**Neue Variable:**
+* `MINDNET_LLM_PROFILES_PATH`: Pfad zur Profil-Registry (Default: `config/llm_profiles.yaml`)
+
+**Legacy (nur noch Fallback):**
+* `MINDNET_LLM_PROVIDER`, `MINDNET_LLM_MODEL`, etc. dienen nur noch als Fallback, wenn kein Profil angegeben wird
+
+---
+
+## 🐛 Behobene Probleme
+
+- ✅ **Behoben:** Sicherheitslücke in der `DecisionEngine` - Fallback-Aufrufe nutzen nun korrekt `profile_name`
+- ✅ **Behoben:** Circular Import zwischen Ingestion-Modulen und Registry
+- ✅ **Behoben:** Fehlende Startup-Validierung der YAML-Konfigurationen
+
+---
+
+## 📚 Dokumentation
+
+**Aktualisierte Dokumente:**
+- ✅ `03_tech_configuration.md`: llm_profiles.yaml Dokumentation
+- ✅ `03_tech_chat_backend.md`: MoE Architektur und Fallback-Kaskade
+- ✅ `02_concept_ai_personality.md`: Mixture of Experts Konzept
+- ✅ `03_tech_ingestion_pipeline.md`: Profilgesteuerte Validierung
+- ✅ `00_glossary.md`: Neue Begriffe (MoE, Profile, Fallback-Kaskade)
+- ✅ `05_developer_guide.md`: Teach-the-AI mit Profilen
+- ✅ `04_admin_operations.md`: Konfigurations-Updates
+- ✅ `06_active_roadmap.md`: WP25a als abgeschlossen markiert
+
+---
+
+## 🚀 Migration & Upgrade
+
+### Für Administratoren
+
+1. **Neue Konfigurationsdatei erstellen:**
+   ```bash
+   cp config/llm_profiles.yaml.example config/llm_profiles.yaml
+   # Anpassen nach Bedarf
+   ```
+
+2. **Startup-Validierung prüfen:**
+   ```bash
+   # System startet nicht, wenn llm_profiles.yaml fehlt oder ungültig ist
+   python3 -m app.main
+   ```
+
+3. **ENV-Variablen (optional):**
+   Die `.env` Variablen `MINDNET_LLM_PROVIDER`, `MINDNET_LLM_MODEL` etc. dienen nur noch als Fallback. Die primäre Steuerung erfolgt über `llm_profiles.yaml`.
+
+### Für Entwickler
+
+**API-Änderungen:**
+* `LLMService.generate_raw_response()` unterstützt nun `profile_name` Parameter
+* Fallback-Kaskade erfolgt automatisch bei Fehlern
+* `visited_profiles`-Tracking verhindert Zirkel-Referenzen
+
+**Konfiguration:**
+* Neue Profile können in `llm_profiles.yaml` definiert werden
+* `decision_engine.yaml` referenziert Profile über `router_profile`, `llm_profile`, `compression_profile`
+
+---
+
+## 🔮 Ausblick (WP-25b: Prompt-Orchestration & Model-Specific Tuning)
+
+- Pre-Synthesis: LLM-basierte Komprimierung überlanger Streams (✅ bereits implementiert)
+- Kontext-Budgeting: Intelligente Token-Verteilung
+- Stream-specific Provider: Unterschiedliche KI-Modelle pro Wissensbereich
+- Prompt-Orchestration: Dynamische Prompt-Anpassung basierend auf Profil und Kontext
+
+---
+
+## 📊 Metriken & Performance
+
+**Erwartete Verbesserungen:**
+* **Resilienz:** Automatische Fallback-Kaskade reduziert Ausfallzeiten
+* **Token-Effizienz:** Pre-Synthesis Kompression reduziert Token-Verbrauch bei langen Streams
+* **Determinismus:** Profilgesteuerte Validierung (Temperature 0.0) erhöht Konsistenz
+* **Wartbarkeit:** Zentrale Profil-Registry vereinfacht Konfigurations-Management
+
+---
+
+**Status:** ✅ WP-25a ist zu 100% implementiert und audit-geprüft.  
+**Nächster Schritt:** WP-25b (Prompt-Orchestration & Model-Specific Tuning).