[Proposal] Temporal Knowledge Graph as a companion to vector memory

[mrsteveken]

Summary

I have been using memory-lancedb-pro as my agent's primary long-term memory and it works great for semantic search. However, I found a class of queries that vector search handles poorly: structured, temporal facts.

Examples:

• "What version is the trading strategy at?" → needs exact value, not semantic similarity
• "What model did we use in March?" → needs temporal validity tracking
• "What decisions did we make about project X?" → needs structured predicate filtering

What I Built

As a separate companion plugin (memory-kg-lite), I added a temporal fact layer using SQLite:

• Data model: Subject → Predicate → Object triples with valid_from / valid_until windows
• Storage: Plain SQLite (no new infra dependencies)
• Query cost: Zero LLM tokens — all retrieval is SQL
• Tools: fact_add, fact_query, fact_invalidate, fact_list_recent

Example triples

subject	predicate	object	valid_from	valid_until
Steve	timezone	Asia/Shanghai	2026-02-01	—
MyQuant strategy	version	v11.1	2026-02-15	—
H5 data	format	XXXXXX.SZ	2026-02-05	—

Why a separate plugin?

• Different storage paradigm (relational vs vector)
• Keeps memory-lancedb-pro focused on what it does best
• Either plugin can be upgraded/disabled independently
• Optional cross-reference: triples can link to LanceDB memory IDs via source_id

Proposal for Upstream

Two options I'd like to discuss:

1. Official companion plugin — A separate package under the same org (e.g., memory-kg-lite) with optional LanceDB cross-references
2. Built-in fact table — Add an optional SQLite-backed fact layer inside memory-lancedb-pro itself (behind a config flag)

I lean toward option 1 (separation of concerns), but wanted to gauge interest before investing more in the standalone approach.

Measured Benefits

Query type	Before (vector only)	After (vector + KG)
"What version is X?"	Semantic search, often returns related-but-wrong results	SQL lookup, exact match, instant
"What did we decide about Y?"	Grepping daily logs or hoping vector search hits	fact_query(subject=Y, category=decision)
"What was true in March?"	Not possible — no temporal tracking	atDate=2026-03-15 parameter

Related Work

• MemPalace — local-first memory with knowledge graph and temporal reasoning
• Galadriel harness — Claude Code agent with MemPalace integration

Happy to share the full plugin spec or collaborate on a design if there's interest.

[hilyfux]

Strong proposal. I think the split from vector memory is exactly the right call: temporal facts are not just "more memories" — they need different correctness guarantees.

A few design details that have helped in similar agent-memory systems:

• Keep vector recall and triple recall separate until the final answer assembly step. If triples get embedded back into the semantic store too early, you lose the exactness that made them useful.
• Model invalidation as first-class history, not deletion. valid_until plus an optional superseded_by/source_event_id makes it much easier to debug why the agent believes the current value.
• Store evidence with every assertion: source note, conversation id, file path, or issue URL. Agents need to be able to say "I know this because...", especially when temporal state changes.
• Add a small deterministic eval set: current value, value at date, changed-since-date, and conflicting-fact queries. Those catch the difference between a useful temporal KG and a table that merely stores triples.

For a lightweight comparison, I maintain knowledge-graph (https://github.com/hilyfux/knowledge-graph), a git-native, zero-dependency memory layer that works with Claude Code and Codex. It is less database-oriented than your SQLite direction, but the same separation has been useful there: durable structured memory for exact facts, plain text/notes for context, and deterministic retrieval so failures are inspectable.