OntoGr: Adding Citation Traceability and Bi-Temporal Axes to Agent Memory

Every fact must carry its exact words, source, and time — this is the new baseline that OntoGr Agent Memory seeks to establish for AI Agent memory systems.

Why Agent Memory Needs Traceability

Anyone who has built RAG and Agent memory systems has likely encountered the same trust problem: the Agent stores something it learned, but after some time, nobody can clearly say where it came from, whether it's still true, and what the system actually "believed" on some earlier date. According to the project's launch post on Reddit, this is precisely the core pain point OntoGr aims to solve.

The author has built it into an open-source Python library. Rather than simply "stuffing more things into a vector database," the approach is to establish a complete chain of evidence for every fact. The image below is the project's original launch post on Reddit.

Core Design: Every Fact Retains Its Exact Words, Source, and Time

OntoGr's differentiation centers on "source fidelity" for facts. During ingestion, messages, documents, tool outputs, events, and record rows are first converted into episodes; then entity extraction and fact extraction run as two independent passes, and every fact must carry a verbatim quote from its originating episode. This means any subsequent read can trace a fact back to the original text, rather than seeing only a model-generated summary.

This design is especially friendly for audit scenarios. When an Agent's conclusion is questioned, you can directly present the exact sentence it was based on, rather than re-running inference to "guess."

Time Model: Bi-Temporal Axes and Reversible Merging

The two areas the author particularly seeks feedback on in the post are the time model and entity resolution.

Bi-temporal axes distinguish valid time from system time. A single read can ask either "what was factually true on a given date" or "what the system believed on that date." When a new value appears, the old version is closed rather than overwritten — historical versions are preserved, which is a clear departure from the common vector database practice of "direct upsert overwrite."

Reversible entity resolution follows a "cheapest evidence first" principle, invoking model judgment only for ambiguous pairs, and every merge can be undone. Combined with per-tenant ontology — where each tenant defines the allowed entity and relation types, and the model can propose new types but they must be approved by a human — the entire system makes a clear trade-off between automation and controllability.

Bi-temporal is a well-established concept in databases and temporal knowledge graphs, typically splitting time into two independent dimensions: valid time describes the time interval during which a fact holds in the real world, while system time describes the point at which the fact was recorded, modified, or invalidated by the system. The two need not coincide — for example, the system may only record today that "the customer changed address last year," where the valid time is last year and the system time is today. A store that supports bi-temporal axes can answer "as-of queries": querying by valid time yields the factual truth at a historical point in time, while querying by system time reconstructs the beliefs the system held at that time. This differs from ordinary tables that retain only a single timestamp, where once overwritten, one cannot distinguish "the fact changed" from "we just learned it." OntoGr's "close old versions rather than overwrite" is exactly a typical implementation of bi-temporal axes and a common requirement in audit and compliance scenarios.

Entity resolution (entity alignment) refers to determining whether records from different sources refer to the same real-world entity and merging them into a unified node. Common techniques include exact matching, string similarity, blocking to narrow candidate pairs, and invoking models or human judgment in ambiguous cases. Resolution is a high-risk step in Agent memory: incorrect merges conflate the attributes, relations, and histories of two entities, and are often hard to detect. Therefore "reversible merging" means the system must retain the pre-merge nodes, edges, and alias mappings, support unmerge, and replay affected facts. This complements the cascading "cheapest evidence first" strategy — using low-cost rules to filter most candidates first, and only handing truly ambiguous pairs to expensive judgment, thereby balancing accuracy and cost.

Conflict Adjudication and an Auditable Ledger

When new and old facts conflict, OntoGr adjudicates with a three-tier mechanism: rules, an optional model judge, and final human decision, with human decisions taking highest priority. One detail worth noting: the post explicitly states that a failed model-judge call is never stored as "no conflict" — such failure states are treated separately, avoiding disguising system errors as conclusions.

On auditability, every fact can be traced to its quote and episode, and every temporal write enters a hash-chained ledger. It also includes built-in per-tenant authorization, audit logs, previewable and resumable forget/erase operations, and deterministic export.

Retrieval and Deployment: Four-Way Recall and Integration with Existing Stacks

The retrieval side uses four-way recall: vector, keyword, entity, and graph channels, merged via reciprocal rank fusion, ultimately outputting a context block constrained by a token budget, and reporting which channels failed — which is very practical for diagnosing retrieval quality issues.

For deployment, it runs on FalkorDB or Neo4j, with optional pgvector or Postgres; a background consolidation task handles deduplication, summarization, scoring, and archiving; the LLM and embedder are bring-your-own.

Reciprocal Rank Fusion (RRF) is a training-free method for merging results from multiple retrieval paths, with the formula of summing 1/(k + rank_i) for each document, where rank_i is its rank in the i-th result list and k is typically around 60. RRF depends only on ranks rather than the raw scores of each channel, so it can compare vector similarity, keyword BM25 scores, entity match scores, and graph traversal scores that have completely different scales, and is relatively robust to fluctuations in individual recall quality. The cost is that it discards score magnitude information and cannot explicitly model channel reliability. For Agent memory, RRF lets four types of evidence — "semantically similar," "literal match," "entity-associated," and "graph-reachable" — enter the candidate pool simultaneously, then be pruned by token budget, making it a common engineering choice that balances recall and implementation simplicity.

Open Questions: Time Model and Benchmarks

At the end of the post, the author openly solicits two types of feedback: first, whether the design of the time model is reasonable, and second, which benchmarks the community would most like to see first. For developers concerned about the trustworthiness of Agent memory, this is an early-stage open-source project worth joining the discussion on. The repository is at https://github.com/ontogr/ontogr-agent-memory.

One-line Summary

OntoGr establishes fact-level citation traceability, bi-temporal axes, and an auditable ledger for Agent memory.

Paragraph Summary

OntoGr is an open-source Python library that seeks to solve the trust problem in Agent memory systems: every fact must carry a verbatim quote from its source episode, so any conclusion can be traced back to the original text. It distinguishes valid time from system time to form bi-temporal axes, closing old versions rather than overwriting them to preserve historical beliefs; entity resolution uses a cheapest-evidence-first strategy with reversible merges, and per-tenant ontology lets humans approve model proposals. Conflict adjudication consists of three tiers — rules, an optional model judge, and human decision — and a failed judge call is never mistakenly stored as no conflict. On the retrieval side, four-way recall is fused via RRF and outputs a context block constrained by token budget. The system runs on FalkorDB/Neo4j or Postgres, and the author is soliciting feedback on the time model and benchmarks.