glpi-neural-brain/ANALYSIS-DASHBOARD.md

BRAIN ANALYSIS CENTER

Das technische Analyse-Dashboard ist von der animierten Gehirnansicht getrennt:

• Visualisierung: http://localhost:8090/
• Analyse: http://localhost:8090/analysis.html
• Kurzpfad: http://localhost:8090/analysis

Zweck

Das Dashboard soll nicht nur einzelne Events anzeigen, sondern beantworten:

• Was hat ein Workflow tatsächlich bewirkt?
• Wie lange dauerte er und wo liegen P50/P95-Ausreißer?
• Wie viele Nodes, Edges oder Embeddings wurden erzeugt, verändert oder gelöscht?
• Wie teuer waren Artikel-, Research-, Security- und THINK-Läufe relativ zueinander?
• Wurde Research aus der Source Inbox wiederverwendet oder musste SearXNG arbeiten?
• Wie viele Security-Meldungen wurden materialisiert, verworfen oder sind fehlgeschlagen?
• Welche Claims hat der Article Reviewer unterstützt, nur teilweise gestützt, verworfen oder als widersprüchlich bewertet?
• Ist die Analysehistorie vollständig genug oder wurde sie von Telemetrie-/Queue-Limits beschnitten?

Persistentes Auditprotokoll

Die Historie liegt in BRAIN_DATA_DIR/graph.db:

analysis_events
analysis_points
analysis_changes

analysis_events enthält Aktivitäten und Metadaten. analysis_points speichert den dazugehörigen Graphzustand und exakte Mutation-Deltas. analysis_changes enthält die konkreten Node-, Edge- und Vector-Änderungen.

Die Rohhistorie wird 90 Tage aufbewahrt. Detailänderungen sind pro Event auf 2.000 Datensätze begrenzt; die aggregierten Mutation-Zähler bleiben auch bei Kürzung vollständig.

Event-Hygiene

Hochfrequente Hintergrundtelemetrie darf fachlich relevante Läufe nicht aus dem Analysefenster verdrängen.

Unveränderte KB-Scans

learning.scan.started wird nicht mehr separat persistiert. Ein learning.scan.completed mit result=unchanged und ohne Graphänderung wird gesammelt. Standardmäßig werden bis zu 15 solcher Läufe beziehungsweise maximal fünf Minuten zu einem Event verdichtet:

learning.scan.unchanged.aggregate

Das Aggregate enthält unter anderem:

• exakte Anzahl der Scan-Läufe,
• äquivalente Zahl früherer Roh-Events,
• First/Last Timestamp,
• Gesamt-, Durchschnitts-, Minimal- und Maximallaufzeit,
• Zahl der geprüften Wissenselemente,
• Ollama-Status.

Embedding-Batches

Repetitive embedding.batch-Fortschrittsereignisse werden ebenfalls verdichtet. Bis zu 16 Batch-Events beziehungsweise maximal 60 Sekunden werden zu

embedding.batch.aggregate

zusammengefasst. Anders als bei reiner Telemetrie bleiben hierbei die Mutation-Deltas erhalten: Vector-Created/Updated/Deleted werden exakt aufsummiert und vorhandene Detailänderungen in das Aggregate übernommen.

Bestehende Datenbanken

Alte Rohdaten werden nicht gelöscht oder umgeschrieben. Beim Lesen des Dashboards werden historische unveränderte Scans und historische Embedding-Batches zusätzlich virtuell verdichtet. Dadurch wird eine bestehende graph.db sofort übersichtlicher.

Der Bereich Analysequalität / Event-Hygiene zeigt:

• persistierte Events,
• tatsächlich geladene aussagekräftige Events,
• verdichtete No-op-Scans,
• verdichtete Embedding-Batches,
• durch die neue Persistenz künftig vermiedene Roh-Events,
• ausgelassene Events durch das Anzeige-Limit,
• Audit-Queue-Fehler oder verworfene Detailänderungen.

Laufmodell

Zusammengehörige Events werden zu Workflows gruppiert. Unterstützt werden unter anderem:

• learning
• thinking
• research
• autonomous-research
• security-source
• article
• query
• searxng-test
• Persistenz-/Synchronisationsaktionen

Article Pipeline

Ein Artikellauf beginnt bei article.plan.started und endet bei einem Terminal-Event wie:

article.created
article.draft.rejected
article.failed
article.duplicate
article.skipped
article.plan.skipped

Zwischenereignisse wie Draft, Rewrite, Inbox Research, SearXNG Research, Revision und Review werden demselben Lauf zugeordnet.

Security Source Pipeline

Neue proactive Security-Verarbeitung erzeugt einen echten Lifecycle:

source.security.started
  -> source.security.research       optional
  -> source.security.materialized
     | source.security.rejected
     | source.security.failed

Die Terminal-Events enthalten duration_ms. Damit sind ab dieser Version echte Laufzeitstatistiken für Security-Materialisierung möglich. Ältere bereits materialisierte Security-Nodes bleiben in den Zählern sichtbar, besitzen aber rückwirkend keine rekonstruierbare Startzeit.

Research Lifecycle

