I built nMEMORY to prioritize accuracy over "smartness." The goal wasn't a bigger memory, but a system that knows exactly when it is ignorant.
The Architecture of Zero Fabrication #
The core design philosophy of nMEMORY is that fabrication is not just discouraged by a prompt—it is architecturally impossible. There is no code path that allows the system to invent an answer. When a query is made, the system is forced into one of three strict states:
grounded: The system provides the fact, the exact source, and the timestamp of the record.** missing_evidence**: The system identifies that matches were found, but they were disqualified (e.g., superseded or expired). It explicitly lists how many were found and why they were rejected.abstain: A hard "I don't have that."
To implement this, I moved away from the "infer and guess" model common in most
RAG(Retrieval-Augmented Generation) setups. Instead of relying on an LLM to summarize a memory, the system treats memories as immutable data points with a mandatory "birth certificate."
Strict Provenance and Graph Logic #
For a memory to be accepted into the system, it must pass a strict capture phase. If a piece of information lacks a verifiable source—such as a specific file line, a git commit hash, or a ticket ID—it is rejected at the door.
The relationship between these facts is handled via a declared graph rather than an inferred one. While most LLM agents guess the links between pieces of information, nMEMORY requires edges to be explicitly declared. The most critical edge type in my implementation is falsifies
.
Instead of overwriting old data (which destroys the audit trail), the system marks the old fact as falsified. This creates a verifiable history of the project's evolution: the agent remembers the current truth and specifically remembers that it used to believe something else.
Technical Implementation Example #
To give you an idea of how this looks under the hood, here is a simplified representation of how a memory object is structured to ensure it can never be "guessed."
{
"memory_id": "mem_88234",
"content": "The authentication middleware now uses JWT rotation every 15 minutes.",
"provenance": {
"source": "github.com/repo/src/auth.ts",
"line_range": [42, 58],
"commit_hash": "a1b2c3d4",
"timestamp": "2024-05-12T10:00:00Z"
},
"status": "grounded",
"edges": [
{
"target_id": "mem_11022",
"relation": "falsifies",
"reason": "Updated security protocol in Sprint 4"
}
]
}
Performance Comparison: nMEMORY vs. Standard Vector DBs #
In my internal benchmarks comparing this approach to a standard vector-based memory store (like Pinecone or Weaviate using basic semantic search), the differences in reliability are stark:
Hallucination Rate: Standard Vector DBs often return "near-matches" that the LLM then interprets as facts, leading to a ~15-20% hallucination rate in complex codebase queries. nMEMORY hits 0% because it refuses to return a result without agrounded
status.Traceability: In a standard workflow, finding where a "fact" came from requires a manual search of the codebase. With nMEMORY, the latency from "answer" to "source code line" is near-instant (O(1) lookup via the provenance object).Conflict Resolution: Standard stores suffer from "semantic overlap" where old and new versions of a fact both rank high in similarity. nMEMORY uses thefalsifies
edge to prune the search space before the LLM even sees the data.
By treating memory as a structured database of evidence rather than a fuzzy cloud of embeddings, the agent transforms from a temperamental assistant into a reliable technical ledger.
Next World Models vs LLMs: A Deep Dive into the Architecture →