# Architektur und Vertrauensgrenzen

```text
Lokale Knowledge-JSONs ──ro──┐
GLPI Knowledge Base ─────ro──┼──► Ingest ─► In-Memory Graph + Float32 Vectors
Agent runs.jsonl ─────────ro──┘                       │
                                                    ├──► Ollama Pool
                                                    ├──► Relation Thinking
                                                    ├──► Knowledge Consolidation / Research / Synthesis
                                                    ├──► SSE / Hierarchical LOD UI
                                                    └──► Batched Persistence
                                                          ├── staging drafts
                                                          ├── article metadata sidecars
                                                          ├── GLPI cache
                                                          └── SQLite/WAL graph.db
```

## Edge-Klassen

- `categorized_as`, `mentions`, `derived_from`: deterministisch aus lokalen oder GLPI-Daten.
- `research_evidence`: aus explizit kontrollierter Recherche, weiterhin `staging`.
- `related_to`, `depends_on`, `supports`, `contradicts`, `extends`, `same_topic`, `caused_by`: Qwen-Inferenz mit Confidence und Evidence.
- `rejected`: intern gespeicherte Prüfung ohne sichtbare Beziehung.

## Mehrstufiges Thinking und adaptive Artikelsynthese

```text
Kandidatenpaar
  └── Relation Thinking
        ├── rejected edge
        └── staging edge
              ├── Relationsrecherche nur bei Unsicherheit; Graphmaterialisierung erst nach akzeptierter Relation
              └── Cluster/Fast: kompatible Relationen eines Zyklus bündeln
                    └── Quellenverbund (3–8 Quellen)
                          ├── persistenter Work-Fingerprint → unveränderte Arbeit sofort überspringen
                          └── Artikelplanung: create / update / merge / skip
                                └── Aktualitätsrouting
                                      ├── zeitabhängig → kleine offene SearXNG-Runde
                                      └── statisch → Gemma intern-first
                                            ├── Autor meldet Evidenzlücke → gezielte kleine SearXNG-Runde
                                            └── Qwen Claim-Review
                                                  ├── akzeptiert → Staging
                                                  └── fehlende Claims → gezielte Repair-Recherche + Revision
```

Relation Thinking schreibt keine Artikel. Die sichtbare KB-Datei enthält ausschließlich das reguläre KB-Schema. Interne Planung, Bewertung, Confidence, Quellen-IDs und Rechercheprotokolle werden getrennt unter `BRAIN_DATA_DIR/article-metadata/` gespeichert. Frisch geladenes Artikel-Webmaterial wird zunächst nur unter `research-evidence/` persistiert. Erst eine vom finalen Reviewer tatsächlich für einen `supported`/`partially_supported` Claim verwendete Quelle wird als externer Graph-Node materialisiert, eingebettet und über `grounded_by` mit dem Staging-Artikel verbunden. Dadurch erzeugt bloßes Suchen keinen dauerhaften Graph-Fan-out.

Details: `ADAPTIVE-ARTICLE-WORKFLOW.md`.

## Schreibmodell

Produktive Knowledge-Dateien und GLPI sind read-only. AI-THINK wird nur in das konfigurierte Staging geschrieben. Ein prozessweiter Coordinator dedupliziert Dateischreibvorgänge und schreibt sie seriell vor der Graphtransaktion.

Der Graph Store verwendet `modernc.org/sqlite` über `database/sql`. Nodes, Edges und binäre Float32-Vektoren werden nur bei Änderungen geschrieben. WAL erlaubt eine kompakte laufende Journaldatei; der Export-Endpunkt erzeugt mit `VACUUM INTO` eine portable Einzeldatei ohne WAL-Sidecars.

## Ollama-Pool

Chat- und Embeddingaufrufe werden als vollständige Requests geroutet. Healthchecks prüfen Erreichbarkeit und Modelle. Ein Per-Node-Inflight-Limit verhindert lokale Überlastung. Failover verändert keine produktiven Daten, da Schreiboperationen erst nach erfolgreicher Inferenz deterministisch ausgeführt werden.

## Hierarchische Render-Schicht

Der persistierte Wissensgraph bleibt vollständig. Das Frontend leitet eine temporäre LOD-Struktur ab:

```text
Full Graph
└── Cortex-Region
    └── Themenwolke
        └── lokale Gruppe
            └── einzelner Wissensknoten
```

Außenkanten werden nach sichtbaren Endpunkten, Relationstyp, Richtung, Herkunft und Status aggregiert. Aktivität öffnet nur den betroffenen Hierarchiepfad.

## Distributed Source-Agent runtime

`BRAIN_MODE` selects one of two startup graphs in the same executable. `brain` initializes the Graph, Ollama, knowledge scanner, article pipeline, Source Agent registry and Source Inbox. `agent` initializes only the source-poller runner, local dedupe/config cache and a minimal health/status HTTP server.

Remote discovery follows `Agent -> authenticated batch ingest -> Source Inbox -> embedding/ANN relevance classification -> candidate archive`. Article evidence acquisition follows `internal KB -> Source Inbox -> SearXNG`, and permanent graph materialization happens only after claim-level grounding.

## Startup-Gate und kausale Telemetrie

Der HTTP-Server bleibt während des Startups erreichbar. GPU-/Graph-schwere autonome Workflows warten jedoch auf den initialen Knowledge-/Embedding-Bootstrap. Ein fataler Knowledge-Scan hält den Gate geschlossen und wird periodisch erneut versucht. Workflow-Telemetrie verwendet explizite MutationStats; globale Graph-Deltas dienen nur noch der chronologischen Timeline.