# Runtime Controls, Ansichten, Source-Filter und ECO Die Fullscreen-Oberfläche kann Hintergrundprozesse und Darstellung ohne Neustart umschalten. Änderungen gelten sofort im Arbeitsspeicher und werden gebündelt in `BRAIN_DATA_DIR/runtime-settings.json` persistiert. ## Living-only Die Schalter **LEARNING** und **THINKING** befinden sich direkt in der unteren Steuerleiste. - **Learning aus**: geplante lokale Scans, Reindex, GLPI-KB-Synchronisation und neue Embeddings werden pausiert. Der vorhandene In-Memory-Graph bleibt nutzbar. - **Thinking aus**: automatische und manuelle AI-THINK-Zyklen, neue KI-Edges, Artikelsynthese und zugehörige Recherche werden pausiert. - Sind beide Schalter aus, bleibt die Visualisierung im **LIVING**-Modus. Eingehende Agent- oder Knowledgebase-Anfragen dürfen weiterhin tatsächlich verwendete Notes aktivieren, starten aber keinen autonomen Zyklus. Ein bereits laufender Ollama-Aufruf wird nicht hart abgebrochen. Die Deaktivierung verhindert nachfolgende Schritte und neue Zyklen. ## Honeycomb-Ansicht Mit **HONEYCOMB** wird die semantische Graphansicht durch eine gleichmäßig besetzte dreidimensionale Wabenstruktur ersetzt. - Gerendert werden nur `knowledge`, `ai-think` und `external`. - Die Punkte liegen auf einem dicht gepackten 3D-Gitter mit einheitlichem Abstand. - Das Gitter wird auf die mathematische 3D-Grenze der beiden Gehirnhälften beschnitten. - Der Abstand wird automatisch so gewählt, dass alle sichtbaren Notes in die Gehirnform passen. - Edges, Partikelpfade, Cortex-Flächen und LOD-Supernodes werden in dieser Ansicht nicht gerendert. - Wird eine Note durch Agent, Knowledgebase, Retrieval oder AI-THINK referenziert, leuchtet ihr Wabenpunkt auf. Die Slotbelegung bleibt bei Graphupdates stabil. Neue Notes belegen freie Plätze, statt die komplette Wabe neu zu sortieren. ## Constellation-Ansicht Mit **CONSTELLATION** werden semantische Themenbereiche als ruhige Zentren mit umlaufenden Wissenssternen dargestellt. Aggregierte Verbindungen machen Wissensbrücken sichtbar, ohne jede Einzelkante zu rendern. Aktivierte Notes und Rechercheereignisse bleiben sichtbar. ## ECO-Modus Der persistierbare Schalter **ECO** optimiert die Darstellung für schwächere Systeme, ohne die Kernanimationen zu entfernen. Er begrenzt die Ausgabe auf ungefähr 30 FPS, reduziert Device-Pixel-Ratio sowie Budgets für inaktive Edges, Partikel, Wolken, Sterne und Quellenpunkte. Aktive Nodes, Rechercheanimationen, Fade-Übergänge und Themenzentren bleiben erhalten. Der ECO-Modus ist unabhängig vom GPU-Node-Limit: ECO reduziert die Kosten pro Frame, das Node-Limit reduziert die Anzahl aufgebauter Elemente. ## GPU-Limit für schwächere Systeme `max_display_nodes` begrenzt die Anzahl der Nodes, die im Browser für Neural, Honeycomb und Constellation aufgebaut werden. `0` bedeutet unbegrenzt. Die Begrenzung wird nach dem Anzeige-Source-Filter angewendet. Das vollständige Wissen bleibt im Backend und im geladenen Graph-Snapshot erhalten. Die Auswahl ist stabil und bevorzugt aktive Notes, AI-THINK-/Staging-Inhalte, Hubs und eine Grundabdeckung der vorhandenen Themenbereiche. Wird eine aktuell nicht dargestellte Note von Agent, Knowledgebase oder AI-THINK angefordert, ersetzt sie temporär einen inaktiven Node. Nach der Aktivitätsphase greift wieder die stabile Grundauswahl. Im Web befindet sich die Einstellung unter **FILTER → GPU-Limit**. Voreinstellungen für 1.000, 5.000, 10.000 und 25.000 Nodes sind enthalten. ```env BRAIN_MAX_DISPLAY_NODES=5000 ``` Zulässig sind Werte von `0` bis `500000`. ## Exakte Source-Filter Das frühere Kategorie-/Source-Doppelfiltersystem wurde vollständig entfernt. Gefiltert wird nur nach dem exakten Wert des top-level JSON-Feldes `source` eines KB-Dokuments. Beispiel: ```json { "id": "KB-AD-001", "title": "Active Directory prüfen", "source": "internal-category" } ``` Dazu passt ausschließlich: ```text internal-category ``` Nicht passend sind `Internal-Category`, `glpi-kb`, ein technischer `origin`-Wert oder eine Kategorie des Artikels. Vor dem Vergleich werden lediglich äußere Leerzeichen entfernt; Groß-/Kleinschreibung bleibt relevant. Für gelernte Webbelege wird als explizite Quelle der Hostname gesetzt, zum Beispiel `learn.microsoft.com`. Nodes ohne `source` erscheinen bei einer konkreten Auswahl nicht als eigener synthetischer Filterwert; sie bleiben nur bei „Alle“ sichtbar beziehungsweise nutzbar. ### Lernen `learning_sources` steuert: - welche neuen oder geänderten Nodes eingebettet werden; - welche vorhandenen Vektoren bei semantischen Abfragen berücksichtigt werden. Bereits gespeicherte Vektoren anderer Quellen bleiben in `graph.db`, sind unter dem aktuellen Filter aber inaktiv. Eine spätere Freigabe erfordert daher kein erneutes Embedding. ### Anzeige `display_sources` begrenzt die sichtbaren Wissens-Nodes. Wissens-Nodes mit einem anderen `source`-Wert werden nicht über semantische Kanten hereingezogen. In der Neural-Ansicht dürfen direkt verbundene `category`, `source` und `concept`-Taxonomieknoten als visueller Kontext mitgeführt werden. Honeycomb zeigt weiterhin nur Notes. Der Anzeige-Filter ist eine Rendersteuerung und keine Zugriffskontrolle. `/api/graph` liefert weiterhin den vollständigen Graphen. ### Thinking `thinking_sources` begrenzt: - beide Nodes eines Relationskandidaten; - Quellen eines Themenverbunds; - Knowledge-Synthesis-Quellen; - wiederverwendete Research-Evidence; - neu akzeptierte SearXNG-Volltextbelege. Mehrere ausgewählte Quellen verwenden ODER-Semantik. Eine leere Liste bedeutet in allen drei Bereichen **alle Source-Werte**. ## GLPI-Source Der genaue Source-Wert aller GLPI-KB-Nodes wird durch folgende Variable festgelegt: ```env GLPI_KB_SOURCE=GLPI Knowledge Base ``` Genau dieser Wert wird in `metadata.source` der GLPI-Nodes gespeichert und steht in der WebUI immer zur Auswahl – auch vor dem ersten GLPI-Sync, bei deaktiviertem GLPI-Ingest oder bei aktuell 0 Beiträgen. Der technische Origin `glpi-kb` ist absichtlich kein Alias und wird nicht als Treffer behandelt. ## Konfiguration und Persistenz ```env BRAIN_LEARNING_ENABLED=true BRAIN_THINKING_ENABLED=true # Exakte Werte des JSON-Feldes source; kommagetrennt, leer = alle BRAIN_LEARNING_SOURCES= BRAIN_DISPLAY_SOURCES= BRAIN_THINKING_SOURCES= BRAIN_DEFAULT_VIEW=neural BRAIN_MAX_DISPLAY_NODES=0 BRAIN_LOW_POWER_MODE=false ``` Die drei Environment-Listen sind ausschließlich Startwerte. Sobald die neue WebUI-Konfiguration gespeichert wurde, ist `runtime-settings.json` maßgeblich. Es gibt keine zusätzliche ENV/WebUI-Schnittmenge. Die neue Datei kennzeichnet die Semantik mit: ```json { "source_filter_version": 1 } ``` Alte Kategorie-Felder sowie unversionierte Source-Auswahlen werden bei der Umstellung bewusst ignoriert. Learning-/Thinking-Schalter, Ansicht, Node-Limit und ECO-Wert werden weiterhin feldweise übernommen. `graph.db` muss nicht gelöscht werden. ## API ```http GET /api/runtime-settings PUT /api/runtime-settings GET /api/sources ``` `GET /api/sources` enthält die exakt im Graph gefundenen Source-Werte mit Anzahl und zusätzlich immer den aktuell konfigurierten Wert aus `GLPI_KB_SOURCE`. Beispiel: ```bash curl -X PUT http://localhost:8090/api/runtime-settings \ -H 'Content-Type: application/json' \ -d '{ "source_filter_version": 1, "learning_enabled": true, "thinking_enabled": true, "learning_sources": ["internal-category", "GLPI Knowledge Base"], "display_sources": ["GLPI Knowledge Base"], "thinking_sources": ["internal-category", "learn.microsoft.com"], "view_mode": "constellation", "max_display_nodes": 5000, "low_power_mode": true }' ``` Ist `BRAIN_API_KEY` gesetzt, benötigt der PUT-Aufruf `Authorization: Bearer …` oder `X-Brain-Key`.