The Continuity Layer · The primer

Memory Is Not Continuity

A short, structural explanation of what continuity is, how it differs from what most current systems are built to do, and what this site asks when it evaluates a claim.

Start Here routeStep 1 of 4Next: Build a local layer

If Why AI forgets is the plain-language version, the primer is the field guide. It turns the same idea into a structural model: what must persist, what must be governed, what must be provable, and what must be able to be let go. The full argument is the thesis; the test is the framework.

Six words that are not the same

The field uses these interchangeably. Each row is a different thing, and each label says whose vocabulary it is.

01
Context: What the model can see this call: the prompt, the retrieved passages, the tool results in the window. It does not survive the call. A bigger window holds more; it does not carry anything forward. Established
02
Memory: What is stored for later recall, in text, in a graph, in an index, or in a model's weights. Storage says where facts live, not which are still true, who may change them, or why they changed. Established
03
Knowledge: What the system currently takes to be true: facts with a validity and a source, as distinct from the records they came from. A memory is a record of what was said; knowledge is the maintained answer to what holds. Two memories can disagree; knowledge has to decide. Our proposal
04
State: What the system is committed to right now: tasks in flight, permissions granted, obligations made, effects it has had on the world. State is wider than facts. A task ledger, a credential and a promise are state; none of them is a memory of a conversation. Emerging convention
05
Identity: Who the agent is across runtimes: the versioned contract that says which facts, commitments and roles are its own, and who may change them. Identity is not the model. If replacing the model makes a new agent, the identity lived in the weights and was never carried. Emerging convention
06
Continuity: All of the above carried forward under governance: current, sourced, time-bounded, portable, and able to forget. Not a feature of a memory product. A layer above memory and below execution, judged by the five obligations. Our proposal

Long context extends what one session can hold. It doesn't survive the session ending, and it degrades as it fills.

RAG retrieves chunks that resemble the question. It doesn't know which of those chunks are still true, and it serves the stale one up to 40% of the time when a fact has changed.

Vector databases search by similarity. They don't reconstruct which version of a fact is current, and a soft-deleted vector stays on disk.

Knowledge graphs store relationships between entities. The temporal ones close an old edge when a new fact arrives; most don't record who may write or why.

Memory APIs extract profile-shaped facts about a user and add, update or delete them. They rarely keep the source, a reason for a change, or the shape of an in-flight task.

Background memory builds memory from your history while you sleep. Convenient, and the route by which deleted facts get written back.

Fine-tuning puts what the system remembers into its weights. The hardest memory to source, audit or erase.

Continuity what the others don't do alone: carry state across sessions, tools, models and hosts; govern who may write it; evolve it with reasons; prove where it came from; and forget it, verifiably.

The five obligations, in brief

What a continuity layer owes the people and systems that depend on it. The full framework, with fifteen questions and the erasure ladder, is on its own page.

Carry

State outlives the session, the tool, the model and the host that created it.

Govern

Every write names its source and its authority; untrusted input does not become trusted memory.

Evolve

A changed fact is superseded with a reason, never silently edited; the record can say what was true when.

Prove

Every carried fact can show where it came from; every change can show who made it, when, and why.

Forget

Anything carried can be corrected, revoked, expired, deleted and verified gone, including what was derived from it.

History: the first version of this site evaluated a claim against seven continuity properties: persistence beyond a session, update handling, temporal ordering, disambiguation, reconstruction, model independence, operational usefulness. They fold into carry and evolve; the three things they never asked about, authority on writes, portability of identity, and forgetting, became obligations of their own in version 2.0.

How to read this section

The primer is the model. The other pages test it, source it, or map the field around it.

The model

Why this matters now

Most systems people call “memory” today are strong in-session and weak across time. Agents lose state between steps, between sessions, between tool calls, and at every handoff to a different surface or model. RAG helps a system find something that resembles the answer; it doesn’t help it know what’s still true. Long context helps a session last longer; it doesn’t make what happened in that session durable afterward.

And memory that persists brings two problems memory that didn’t never had. What persists can be poisoned: a stored entry that lost where it came from is later recalled as trusted knowledge. And what persists has to be able to be forgotten: deleting a record leaves the summaries built from it, the vector in the index and the copies in other stores, and the research of 2026 shows deleted facts returning within a few sessions. The field responding to this is fragmenting; this site maps it as it exists, before the language collapses into vendor claims.

What we ask of a claim

01
What actually persists: facts, embeddings, transcripts, task state, identity, something else?
02
Where does it live: local, hosted, portable, locked to one vendor?
03
Who owns it: the user, the app, the model provider, the runtime?
04
Who may write to it, and does every write keep its source and its authority?
05
What happens when a stored fact goes stale: is it superseded with a reason, or does it just sit there, or get silently overwritten?
06
Can the system say what was true at a given time, not only what is true now?
07
Can it tell two similar facts apart, and can it say “I cannot tell” when two conflict?
08
Does it work across models, or is it tied to one?
09
Can you take it out in a form another system reads?
10
When you delete something, how far does the deletion reach: the record, the summaries built from it, the index, the backups, the model?
11
Is there public evidence for the claim: a paper, a repository, a reproducible evaluation, or a vendor assertion?

Open questions

Kept on their own page now, with the sources that show each is open and what progress would look like.

Nine, as of November 2026: no benchmark scores governance, no shared format carries memory between vendors, deletion has no receipt, erasure is bounded by provenance, identity is not carried, conflicts have no rule, consolidation resurrects what was deleted, the law names outcomes without methods, and the words still mean different things. Open problems →

Keep going

Test the model, then inspect the receipts.

After the structural model: the framework that turns it into questions, the ladder that says what forgetting means, the library that sources every claim, and the practice that turns it into plain files.

The five obligations →The erasure ladder →The research library →Build a local layer →

Reference pages: continuity layer definition, memory vs continuity, bi-temporal memory, and the continuity glossary.