Zum Inhalt

Memory Lifecycle und Knowledge Operations

Stand: 2026-05-30

Kurzfazit

Hermes soll nicht nur Retrieval liefern, sondern ein kontrolliertes Organisationsgedaechtnis werden. Dafuer braucht die AI Suite einen klaren Lebenszyklus: Session-Inhalte werden zuerst Memory-Kandidaten, dann gepruefte Facts, Decisions, Runbook-Hints oder Profileintraege. Nichts davon wird automatisch als Wahrheit gespeichert.

Diese Seite ist Plan und Governance. Es wurden keine produktiven Memory-Eintraege, Qdrant-Punkte, Obsidian-Dateien oder Runtime-Jobs angelegt.

Memory Architecture Report

Schicht Rolle Aktueller Datenfluss Bewertung
Nous Memory Agent-, User- und Session-Kontext native Memory, USER/MEMORY, Sessions und Skills vorbereitet wichtig fuer Verhalten, aber nicht alleinige Wahrheitsquelle
Obsidian kuratierte Knowledge Source menschenlesbare Notizen, Entscheidungen, Runbooks, Profile beste Quelle fuer bestaetigtes Betriebswissen
Qdrant semantischer Retrieval-Index indiziert Obsidian/MkDocs/Inventory-Chunks Retrieval, nicht Governance
MkDocs publizierte Betriebsdoku versionierte Operator-Dokumentation verbindliche Betriebslesbarkeit
Vaultwarden Secrets Secret Source of Truth nicht indexieren, nicht in Memory speichern

Speicherung und Wiederfinden

Datentyp Primaerer Speicher Sekundaer Bemerkung
bestaetigte Infrastruktur-Fakten Obsidian/MkDocs Qdrant Index nur mit Quelle, Datum und Confidence
Entscheidungen Obsidian/MkDocs Qdrant Index, optional Nous Summary auditierbar halten
Runbook-Hinweise Obsidian/MkDocs Qdrant Index als Vorschlag, nicht als Secret
Session-Zusammenfassungen Nous Session / Review Inbox Obsidian nach Review nie automatisch confirmed
User Preferences Nous User Memory optional Obsidian wenn teamrelevant datensparsam
Team Preferences Obsidian Qdrant, optional Nous nur betriebliche Praeferenzen
Secrets Vaultwarden nein niemals in Obsidian/Qdrant/Nous Memory

Kurzlebiger Session-Kontext wird vergessen, wenn er keine betriebliche Wiederverwendbarkeit hat, unsicher ist, personenbezogen ohne Zweckbindung ist, Secret-nahe Inhalte enthalten koennte oder nur fuer einen einmaligen Troubleshooting-Schritt relevant war.

Hermes soll Wissen ueber exakte Referenzen, semantisches Qdrant Retrieval und native User-/Session-Memory finden. Native Memory ist Kontextsignal, nicht automatisch Governance-Wahrheit.

Fehlende Memory-Typen

Memory-Typ Status Naechster Schritt
Session Memory vorbereitet standardisierte Session Summary Preview
Long-Term Memory vorbereitet Review Inbox und Reindex Job
Team Memory konzeptionell Teamprofile mit Owner und Review-Zyklus
Infrastructure Memory teilweise vorhanden Drift, State, Changes und Runbooks verknuepfen
Decision Memory teilweise vorhanden Decision Records mit decision_id und supersedes
Skill Memory Nous Skills vorbereitet Skill-Kandidaten reviewen, nicht auto-aktivieren
Incident Memory fehlt Incident Timeline und Lessons Learned als eigener Typ
Preference Memory teilweise strikte Zweckbindung und Loeschbarkeit

Memory Candidate Lifecycle

flowchart TD
  Session["Session / Tool Output / Operator Note"] --> Extract["Candidate Extraction"]
  Extract --> Classify["Fact / Decision / Runbook Hint / Infra Knowledge / Preference"]
  Classify --> Safety["Secret and Sensitivity Check"]
  Safety --> Draft["draft / interpreted"]
  Draft --> Review["Human Fact Review"]
  Review --> Confirmed["confirmed"]
  Review --> Rejected["deprecated / rejected"]
  Confirmed --> Obsidian["Obsidian canonical note"]
  Obsidian --> Reindex["Server-side Qdrant Reindex"]
  Reindex --> Retrieval["Hermes Retrieval"]
