mindnet/docs/00_General/00_glossary.md

doc_type	audience	status	version	context
glossary	all	active	3.1.1	Zentrales Glossar für Mindnet v3.1.1. 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), WP-25b Lazy-Prompt-Orchestration und Mistral-safe Parsing.

Mindnet Glossar

Quellen: 01_edge_vocabulary.md, llm_service.py, ingestion.py, edge_registry.py, registry.py, qdrant.py

Kern-Entitäten

• Note: Repräsentiert eine Markdown-Datei. Die fachliche Haupteinheit. Verfügt über einen Status (stable, draft, system), der das Scoring beeinflusst.
• Chunk: Ein Textabschnitt einer Note. Die technische Sucheinheit (Vektor).
• Edge: Eine gerichtete Verbindung zwischen zwei Knoten. Wird in WP-22 durch die Registry validiert. Seit v2.9.1 unterstützt Edges Section-basierte Links (target_section), sodass mehrere Kanten zwischen denselben Knoten existieren können, wenn sie auf verschiedene Abschnitte zeigen.
• Vault: Der lokale Ordner mit den Markdown-Dateien (Source of Truth).
• Frontmatter: Der YAML-Header am Anfang einer Notiz (enthält id, type, title, status).

Komponenten

• Edge Registry: Der zentrale Dienst (SSOT), der Kanten-Typen validiert und Aliase in kanonische Typen auflöst. Nutzt 01_edge_vocabulary.md als Basis.
• LLM Service: Der Hybrid-Client (v3.3.6), der Anfragen zwischen OpenRouter, Google Gemini und lokalem Ollama routet. Verwaltet Cloud-Timeouts und Quoten-Management. Nutzt zur Text-Bereinigung nun die neutrale registry.py, um Circular Imports zu vermeiden.
• Retriever: Besteht in v2.7+ aus der Orchestrierung (retriever.py) und der mathematischen Scoring-Engine (retriever_scoring.py). Seit WP-14 im Paket app.core.retrieval gekapselt.
• Decision Engine (WP-25): Der zentrale Agentic Orchestrator, der Intents erkennt, parallele Wissens-Streams orchestriert und die Ergebnisse synthetisiert. Implementiert Multi-Stream Retrieval und Intent-basiertes Routing.
• Agentic Multi-Stream RAG (WP-25): Architektur-Paradigma, bei dem Nutzeranfragen in parallele, spezialisierte Wissens-Streams aufgeteilt werden (Values, Facts, Biography, Risk, Tech), die gleichzeitig abgefragt und zu einer kontextreichen Antwort synthetisiert werden.
• Stream-Tracing (WP-25): Kennzeichnung jedes Treffers mit seinem Ursprungs-Stream (stream_origin), um Feedback-Optimierung pro Wissensbereich zu ermöglichen.
• Intent-basiertes Routing (WP-25): Hybrid-Modus zur Intent-Erkennung mit Keyword Fast-Path (sofortige Erkennung von Triggern) und LLM Slow-Path (semantische Analyse für unklare Anfragen).
• Wissens-Synthese (WP-25): Template-basierte Zusammenführung der Ergebnisse aus parallelen Streams mit expliziten Stream-Variablen (z.B. {values_stream}, {risk_stream}), um dem LLM eine differenzierte Abwägung zu ermöglichen.
• Traffic Control: Verwaltet Prioritäten und drosselt Hintergrund-Tasks (z.B. Smart Edges) mittels Semaphoren und Timeouts (45s) zur Vermeidung von System-Hangs.
• Unknown Edges Log: Die Datei unknown_edges.jsonl, in der das System Kanten-Typen protokolliert, die nicht im Dictionary gefunden wurden.
• Database Package (WP-14): Zentralisiertes Infrastruktur-Paket (app.core.database), das den Qdrant-Client (qdrant.py) und das Point-Mapping (qdrant_points.py) verwaltet.
• LocalBatchCache (WP-15b): Ein globaler In-Memory-Index, der während des Pass 1 Scans aufgebaut wird und Metadaten (IDs, Titel, Summaries) aller Notizen für die Kantenvalidierung bereithält.

Konzepte & Features

