knowmindknowmind
DokumentationQuickstartAnbindungReferenzFehlerbehebung
DEEN

Konzept

Bi-temporale Historie

knowmind hält Fakten nicht als „letzter Stand", sondern mit zwei Zeitachsen: gültig wann (valid_from / valid_to) und gewusst wann (created_at / updated_at). Damit beantwortet knowmind nicht nur „Was wissen wir heute?" sondern auch „Was wussten wir am 14. März?".

Worum es geht

In klassischen Datenbanken überschreibt eine Aktualisierung den alten Wert. Die Historie ist verloren, sobald keine separate Versionierungs-Tabelle geführt wird. knowmind nutzt eine bi-temporale Modellierung: Aktualisierungen ersetzen nichts — stattdessen bekommt die alte Aussage einen Endzeitpunkt (valid_to), eine neue Aussage wird mit valid_from erzeugt, beide bleiben über eine SUPERSEDES-Beziehung verbunden.

Wann es relevant ist

  • Vertragsdaten, die sich periodisch ändern (Adresse, Vertragspartner, Tarif).
  • Beratungs-Mandate, in denen Entscheidungen revidiert werden — die Begründung der Revision soll auditierbar bleiben.
  • Compliance-relevante Aussagen, bei denen der Stand zu einem bestimmten Zeitpunkt rückwirkend rekonstruiert werden muss.

Wie es funktioniert

Statt eine Erinnerung direkt zu bearbeiten, rufen Sie knowmind.update_fact auf. knowmind setzt automatisch:

  1. valid_to der alten Erinnerung gleich jetzt.
  2. Eine neue Erinnerung mit valid_from gleich jetzt und Ihrem aktualisierten Inhalt.
  3. Eine SUPERSEDES-Beziehung von neu auf alt.

Bei einer Punkt-in-Zeit-Frage über knowmind.recall_at_time filtert die Recall-Pipeline auf valid_from ≤ as_of und (valid_to > as_of OR valid_to IS NULL) — Sie sehen nur, was zu dem Zeitpunkt gültig war.

Beispiel

Zwei Versionen einer Erinnerung mit ihren Gültigkeitsfenstern. Recall liefert jeweils die zum gefragten Zeitpunkt gültige Version.
text
Stand am 01.02.2026:
  Erinnerung „Anschrift Müller GmbH":
    content    = "Müller GmbH, Hauptstraße 1, 32108 Bad Salzuflen"
    valid_from = 2024-09-01
    valid_to   = NULL (gilt unbegrenzt)

01.06.2026 — Umzug der Müller GmbH. Aufruf:
  knowmind.update_fact(
    target_id   = "memory_mueller_adresse_v1",
    new_title   = "Anschrift Müller GmbH ab 01.06.2026",
    new_content = "Müller GmbH, Industriestraße 7, 32756 Detmold",
    update_reason = "Umzug zum 01.06.2026"
  )

Stand danach:
  Erinnerung „Anschrift Müller GmbH" (v1):
    content    = "Müller GmbH, Hauptstraße 1, 32108 Bad Salzuflen"
    valid_from = 2024-09-01
    valid_to   = 2026-06-01

  Erinnerung „Anschrift Müller GmbH ab 01.06.2026" (v2):
    content    = "Müller GmbH, Industriestraße 7, 32756 Detmold"
    valid_from = 2026-06-01
    valid_to   = NULL
  + Beziehung: v2 -[:SUPERSEDES]-> v1

Recall am 15.06.2026:
  „Wo sitzt Müller GmbH?" → v2 (Detmold)

Recall_at_time am 01.04.2026:
  „Wo sitzt Müller GmbH?" → v1 (Bad Salzuflen)

Was es für die Praxis bedeutet

  • Aktualisierungen sind unproblematisch — die Historie bleibt.
  • Audits, die nachvollziehen müssen, was zu einem Zeitpunkt galt, sind einfach umsetzbar.
  • Wer wirklich löschen muss (DSGVO Art. 17), nutzt die vollständige Arbeitsbereich-Löschung oder eine manuelle Löschung über die Lösch-API. Bi-temporale Historie ersetzt das nicht.
  • Sie sollten Anweisungen für die KI im Memory-Pack so formulieren, dass sie bei Konflikten update_fact statt direkter Überschreibung verwendet.

Weiterführend