Typ Beschreibung Standardstatus Ziel
Fact technisch oder organisatorisch pruefbare Aussage interpreted confirmed nach Review
Decision getroffene Architektur-/Betriebsentscheidung draft Decision Record
Runbook Hint Hinweis fuer Arbeitsanleitung draft Runbook-Ergaenzung
Infrastructure Knowledge System-, Abhaengigkeits- oder State-Wissen interpreted Obsidian/MkDocs + Qdrant
User Preference Arbeitsstil oder Anzeigevorliebe draft Nous User Memory, sparsam
Team Preference Teamweite Betriebsregel draft Obsidian Team Profile

Candidate Payload

candidate_id: "memcand-YYYYMMDD-..."
candidate_type: "fact|decision|runbook_hint|infrastructure_knowledge|user_preference|team_preference"
source_system: "opencode|openwebui|voice|teams|scheduled_workflow|manual"
source_reference: "<artifact-or-session-id>"
summary: "<short statement>"
evidence:
  - "<source reference without secrets>"
confidence: "low|medium|high"
status: "draft|interpreted"
sensitivity: "public_internal|restricted|secret_like"
requires_review: true
recommended_destination: "obsidian|mkdocs|nous_memory|discard"
expires_at: "YYYY-MM-DD|null"

Fact Review Governance

Rolle Darf
Operator Kandidaten erstellen und kommentieren
Reviewer Facts pruefen, Status auf confirmed oder deprecated setzen
Service Owner Infrastruktur-Facts fuer eigenen Service bestaetigen
Auditor Verlauf lesen, keine produktive Memory-Aenderung
Admin Review-Regeln und Retention verwalten
Status Bedeutung Retrieval-Verwendung
draft Rohkandidat, nicht vertrauenswuerdig nicht fuer Antworten nutzen
interpreted plausible Ableitung mit Quelle nur mit Hinweis
confirmed durch Mensch oder technischen Check bestaetigt bevorzugter Kontext
deprecated ersetzt oder falsch nicht als aktive Wahrheit nutzen
historical historisch korrekt, nicht aktueller Zielzustand nur mit Marker

Review Workflow:

  1. Candidate Preview erzeugen.
  2. Secret-/Sensitivity-Check ausfuehren.
  3. Quelle und Freshness pruefen.
  4. Owner bestimmen.
  5. Reviewer bestaetigt, korrigiert oder verwirft.
  6. Zielnotiz in Obsidian oder MkDocs aktualisieren.
  7. Reindex serverseitig ausfuehren.
  8. Audit-Eintrag ohne Secretwerte erzeugen.

Obsidian Governance v2

Zielstruktur:

00_Inbox/
10_Infrastructure/
20_AI_Suite/
30_Runbooks/
40_Decisions/
50_Incidents/
60_Teams/
70_Skills/
80_Profiles/
90_Historical/

Frontmatter v2:

---
title: "<Titel>"
memory_id: "mem-YYYYMMDD-..."
memory_type: "fact|decision|runbook|incident|profile|skill|historical"
status: "draft|interpreted|confirmed|deprecated|historical"
owner: "<person-or-team>"
reviewer: "<person-or-team|null>"
source_system: "opencode|openwebui|teams|voice|mkdocs|manual|scheduled_workflow"
source_reference: "<artifact-or-url-without-secret>"
systems: []
projects: []
tenants: []
tags: []
confidence: "low|medium|high"
last_verified_at: "YYYY-MM-DD"
review_after: "YYYY-MM-DD"
retention_policy: "session|90d|1y|permanent|audit"
supersedes: []
secret_free: true
qdrant_index: true
---

Tag-Namespaces:

Namespace Beispiel
system/ system/opencode, system/hermes, system/qdrant
domain/ domain/network, domain/m365, domain/proxmox
memory/ memory/fact, memory/decision, memory/runbook
status/ status/confirmed, status/historical
team/ team/operations, team/security
risk/ risk/low, risk/high

Automatischer Reindex

Reindex laeuft serverseitig, nicht auf dem Mac. Er nutzt Runtime-Secrets aus root-only Umgebung und Vaultwarden als Source of Truth.

