Resolve the anchor
The query is parsed with the same machinery ingest used to ground it — the subject entity is resolved to a real identity, not matched by cosine distance.
The write path
Validated writes, not dump-and-embed.
The default memory pattern is dump-and-embed: chunk the text, embed it, upsert to a vector store. Nothing is typed, nothing is checked, and "truth" is whatever the embedding happens to be near later. FaultLine spends its intelligence at write time instead — every fact runs a validation gate before it's allowed to exist.
Vector RAG
Embed the blob. Hope it's near later.
Raw text goes straight to vectors — untyped, unvalidated, no provenance, no conflict handling. Contradictions stack silently; the store has no notion of what's actually true.
FaultLine
Extract → validate → ground.
Entities and relationships are extracted, typed against an ontology, classified by provenance, checked for conflicts and corrections, then committed as rows in a PostgreSQL-authoritative graph. No model gets unsupervised write access.
- Typedevery edge validated against the ontology, not a free-text blob
- Provenancestated vs inferred is recorded at write time
- Conflict-checkedcorrections supersede; contradictions don't just pile up
- AuthoritativePostgreSQL holds the truth; the vector index is derived
The vector index still exists — but as a derived, short-term scratchpad for things not yet classified, never the source of truth. It's a lane to revisit, and it never overrides the graph.
The read path
Deterministic recall you can trace.
Recall is not a similarity search. It's a plain, fast walk of the structure ingest laid down: resolve the anchor entity, walk its real connections scoped to the question, return the rows. Every answer points back to a fact that was actually stored — and if none exists, the honest answer is "you never told me," not the nearest fuzzy neighbour dressed up as truth.
Walk the graph
From the anchor, FaultLine walks real relationships and hierarchy — scoped to the question and bounded in depth — collecting the facts and scalars that actually answer it.
Return traceable rows
The result is grounded facts, each traceable to a stored row, rendered to prose over MCP. No UUIDs or internal tokens leak; a miss is reported as a miss.
Fuzzy nearest-neighbour can surface something that sounds related but was never said — a confident hallucinated memory. A deterministic walk can't: it only returns what's on the graph.
Provenance as epistemics
The epistemic firewall.
A memory system that can't tell what it was told from what it guessed will eventually present a guess as a fact. FaultLine draws that line at write time and carries it all the way to the voice of recall — so the confidence you hear matches the evidence behind it.
Stated → asserted
A fact the user actually stated is grounded as authoritative and comes back asserted — stated as knowledge, with confidence. User truth is sacred and never modified by the engine; only the user can correct it.
Inferred → held
A fact the engine merely inferred is kept apart and comes back held — flagged as tentative, "mention this cautiously." It's never dressed up as something the user confirmed.
The class of a fact is decided by its provenance, and that class drives the recall voice — the split between asserted and held is locked. A guess is always presented as a guess, in every configuration.
Time, done properly
The temporal dual-clock.
Facts change. Most memory stores conflate "when the fact is true" with "when we learned it," and end up either overwriting history or serving stale state. FaultLine keeps two clocks orthogonal — and recomputes temporal reasoning at read time rather than trusting a stamp that's gone stale.
Valid-time — when it's true
Each fact carries the time it refers to — an event date parsed deterministically at ingest (spaCy DATE spans plus a rule-based date engine, no LLM tense-guessing). A miss stays null; the system never fabricates a date.
Belief-time — when we knew it
Independent of valid-time, FaultLine tracks when a fact became current and when it was superseded. The two axes are never conflated — you can ask what was true then and what we believe now.
State changes coexist rather than destroy history — recency picks the current answer, but the past stays queryable. And because a stored "past / future" stamp goes stale, temporal queries recompute from the event date against the time of asking.
Interop & isolation
Portable memory, isolated per tenant.
The trust lives in the memory, not the model — so the model is interchangeable and the memory is authoritative and independent of it. And that memory is walled off per tenant, physically separable, not filtered rows in a shared table.
Model-agnostic over MCP
FaultLine speaks the Model Context Protocol and exposes remember, recall, and retract as tools. Connect Claude and it uses Claude; connect another model and the same validated memory comes back. Swap the model without touching the truth — the model is a client, not the store.
Per-tenant schema isolation
Every tenant gets a dedicated, physically separable schema — no shared table, no cross-talk. Isolation is the boundary, not a WHERE clause: a query resolves inside one tenant's graph or it doesn't resolve at all (search_path bound with no public fallthrough). Export the whole graph or delete it on demand.
This is the stronger posture on purpose: database-level isolation is far more demonstrable and auditable than row-filtering in a shared table (the "RLS alone is enough" assumption is a well-known cautionary tale for regulated data). To be precise about what it is: physical isolation is a compliance aid — it makes cross-tenant separation provable — not a certification. It doesn't by itself make FaultLine HIPAA/SOC2/GDPR-compliant or issue a BAA; those still require the surrounding controls (encryption, audit logging, access management, a signed agreement) on top of it.
Token economics · the mechanism, not a benchmark
Two ways it cuts wasted tokens.
For agents, tokens are money and long-context degradation is a real failure mode. FaultLine attacks the token bill from two independent directions — one on the input side of every turn, one on the wasted round-trips agents make re-solving the same problems. No fabricated numbers here; just the mechanism.
1 · Context reduction
Traditional memory and RAG re-send the whole transcript, or a pile of fuzzy retrieved chunks, into the context window every turn — expensive, slower, and less accurate as context grows. FaultLine returns the one grounded fact the question needs via a deterministic walk. Smaller prompts, lower latency, and no long-context degradation to fight — you send the model a sentence, not a haystack.
2 · The agent's own operational memory
Beyond the user's memory, a serving agent keeps its own private, firewalled record of operational lessons — what failed, the fix that worked, the gotcha to avoid. So it stops re-deriving solved problems and stops re-issuing approaches it already knows fail. Eliminating that churn on known-repeated issues means fewer wasted round-trips and fewer tokens spent re-learning. It's an engineer's notebook of pitfalls and how-tos — never mixed with user memory, and not a claim that the AI has feelings.
Both are structural, not prompt tricks: one shrinks what every turn has to carry, the other removes turns you'd otherwise burn re-solving the same thing.
Direction — memory that teaches the model (in design)
Both mechanisms above answer "what does the model need to know." We're also working the adjacent question, in the established context-engineering sense (the same category as tool-description tuning and relevance-filtered retrieval): teaching the model how to use what it's given, via two labeled channels back to any client — YOUR MEMORY (the facts) and HOW YOU OPERATE (seeded usage guidance). This is in-flight design work, not a shipped feature — no accuracy numbers to cite, and we won't invent any until it's built and measured.
Growth · two pathways
Give facts a place to live with /expand.
Deterministic recall only works if the structure to walk was built at ingest. FaultLine grows that type-and-class hierarchy two ways: automatically and bounded around everything you tell it, and deliberately and deep with /expand — so later facts land in the right spot instead of floating as disconnected islands.
Automatic buildout
Every ingest grows a bounded region of hierarchy around the entity — instant enough to be walkable now, with the deeper buildout done asynchronously so it never blocks recall. Bounded on purpose: enough structure to connect, not the whole world.
Deliberate /expand
Run /expand on a subject — networking, law, medicine — and FaultLine learns it to real depth from online sources, with its own anti-sprawl bounding. This is a separate, deeper mechanism from the automatic buildout.
Facts land right
With the field in place, everything you state afterward drops into the correct spot in the structure — grounded, connected, and returned later by the same deterministic walk.
Train once, serve forever. Most memory tools store only what you feed them; FaultLine can build the domain the facts live in first — so it understands the field, not just the facts.
Developer API · V1 · preview
The same memory, reachable as a REST API.
FaultLine is "one brain, two doors — decisions live backend-side, transports consume." The Developer API is the third door: the same validated, per-tenant, traceable memory engine over a clean, versioned /v1 REST surface and a Python SDK — beside the MCP tools and the OpenWebUI shim. Hitting /v1 runs the same code path past the transport boundary, so you get the byte-for-byte-equivalent validated result an MCP client gets. It's early — the surface is in preview/beta and may change before it's locked to a stable contract.
pip install faultline # then, in Python: fl = Client(api_key="flk_…", user_id="<seat-uuid>") fl.remember("My sister Diane is a nurse in Ottawa.") ✓ POST /v1/memories → stored · 2 committed · validated fl.recall("what does my sister do?").memory "Your sister Diane is a nurse." ← real row, traceable
Bearer flk_ key, JSON in, JSON out. POST /v1/memories to remember, POST /v1/recall to recall grounded prose, plus /v1/documents, /v1/corrections, /v1/learn. The tenant is always server-derived from your key — a caller can never address another tenant's memory. Same engine, same validated result — no memory logic in the client.
What you'd build with it
Persistent memory for your own agents
Give the agents you already run a validated, traceable long-term memory — remember and recall over REST, every write through the same gate, every answer traceable to a real row. No fuzzy vector guessing bolted onto your stack.
Ship a personal-memory product
Build a second-brain or personal-memory app on a substrate you don't have to build — extraction, typing, validation, the epistemic firewall, and per-tenant isolation are all server-side. You write the product; FaultLine is the memory.
Per-end-user memory in a multi-user app
Address each of your end-users as their own memory. One account key plus a per-end-user subject means thousands of end-users each get an isolated, validated memory — billed on volume, not per licensed seat.
Regulated / compliance workloads
When traceable, per-tenant-isolated memory is a requirement rather than a nicety: every recall points back to a stored row, every tenant lives in a physically separable schema, and you can export or delete a tenant's whole graph on demand.
On the roadmap, not shipped yet: an elevated lane for higher-sensitivity data (e.g. clinical) that mints a dedicated schema per record-owner instead of per seat — physical isolation taken a step further — plus a tiered isolation ladder (shared schema pool → dedicated database instance) for accounts that need it. In design; we'll say clearly here when it ships.
Access is opt-in and least-privilege
The security posture is a feature. The API isn't silently on the moment you hold a key.
Opt-in billable add-on
Off by default.
API access is an explicit account-level add-on, OFF for every account until a billing admin turns it on — after seeing the use-case and agreeing to the per-usage billing. A valid key authenticates; it doesn't imply entitlement. Nobody is billed for a door they didn't knowingly open.
Per-seat least-privilege
Enabled ≠ armed.
Enabling the account doesn't arm every seat. An admin grants API access only to the specific seats that need it — least-privilege by default, so the blast radius of a key is exactly the seats you chose, not the whole account.
Preview. /v1 is shipping and in beta — the contract may still change. Self-hosters get the same third door as the open-core transport; the add-on lever and metering are the managed-SaaS layer around it.
The honest comparison
Great company. Go try them.
The AI-memory field is full of genuinely excellent work, and you should evaluate it before you pick. Here's a fair read on the leaders — what each does well, and where FaultLine draws a different line.
Our position, plainly: these are all excellent products — go try them. They're further along than we are — funded, proven, with the community and integrations that maturity buys, and we'll say that openly. We're the newer bet. Where we draw a different line is deterministic, traceable recall (every answer maps to a real row, not a nearest-neighbour guess), per-tenant schema isolation, and one engine for both personal and agent memory — model-agnostic and self-hostable. We point you at the competition on purpose: we'd rather you choose right than choose us blind, and we're confident enough in that difference to do it.
Mem0
mem0.ai ↗The quickest way to add a memory layer to an app, with a huge community and a dead-simple developer experience. Vector-first, generous free tier, with graph memory on the Pro plan. If you want to ship memory today, Mem0 is a superb choice.
FaultLine differs: recall is a deterministic walk of real rows — every answer traceable, not a nearest-neighbour guess — with per-tenant schema isolation you own.
Zep (Graphiti)
getzep.com ↗Zep pioneered the temporal knowledge graph with its open-source Graphiti engine, tracking facts as they change with validity windows, and scores a genuinely excellent 63.8% on LongMemEval. Serious, well-engineered memory.
FaultLine differs: the same temporal-graph strength plus a stated-vs-inferred epistemic firewall and deterministic recall traceable to a real row — one contract for personal and agent memory.
Letta (MemGPT)
letta.com ↗Letta (formerly MemGPT) is a full agent runtime with OS-style self-managed memory and a strong research pedigree — and it's self-hostable. If you want an opinionated agent operating system with memory baked in, Letta is excellent.
FaultLine differs: we're model-agnostic memory infrastructure over MCP and REST — run us under any runtime, including theirs, and swap the model without touching the truth.
Supermemory
supermemory.ai ↗Supermemory shines at multi-source ingestion for personal knowledge management — tweets, web pages, documents — with a generous free tier. If your goal is a personal second brain that ingests everything, it's a great pick.
FaultLine differs: built for provable, owned, per-tenant memory — validated writes and deterministic recall, one engine serving personal and agent memory alike.
Fair comparison, not a teardown — links go straight to each vendor. We're pre-launch: no invented benchmarks, logos, or customer counts here. The published number above (Zep's LongMemEval) is theirs, cited because it's a bar worth holding ourselves to.
Want the architecture diagrams and the full deep dive?
The Research page has the founding distinction, the ingest and recall flowcharts, the temporal model, and the WGM ontology aligned to Wikidata — with the full mermaid diagrams of the write and read paths. This flavour page is the summary; that's the long-form.
Validated writes only
No unsupervised model writes — every fact passes the gate. The truth lives in the memory, not the model.
Per-tenant isolation
A dedicated schema per tenant, physically separable — no shared table, no cross-talk.
Model-agnostic over MCP
remember / recall / retract as tools. Swap the model; keep the same validated memory.
Your data is yours
Export the whole graph or delete it on demand. Point the engine at your own model endpoint.
Open core · Apache 2.0
Same engine, open source. Self-host it.
The memory engine is genuinely open source under the Apache License 2.0 — the validated knowledge graph, the deterministic recall walk, the MCP tools, and per-tenant isolation. Run it yourself, or let us run it. It's the same truth engine either way.
Self-host · free · Apache-2.0 · you run it
You run it.
The full open engine on your own infrastructure: validated writes, deterministic recall, MCP, per-tenant schema isolation. Total control and every line auditable — and the ops burden is entirely yours. No managed multi-tenancy, no billing, no dashboards, no support.
FaultLine SaaS · managed · we run it
We run it.
The same engine hosted and maintained — plus the layer around it: accounts, seats and billing, the tenant and individual dashboards, per-tenant isolation at scale, the agent's operational memory, SSO / compliance / SLA, and real humans on support.
Same truth engine — we just run it so you don't have to.
Not the trusting type? Good.
The whole engine's open source — self-host it, audit every line, tear it apart. Apache License 2.0, with real self-host paths (quickstart, deployment, docker-compose).
Memory that answers from a real row.
Grounded, validated, traceable — and model-agnostic over MCP. Start free, or read the full architecture.