Memory you can trace.

One engine, any subject

FaultLine has no idea whether the domain is networking, law, biology, or mental health. The domain is just data grown into the hierarchy — never hardcoded.

Because the engine is subject-agnostic, the same machinery that grounds "my family" grounds a network topology, a legal precedent chain, or a species' lineage. A domain is bootstrapped and then grown as data; there is no per-subject code path. The examples below are illustrations, not separate features.

And you don't only get to store the facts you personally supply. With /expand (also called /learn), you can teach FaultLine a whole subject — have it learn a field to real depth from online sources and grow the knowledge hierarchy for you, so that everything you later tell it lands in the right place and is walkable. Bootstrap the field once; then it serves. More on the two growth pathways in the build story.

What "the walk returns" actually looks like

A concrete example. You told FaultLine about your household over several conversations; later you ask a scoped question. FaultLine grounds the anchor, walks the graph, and hands back grounded rows — no fuzzy matching, and no fabrication for what you never said.

recall "tell me about my family"
  Your mother is Diane, age 62.        ← real rows
  Your household includes a dog, Spot.  ← nested grouping

recall "who is Spot's vet?"
  You haven't told me that — I won't guess.

The domain here was grown from what you said. Swap in networking, law, or biology and the mechanics are identical — the engine never learned "family" or "networking" as special cases.

The agent gets its own memory

Beyond the user's memory, a serving agent can keep its own private, operational memory — the agent's lessons, not the user's life. What worked, what failed, the gotchas it hit, how to do the thing next time: the agent saves those as it goes and recalls them when a similar situation comes up. It's the difference between an agent that re-learns the same mistake every session and one that actually gets better at its job.

To be precise about what this is not: it is operational memory — an engineer's notebook of pitfalls and how-tos — not "the AI has feelings." And it is completely walled off from the user's memory. The two live in strictly separate stores and never mix: an agent's operational note can never surface in a user's recall, and a user's facts never leak into the agent's notebook. Same validation discipline, same grounding — a hard firewall between them.

Reach it as a REST API (V1 — preview)

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 over a clean, versioned /v1 REST surface and a Python SDK (pip install faultline), beside the MCP tools and the OpenWebUI shim. It's a facade — every /v1 endpoint authenticates, resolves the tenant with the existing seams, and calls the same tool an MCP client would, so a developer gets the byte-for-byte-equivalent validated result. No memory logic is re-implemented at the transport.

You authenticate with a Bearer flk_ key; POST /v1/memories remembers, POST /v1/recall returns grounded prose, with /v1/documents, /v1/corrections, and /v1/learn alongside. The tenant is always server-derived from the key — a caller can never address another tenant's memory. This surface is in preview/beta; the contract may still change before it's locked.

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. With SaaS off, /v1 behaves byte-for-byte like the open engine.

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. 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 maturity buys, and we'll say so openly; we're the newer bet. Where we draw a different line is deterministic, traceable recall (every answer traces to a real row, not a fuzzy vector match), per-tenant schema isolation, being model-agnostic and self-hostable open-core, and one engine for both personal and agent memory. We point you at the competition on purpose — we'd rather you choose right than choose us blind. Fair comparison, not a teardown — the links go straight to each vendor, and we're pre-launch, so there are no invented benchmarks or customer counts here.

The build story — strong ingest, lean query

The care is in the pipeline. Ingest carries all the weight so that recall can be a dumb, honest walk.

The guiding principle is a division of labour: all the intelligence is spent at ingest; the query is a lean, deterministic walk of what ingest laid down. If recall is ever wrong, the fix belongs at ingest — never a cleanup bolted onto the read path. That discipline is what keeps answers traceable.

Two ways the knowledge grows

The hierarchy — the "place" a memory gets filed at — is grown, not hardcoded, and it grows through two distinct, honest pathways. They're independent: you always get the first, whether or not you use the second.

Both are subject-agnostic and grown per-tenant: your world is yours. The seed the engine starts from is a read-only template — you grow from it, never into it, so one tenant's growth can never touch another's.

Deterministic extraction — the spine deriver

Pulling structured facts out of loose human sentences is where most systems either hardcode patterns or hand everything to an LLM and hope. FaultLine's approach splits the roles cleanly: the LLM does segmentation only — it breaks a rambling message into single-fact sentences — and a deterministic spaCy-dependency engine does all the structured extraction. The LLM detects and segments; the deterministic engine structures. No LLM tense-guessing, no LLM inventing triples.

