Introducing CLAIV Memory V5

Today we are shipping CLAIV Memory V5, the most significant architecture change since our first public release. V5 replaces the single-pass extraction pipeline with a two-phase LLM curation system, introduces tiered memory storage, and adds evidence-backed facts with character-exact source quotes. Every decision in V5 was driven by one principle: deterministic over probabilistic, structured facts over raw chunks, explainable over black-box.

Two-Phase LLM Curation

Earlier versions of CLAIV ran a single LLM pass over each conversation turn, extracting facts in one shot. This worked for simple exchanges but struggled with nuance. A user might say “I used to live in Berlin but moved to London last year” and the old pipeline would store both cities as current residences.

V5 splits extraction into two distinct phases. Phase one: Extract. The LLM reads the raw conversation and produces candidate facts as subject-relation-object triples. Each triple carries the exact character offsets from the source text so every fact is traceable back to the words that produced it. Phase two: Curate. A second LLM pass reviews the candidate facts against the existing memory graph. It resolves contradictions, merges duplicates, and marks superseded facts with temporal metadata. The result is a clean, deduplicated set of facts where every change is tracked.

Tiered Memory Architecture

Not all facts are equally important. A user’s name matters more than the color of shirt they mentioned wearing last Tuesday. V5 introduces three memory tiers:

• Hot memory — Core identity facts, active preferences, and recent context. Always included in recall responses. Kept in fast storage for sub-50ms retrieval.
• Warm memory — Historical facts, past preferences, and contextual details. Included when token budget allows and relevance score is high enough.
• Cold memory — Archived facts that have been superseded or are rarely accessed. Retained for audit trails and temporal queries but excluded from default recall.

The tier assignment happens automatically during the curation phase. Developers can override tiers via the API, but the defaults are designed to work without manual intervention.

Evidence-Backed Facts

Every fact in V5 carries an evidence span: the exact substring from the original conversation that produced it, along with character-level start and end offsets. When your application surfaces a fact to an end user, you can show them exactly where it came from. This is not just a debugging convenience—it is a compliance requirement for many regulated industries.

Evidence spans also power CLAIV’s conflict resolution. When two facts contradict each other, the system can present both facts alongside their source quotes, letting downstream applications or human reviewers decide which to trust.

Temporal Change Tracking

V5 treats facts as evolving entities rather than static records. When a user’s preference changes—say they switch from preferring email to preferring Slack—the old fact is not deleted. It is marked as superseded with a timestamp and a reference to the new fact. This creates a full temporal graph: you can query what was true at any point in time, not just what is true now.

Synthesized Recall Answers

Previous versions returned raw fact lists from the Recall endpoint. V5 adds an optional synthesis step: the system takes the retrieved facts, the original query, and a token budget, then generates a coherent natural-language summary. This means your chat application can inject a pre-written context paragraph into the system prompt instead of formatting raw triples yourself.

GDPR Forget with Audit Receipts

The Forget endpoint in V5 returns a cryptographic audit receipt for every deletion. The receipt includes a hash of the deleted data, the timestamp of deletion, and the scope of the operation (single fact, user, or session). Receipts are stored immutably and can be retrieved later to prove compliance. No more manual audit logs.

Using V5 in Practice

The API surface remains three calls: Ingest, Recall, and Forget. Here is what a typical integration looks like with V5:

// Ingest a conversation turn
const ingestResult = await claiv.ingest({
  userId: "user_abc",
  sessionId: "sess_123",
  messages: [
    { role: "user", content: "I just moved to London from Berlin" },
    { role: "assistant", content: "Welcome to London!" }
  ]
});
// ingestResult.facts → [
//   { subject: "user", relation: "lives_in", object: "London",
//     evidence: { text: "I just moved to London", start: 0, end: 24 },
//     supersedes: "fact_old_berlin" }
// ]

// Recall relevant context for a new conversation
const context = await claiv.recall({
  userId: "user_abc",
  query: "Where does the user live?",
  tokenBudget: 500
});
// context.synthesis → "The user currently lives in London,
//   having moved from Berlin."
// context.facts → [{ subject: "user", relation: "lives_in",
//   object: "London", tier: "hot", ... }]

Design Philosophy

V5 is opinionated. We chose structured facts over raw text chunks because structured data is queryable, mergeable, and auditable. We chose two-phase curation over single-pass extraction because accuracy matters more than speed when you are building a user’s long-term memory. We chose explainability over black-box retrieval because developers need to debug and users need to trust.

These are not the only valid choices. RAG pipelines, vector stores, and embedding-based retrieval all have their place. But if you are building a chat application that needs to remember users across sessions, handle contradictions gracefully, and comply with data regulations, V5 is built for exactly that problem.

V5 is available now on all plans. Existing integrations continue to work—the API is backward compatible. New features like synthesized recall and audit receipts are opt-in. Check the quickstart guide to get started, or try it in the playground.