Bestandteil Vorschlag
Service lanstyle-obsidian-reindex.service
Timer lanstyle-obsidian-reindex.timer
Ort Agent Runtime oder Hermes LXC
Input obsidian/lanstyle-vault, freigegebene MkDocs-Auszüge
Output Qdrant Collection lanstyle_obsidian_memory
Secrets Qdrant API Key, LiteLLM Embedding Key
Logs nur Counts, Status, Hashes, keine Inhalte
Rollback vorheriger Qdrant Snapshot / Collection Alias

Ablauf:

  1. Secret-Status pruefen: nur SET/MISSING.
  2. Obsidian Secret-Scan.
  3. Frontmatter-Schema validieren.
  4. Changed files bestimmen.
  5. Qdrant Snapshot erstellen.
  6. Reindex in Staging Collection.
  7. Retrieval Validation ausfuehren.
  8. Collection Alias umstellen, wenn Validation gruen.
  9. Audit und Report schreiben.

Retrieval Validation Framework

Dimension Pruefung
Retrieval Qualitaet findet bekannte Facts und Runbooks
Quellenqualitaet Treffer haben Owner, Status, Freshness
Aktualitaet last_verified_at und review_after plausibel
Abdeckung wichtige Systeme haben mindestens eine bestaetigte Quelle
Sicherheit keine Secret-Muster in Treffern
Halluzinationsschutz Antwort trennt confirmed/interpreted/uncertain

Testfragen:

  • Wo laeuft Hermes?
  • Was ist der Unterschied zwischen Gateway und Nous Core?
  • Wie funktioniert OpenCode als AI Operations Console?
  • Welche Schritte braucht ein Change Review?
  • Welche Inhalte duerfen nicht in Obsidian?
  • Welche Qdrant Collection ist fuer Obsidian Memory vorgesehen?

User-, Team- und Infrastructure-Profile

User Profiles speichern nur nutzbare, nicht-sensitive Arbeitspraeferenzen: Antwortlaenge, Sprache, Kanaele, Rollenreferenzen und kurzlebige Session-Zusammenfassungen.

Team Profiles speichern betriebliche Regeln: Change-Fenster, Review-Rollen, kritische Systeme, Namensregeln und Runbook-Konventionen.

Infrastructure Profiles speichern Service- und Abhaengigkeitswissen: Owner, kritische Pfade, Rollback-Faehigkeit, Restore-Runbook, letzte Verification und Drift-/Risk-Hinweise.

Knowledge Aging Model

Zustand Kriterium Aktion
aktuell last_verified_at innerhalb Review-Fenster normal nutzen
reviewbeduerftig review_after erreicht Retrieval mit Warnung
veraltet Quelle ersetzt oder Drift erkannt nicht als confirmed verwenden
historisch Migration/Audit/Canary-Kontext mit HISTORICAL markieren
deprecated falsch, ersetzt oder gefaehrlich nicht indexieren oder stark abwerten

Empfohlene Review-Fenster:

Inhalt Review-Zyklus
Netzwerk-/Firewall-Facts 90 Tage
AI Runtime Architektur 60 Tage
Runbooks 180 Tage
Decisions bei Aenderung, sonst 1 Jahr
Incident Lessons Learned 90 Tage nach Incident
User Preferences 180 Tage oder auf Wunsch

Doku-Konsolidierung

Aktive Memory-Zielseiten:

Historische Inhalte bleiben erhalten, muessen aber klar markiert werden:

  • HISTORICAL: nicht aktueller Zielpfad
  • ROLLBACK ONLY: nur Rueckfallkontext
  • AUDIT CONTEXT: Beleg fuer fruehere Entscheidung

Empfehlungen

  1. Memory-Kandidaten nie automatisch als confirmed speichern.
  2. Obsidian als kuratierte Quelle staerken, Qdrant nur als Index behandeln.
  3. Reindex serverseitig mit Snapshot/Validation/Audit aufbauen.
  4. Retrieval Validation vor jeder Aktivierung neuer Memory-Quellen verlangen.
  5. User-/Teamprofile datensparsam halten und loeschbar machen.
  6. Knowledge Aging in Retrieval-Antworten sichtbar machen.