• Hybrid Provider Cascade: Die intelligente Reihenfolge der Modell-Ansprache. Schlägt die Cloud (OpenRouter/Gemini) fehl, erfolgt nach Retries ein Fallback auf den lokalen Ollama (Quoten-Schutz).
• Deep Fallback (v2.11.14, WP20): Ein inhaltsbasierter Rettungsmechanismus in der Ingestion. Im Gegensatz zum technischen Fallback (bei Verbindungsfehlern) wird der Deep Fallback ausgelöst, wenn ein Cloud-Modell zwar technisch erfolgreich antwortet, aber inhaltlich keine verwertbaren Daten liefert (z. B. bei "Data Policy Violations").
• Silent Refusal (WP20): Ein Zustand, in dem Cloud-Provider (wie OpenRouter) die Verarbeitung eines Dokuments aufgrund interner Filter ("No data training") verweigern, ohne einen HTTP-Fehler zu senden. Wird durch Deep Fallback abgefangen.
• Rate-Limit Resilience (WP-20): Automatisierte Erkennung von HTTP 429 Fehlern. Das System pausiert (konfigurierbar via LLM_RATE_LIMIT_WAIT) und wiederholt den Cloud-Call, bevor der langsame Fallback ausgelöst wird.
• Mistral-safe Parsing: Robuste Extraktions-Logik in Ingestion und Analyzer, die technische Steuerzeichen (<s>, [OUT]) und Framework-Tags erkennt und entfernt, um valides JSON aus Free-Modellen zu gewinnen.
• Lifecycle Scoring (WP-22): Ein Mechanismus, der die Relevanz einer Notiz basierend auf ihrem Status gewichtet (z.B. Bonus für stable, Malus für draft).
• Intent Boosting: Dynamische Erhöhung der Kanten-Gewichte basierend auf der Nutzerfrage (z.B. Fokus auf caused_by bei "Warum"-Fragen).
• Provenance Weighting: Gewichtung einer Kante nach ihrer Herkunft:
  • explicit: Vom Mensch gesetzt (Prio 1).
  • semantic_ai: Von der KI im Turbo-Mode extrahiert und validiert (Prio 2).
  • structure: Durch System-Regeln/Matrix erzeugt (Prio 3).
• Smart Edge Allocation (WP-15b): KI-Verfahren zur Relevanzprüfung von Links für spezifische Textabschnitte. Validiert Kandidaten semantisch gegen das Ziel im LocalBatchCache.
• Matrix Logic: Bestimmung des Kanten-Typs basierend auf Quell- und Ziel-Entität (z.B. Erfahrung -> Wert = based_on).
• Two-Pass Workflow (WP-15b): Optimiertes Ingestion-Verfahren:
  • Pass 1 (Pre-Scan): Schnelles Scannen aller Dateien zur Befüllung des LocalBatchCache.
  • Pass 2 (Semantic Processing): Tiefenverarbeitung (Chunking, Embedding, Validierung) nur für geänderte Dateien.
• 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.
• 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.
• Lazy-Prompt-Orchestration (WP-25b): Hierarchisches Prompt-Resolution-System, das Prompts erst im Moment des Modellaustauschs lädt, basierend auf dem exakt aktiven Modell. Ermöglicht modell-spezifisches Tuning und maximale Resilienz bei Modell-Fallbacks.
• Hierarchische Prompt-Resolution (WP-25b): Dreistufige Auflösungs-Logik: Level 1 (Modell-ID) → Level 2 (Provider) → Level 3 (Default). Gewährleistet, dass jedes Modell das optimale Template erhält.
• PROMPT-TRACE (WP-25b): Logging-Mechanismus, der die genutzte Prompt-Auflösungs-Ebene protokolliert (🎯 Level 1, 📡 Level 2, ⚓ Level 3). Bietet vollständige Transparenz über die genutzten Instruktionen.
• Ultra-robustes Intent-Parsing (WP-25b): Regex-basierter Intent-Parser in der DecisionEngine, der Modell-Artefakte wie [/S], </s> oder Newlines zuverlässig bereinigt, um präzises Strategie-Routing zu gewährleisten.
• Differenzierte Ingestion-Validierung (WP-25b): Unterscheidung zwischen transienten Fehlern (Netzwerk, Timeout) und permanenten Fehlern (Config, Validation). Transiente Fehler erlauben die Kante (Datenverlust vermeiden), permanente Fehler lehnen sie ab (Graph-Qualität schützen).