Nur Root-Events öffnen oder schließen einen Research-Lauf:

research.started / completed / failed
article.research.started / completed / failed

Fetch-, Ranking-, Material- und Evidence-Events sind Unterereignisse. Doppelte native Run-IDs erzeugen keinen zweiten aktiven Prozess. Historische Relationsrecherchen ohne Terminal-Event können nach einer Grace-Period als Legacy-Abschluss rekonstruiert werden.

Workflow-Kosten

Der Bereich Ressourcen / Laufzeit aggregiert pro Workflow-Typ:

• Anzahl Läufe,
• Success/Warning/Error/Running,
• Anzahl Events,
• summierte Graphmutationen,
• Gesamtzeit,
• Durchschnitt,
• P50,
• P95,
• Maximum.

Die Gesamtzeit ist eine aufsummierte Workflow-Zeit und bei parallelen Läufen nicht mit Wall-Clock-Zeit gleichzusetzen.

Das Laufprotokoll kann sortiert werden nach:

• neueste zuerst,
• langsamste zuerst,
• meiste Graphänderungen,
• meiste Events.

Pipeline-Bilanzen

Security Pipeline

Das Dashboard zeigt separat:

• materialisierte Meldungen,
• verworfene Meldungen,
• Fehler,
• Zusatzrecherchen,
• ergänzende Quellen,
• durchschnittliche Gemma-Konfidenz,
• Severity-Verteilung,
• Security-Eventtyp-Verteilung,
• letzte Security-Läufe samt Dauer und Mutationen.

Article Pipeline

Separat dargestellt werden:

• erzeugte Artikel,
• Reviews,
• Rejections/Failures,
• Duplicates/Skips,
• Source-Inbox-Treffer,
• Web-Fetches,
• supported / partially-supported / unsupported / contradicted Claims,
• letzte Artikelläufe.

Änderungssemantik

Nodes

• created: neue Node-ID wurde aufgenommen.
• updated: vorhandene Node wurde mit geändertem Inhalt ersetzt.
• deleted: Node ist aus einer verwalteten Quelle verschwunden.

Edges

• created: neue Relation wurde aufgenommen.
• updated: Typ, Status, Confidence, Evidenz oder Metadaten wurden verändert.
• deleted: Relation wurde entfernt.

Vektoren

• created: Node erhielt erstmals ein Embedding.
• recalculated: vorhandenes Embedding wurde ersetzt.
• deleted: Vektor wurde invalidiert oder der Node entfernt.

Queue-Diagnostik

Die Ollama-/Research-Zusammenfassung zeigt neben Active/Waiting auch Operationstypen wie:

searxng.search
web.fetch
ollama.chat
ollama.embedding

Damit lässt sich unterscheiden, ob Arbeit wirklich ausgeführt wird oder nur auf GPU-/Queue-Kapazität wartet.

HTTP-API

GET /api/analysis/dashboard?hours=24&limit=400
GET /api/analysis/export?hours=24&limit=1000

hours ist auf 1 bis 2.160 Stunden begrenzt. limit ist auf maximal 1.000 Events/Läufe begrenzt. Der Dashboard-JSON-Export verwendet standardmäßig 1.000, damit Diagnoseexporte deutlich mehr Workflow-Kontext enthalten.

Neue History-Bereiche:

{
  "history": {
    "event_selection": {},
    "run_stats": [],
    "pipelines": {
      "security": {},
      "articles": {}
    },
    "runs": [],
    "events": [],
    "changes": [],
    "timeline": []
  }
}

Performance

Die Analyseaufzeichnung bleibt außerhalb des Engine-Hotpaths:

1. Graphmutationen aktualisieren konstante Zähler und begrenzte Detaildaten.
2. Activities übernehmen nur einen billigen Graphcheckpoint.
3. Hintergrundtelemetrie wird vor der SQLite-Persistenz verdichtet.
4. Audit-Records werden asynchron und gebündelt geschrieben.
5. Die aufwendige strukturelle Graphanalyse wird erst beim Öffnen des Dashboards berechnet und nach Graphversion gecacht.
6. Die animierte Gehirnansicht lädt die Analysehistorie nicht.

Es sind für die Observability-V2-Änderungen keine neuen ENV-Variablen erforderlich.

Production Readiness v1

Das Dashboard unterscheidet jetzt globale Timeline-Deltas von kausal einem Workflow zugeordneten Mutationen. Bei Parallelität wird eine unbekannte Kausalität ausdrücklich als „nicht kausal gemessen“ angezeigt statt fremde Graphänderungen einem offenen Run zuzuschreiben. Security-Runs werden zusätzlich mit dem autoritativen Source-Inbox-Lifecycle reconciled.

Der Bereich Produktionsreife prüft Startup-Bootstrap, Audit-Verlust, Embedding-Coverage/-Dimension, Scan-Cadence, Persistenz, Ollama/Artikelmodelle, SearXNG, Agenten, Source-Inbox↔Graph und die Security-Run-Rekonstruktion. Rot ist ein Betriebsblocker; Gelb ist ein plausibler Übergangs- oder Tuningzustand.