knowmindknowmind
DokumentationQuickstartAnbindungReferenzFehlerbehebung
DEEN
knowmindknowmind
DocumentationQuickstartIntegrationsReferenceTroubleshooting
DEEN

Concept

Bi-temporal history

knowmind does not keep facts as "last value". It keeps two time axes: valid when (valid_from / valid_to) and known when (created_at / updated_at). That lets knowmind answer not only "What do we know today?" but also "What did we know on 14 March?".

What this is about

In classic databases an update overwrites the old value. The history is lost unless you maintain a separate versioning table. knowmind uses bi-temporal modelling: updates replace nothing — instead the previous statement gets an end timestamp (valid_to), a new statement is created with valid_from, and both stay connected through a SUPERSEDES relation.

When it matters

  • Contract data that changes periodically (address, counterparty, plan).
  • Consulting mandates where decisions are revised — the rationale for the revision must stay auditable.
  • Compliance-relevant statements where the state at a specific point in time must be reconstructible.

How it works

Rather than editing a memory directly, you call knowmind.update_fact. knowmind sets, atomically:

  1. valid_to of the old memory = now.
  2. A new memory with valid_from = now and your updated content.
  3. A SUPERSEDES relation from new to old.

For a point-in-time question via knowmind.recall_at_time, the pipeline filters on valid_from ≤ as_of and (valid_to > as_of OR valid_to IS NULL) — you see only what was valid at that moment.

Example

Two versions of a memory with their validity windows. Recall returns the version that was valid at the queried point in time.
text
Status on 2026-02-01:
  Memory "Müller GmbH address":
    content    = "Müller GmbH, Hauptstraße 1, 32108 Bad Salzuflen"
    valid_from = 2024-09-01
    valid_to   = NULL (open-ended)

2026-06-01 — Müller GmbH moves. Call:
  knowmind.update_fact(
    target_id     = "memory_mueller_address_v1",
    new_title     = "Müller GmbH address from 2026-06-01",
    new_content   = "Müller GmbH, Industriestraße 7, 32756 Detmold",
    update_reason = "Move effective 2026-06-01"
  )

Status afterwards:
  Memory "Müller GmbH address" (v1):
    content    = "Müller GmbH, Hauptstraße 1, 32108 Bad Salzuflen"
    valid_from = 2024-09-01
    valid_to   = 2026-06-01

  Memory "Müller GmbH address from 2026-06-01" (v2):
    content    = "Müller GmbH, Industriestraße 7, 32756 Detmold"
    valid_from = 2026-06-01
    valid_to   = NULL
  + Relation: v2 -[:SUPERSEDES]-> v1

Recall on 2026-06-15:
  "Where is Müller GmbH based?" → v2 (Detmold)

Recall_at_time on 2026-04-01:
  "Where is Müller GmbH based?" → v1 (Bad Salzuflen)

What this means in practice

  • Updates are safe — the history is preserved.
  • Audits that need to reconstruct the state at a given time are straightforward.
  • If you really must delete (GDPR Art. 17), use full workspace deletion or a manual delete via the deletion API. Bi-temporal history does not replace this.
  • Phrase your AI instructions in the Memory Pack so that the AI uses update_fact on conflicts rather than overwriting.

Related