Temporal determination — never fabricate a date

Time is parsed deterministically at ingest, and the rule is strict: the system never invents a date. spaCy's DATE recognizer proposes candidate spans; a rule engine (dateparser) normalizes and validates them; the first valid date wins. A phrase that isn't really a date resolves to nothing — a miss becomes an empty field, never today's wall-clock stamped in as if it were fact.

FaultLine also keeps two clocks apart: when a fact refers to (its valid time — the appointment is next Tuesday) is independent of when we came to believe it (transaction time). Because a stored "future/past" label goes stale as the calendar moves, time reasoning at query time recomputes from the actual date rather than trusting the old label.

The epistemic firewall — confidence as voice

Every fact carries where it came from, and that provenance decides how it's stored and how it's spoken. A fact you stated is durable and asserted as knowledge. A fact the system inferred is held more tentatively and can be promoted only as evidence accumulates. On recall, that difference becomes tone: confident facts are stated plainly; uncertain ones are flagged as tentative. The class-to-confidence mapping is locked — a "maybe" is always voiced as a maybe.

Per-tenant isolation

Every tenant's memory lives in its own isolated schema, and queries are bound to that schema with no shared fallback path — one tenant's world cannot bleed into another's. The seed ontology is a read-only template you grow from, never into: your growth is yours alone.

Worth being precise about what this buys you: neither HIPAA, SOC2, nor GDPR mandates one specific isolation architecture — they're outcome-based, risk-proportionate rules. But database-level isolation (a real schema boundary, not a WHERE tenant_id = ? filter or a row-level-security policy over a shared table) is far more demonstrable and auditable — exactly the property a compliance review is trying to verify, and the well-known failure mode of "RLS alone" shared-pool designs. It's a compliance aid, not a certification: it doesn't replace a BAA, encryption at rest/in transit, audit logging, or access controls, and we don't claim it does. A tiered isolation ladder for accounts that need it — shared schema pool up through a dedicated database instance — is on the roadmap, not shipped today.

The pursuit of repeatable determinism

This part was hard-won, and it's worth being honest about. Getting an LLM-in-the-loop pipeline to produce the same grounded result run after run took real work — chasing down sources of flicker that turned out to be caching races and environment state, not the model, and rebuilding the growth decisions to be deterministic (convergence by identity, frequency-gated approval) instead of leaning on similarity scores. The payoff is a system whose answers you can reproduce and trust, because the same input lays down the same rows every time.

Foundations — the ontology underneath

FaultLine's graph isn't ad-hoc. It's a triple model aligned to established, open standards.

The WGM ontology — triples aligned to Wikidata

Every fact is a triple: subject → relationship → object. The relationship types are aligned to Wikidata property identifiers where one exists, and to SKOS/OWL semantics where those apply — so the graph speaks a vocabulary the wider knowledge-graph world already shares, rather than a private dialect. Relationships are self-describing: whether one is symmetric, what its inverse is, what types it can connect, and where its value is stored all come from metadata, not hardcoded rules. New relationship types can be grown without touching code.

An illustrative slice — the live ontology is broader and grows per-tenant. Type constraints and inverses are all metadata-driven.

The hierarchy as a universal index

The type-and-class hierarchy — the "place" from the founding distinction — is the founding layer, built at ingest. Almost everything is hierarchable: not just objects, but feelings, concepts, time, even IP addresses. That's what makes it universal rather than a per-subject feature. It is the deterministic scaffolding that keeps recall anchored to what's actually true, instead of to what a model half-remembers deep in a long context.

Crucially, the hierarchy classifies types (common nouns: dog, canine, mammal), never names (Spot, Apollo). A named instance is an instance of its type; the subclass ladder hangs off the type, never off the name. Keeping names out of the index is the same hard line that makes the whole thing safe.

The ladder — from memory to knowledge

The layers form a ladder. At the bottom is the raw, grounded memory — what you said. Above it, the engine builds just enough structure to make that memory walkable: its type, its place in the hierarchy, its relationships, its time. The two axes — the specific instance and the general type — meet at the entity. The engine builds the structure; it never rewrites the memory.