What a continuity layer owes the people and systems that depend on it, and how to tell whether a system meets it. Version 2.0, 7 November 2026. Our proposal, labeled as such; the established vocabulary it rests on is credited where it is used.
Checked 7 November 2026. Sources linked. Our own framing is labeled as ours.
OriginalContinuity Framework v2.0 · 7 November 2026 · supersedes the Continuity Taxonomy v1.0
A continuity layer is the part of an AI system that carries forward governed state across sessions, tools, models, and hosts: what is currently true, what changed, why it changed, by whose authority, and which evidence supports it. It sits above memory and retrieval, and below agent execution, turning stored history into usable, auditable continuity; and it can correct, supersede, revoke, expire, and forget what it carries, with evidence that it did.
Established
Accepted research or standards vocabulary, with a primary source.
Emerging convention
A convention forming across the field in 2025–2026; not yet a standard.
Our proposal
This site's own framing. Citable as such; not an industry standard.
Hypothesis
Ours, and still to be validated by research or practice.
The five obligations
Our proposal A continuity layer is judged by what it owes, not by what it stores.
01 · Carry
State outlives the session, the tool, the model and the host that created it.
Carrying is more than remembering. What has to survive is the current shape of the work: what is true, what is decided, what is in flight, what has been promised, and who the agent is. A continuity layer carries that forward in a form another model, tool or host can pick up without re-explanation, and in a form the owner can take with them. Identity is part of what is carried: if swapping the model creates a new agent, nothing was carried at all.
Without it: The project restarts from zero on Monday, or when the model changes.
C1 Does state outlive the session that created it?
Good answer: Facts, decisions and in-flight work are still there next week, not only in scrollback.
C2 Does the same state work when the model, tool or host changes?
Good answer: Swapping the model is a migration, not a new agent; the record, not the model, holds the identity.
C3 Can the owner take the state out in a form another system can read?
Good answer: An export in an open format, or the data sits in a store the owner controls.
v1.0 properties folded in: Persistence beyond a session; Reconstruction; Model independence.
02 · Govern
Every write names its source and its authority; untrusted input does not become trusted memory.
Memory that anything can write to is memory that anyone can poison. Governance is the contract on the write path: who may add, change or share each item, at what scope, and with what source attached. The 2026 security literature finds the root of memory poisoning at exactly this point: stored entries lose track of where they came from, so content from a tool result or a web page is later recalled as something the owner said. A governed layer keeps the boundary between what was observed and what is trusted, and it keeps the boundary between one user's memory and another's.
Without it: A web page an agent read in June is quietly running its decisions in November.
G1 Does every write pass through a contract that records its source and the authority behind it?
Good answer: No item enters the record without a source, a scope and a named writer.
G2 Is memory scoped: who may read, write and share each item?
Good answer: Per-user, per-agent and per-session scopes, and a rule for sharing between them.
G3 Is untrusted content kept from becoming trusted memory?
Good answer: Tool results and retrieved pages are stored as observations with their origin, not as the owner's own facts; writes are validated or quarantined.
Where the field's terms land
authority and mutability (Always-On Agents, 2026)
write-path provenance, write policies, post-write monitoring (Dash et al., 2026)
memory and context poisoning, ASI06 (OWASP Top 10 for Agentic Applications, 2026)
access control and scoping (GateMem, 2026; SSGM, 2026)
A changed fact is superseded with a reason, never silently edited; the record can say what was true when.
Knowledge changes. The record has to change with it without losing its history: the old value is closed with a reason and points to what replaced it, and every fact carries the time it was true and the time it was recorded. Two clocks, not one, are what let a system answer both questions honestly: what is true now, and what did we believe then. Evolution also needs a rule for conflict: when two records disagree, something decides which is current, and the system is allowed to abstain when it cannot tell.
Without it: The assistant confidently answers with a fact that stopped being true in March.
E1 When a fact changes, is the old one superseded with a reason, or silently overwritten?
Good answer: The prior value stays readable, closed with a dated reason and a pointer to its replacement.
E2 Can it say what was true at a given time, not only what is true now?
Good answer: Each fact carries valid time and record time; history can be replayed.
E3 When two records conflict, is there a rule for which wins, and can the system abstain?
Good answer: A stated resolution rule (time, authority, source quality), and an honest “I cannot tell” when it fails.
Where the field's terms land
bi-temporal data (SQL:2011; Snodgrass)
temporal knowledge graphs; valid-from and invalid-at edges (Zep, 2025; Graphiti)
temporal validity and stale-fact retirement (MemStrata, 2026)
knowledge updates and abstention (LongMemEval, 2024)
Every carried fact can show where it came from; every change can show who made it, when, and why.
Provenance is the hinge of the whole framework. It is what makes a record auditable, and it is what makes a record erasable: a system can only remove what it can trace, including the summaries, plans and indexes that were built from it. The 2026 work on agent accountability converges here: process-level traces instead of answer-only grading, signed receipts for memory operations, and replayable evidence of what an agent did and on what basis. Regulation is moving the same way, with record-keeping duties for high-risk systems written into the EU AI Act.
Without it: Nobody can say why the agent believes what it believes, or who changed it.
P1 Can every carried fact show where it came from?
Good answer: A source on each item: the message, document, tool result or person it came from.
P2 Can every change show who made it, when, and why?
Good answer: A dated, attributed reason on every supersession, revocation and deletion.
P3 Can a third party audit or replay the record?
Good answer: Receipts, logs or signatures that someone outside the system can check.
Where the field's terms land
W3C PROV data model (2013); PROV-AGENT (2025)
evidence tracing and execution provenance (Wang et al., 2026)
signed receipts and public audit logs (SAIHM draft, 2026)
record-keeping for high-risk AI (EU AI Act, Article 12)
Anything carried can be corrected, revoked, expired, deleted and verified gone, including what was derived from it.
A system that remembers everything forever is not a good continuity system; it is a liability with a search box. Forgetting is a family of distinct operations, from correcting a wrong record to proving that a deleted one no longer shapes behavior, and the 2026 research shows how far apart they are. Deleting a stored memory leaves its influence in summaries, plans and caches; soft-deleting a vector leaves it reconstructible on disk; and even a dependency-aware deletion is undone within a few sessions by checkpoint restores, copies in artifacts and peer agents, and consolidation that writes the fact back. The erasure ladder below names each rung so a product's “delete” claim can be read for what it actually guarantees.
Without it: The user deletes a memory and the agent keeps acting on it, because the summary still holds it.
F1 Can an item be corrected, revoked, expired and deleted, each as a distinct operation?
Good answer: Four different operations with four different guarantees, not one “delete” button.
F2 Does deletion reach derived memories, summaries, indexes and copies?
Good answer: Provenance links from the item to everything built from it, and a repair that withdraws or rebuilds them.
F3 Can the system show that something is gone and no longer shapes behavior?
Good answer: A receipt for the deletion, and audits over later sessions that the fact neither returns nor steers decisions.
Where the field's terms land
forget and rollback phases (MemTensor survey, 2026; Always-On Agents, 2026)
execution-state unlearning (Yao et al., 2026); cascade repair (MemoRepair, 2026)
residue and resurrection (Lu, NeurIPS 2026 workshop)
cryptographic erase (NIST SP 800-88 Rev. 2); right to erasure (GDPR Article 17)
Ask these of any memory system, agent framework or assistant. A “yes” needs a source: a docs page, a spec, a test. The graded shelves on this site answer the subset that can be read from makers' own pages; the rest need the system in hand.
C1Does state outlive the session that created it? (Carry)
C2Does the same state work when the model, tool or host changes? (Carry)
C3Can the owner take the state out in a form another system can read? (Carry)
G1Does every write pass through a contract that records its source and the authority behind it? (Govern)
G2Is memory scoped: who may read, write and share each item? (Govern)
G3Is untrusted content kept from becoming trusted memory? (Govern)
E1When a fact changes, is the old one superseded with a reason, or silently overwritten? (Evolve)
E2Can it say what was true at a given time, not only what is true now? (Evolve)
E3When two records conflict, is there a rule for which wins, and can the system abstain? (Evolve)
P1Can every carried fact show where it came from? (Prove)
P2Can every change show who made it, when, and why? (Prove)
P3Can a third party audit or replay the record? (Prove)
F1Can an item be corrected, revoked, expired and deleted, each as a distinct operation? (Forget)
F2Does deletion reach derived memories, summaries, indexes and copies? (Forget)
F3Can the system show that something is gone and no longer shapes behavior? (Forget)
The lifecycle of one carried fact
Our proposal Drawn from the published lifecycles, which follow the system; this one follows a single fact.
01 · Observed
Something is said, read or returned by a tool. It is not yet memory.
02 · Admitted
A governed write admits it with a source, a scope and a writer; or refuses it.
03 · Current
It is part of the current state every model and tool is handed.
04 · Superseded or expired
A later fact closes it with a reason, or its retention clock runs out. It stays readable as history.
05 · Forgotten
It is deleted, with everything derived from it, and a receipt says so.
06 · Verified gone
Later sessions show it neither returns nor steers behavior.
Audit is not a stage; it runs across every arrow. That is why prove is an obligation and not a phase: the lineage written at admission is what makes supersession explainable, what makes the forget step reach derived memories, and what makes “verified gone” possible at all.
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
Crosswalk: where the published frameworks land
This framework was not written in a vacuum, and it is not the only one. The table says how the terms of the published surveys, benchmarks and standards map onto the five obligations, so a reader coming from any of them can find their footing, and so nothing here is mistaken for the consensus.
Six diagnostic axes (authority, scope, mutability, provenance, recoverability, actionability) and a lifecycle from write to rollback. Authority and scope land in govern; mutability in evolve; provenance in prove; recoverability in forget; actionability in carry.
Six phases (write, store, retrieve, execute, share and propagate, forget and rollback) and four objectives (integrity, confidentiality, availability, governance). The forget-and-rollback phase is the forget obligation; integrity and confidentiality are govern.
Forms, functions and dynamics of memory. This framework starts where that taxonomy stops: it classifies what memory is; the obligations say what has to be true of it.
Continuity properties such as persistence, update handling and disambiguation, scored directly. The closest published cousin of the v1.0 seven properties; both fold into carry and evolve here.
Provenance, bi-temporal data and cryptographic erase are decades-old vocabulary. Prove, evolve and rung 8 of the erasure ladder use the established terms rather than new ones.
What changed from v1.0
Version 1.0 (July 2026) was a taxonomy: eight axes for reading the field and seven properties for evaluating a claim. The axes mixed what a system holds (memory, context, state, provenance) with who acts and where (agents, workflows, evaluation, infrastructure), which made them a good map of the field and a poor test of a system. They retire as a framework element and survive as the categories of the landscape. The seven properties were the real core; they fold into the obligations as shown above, and three things the properties never asked about, authority on writes, portability of identity, and forgetting, become obligations in their own right.
The v1.0 definition, axes and properties, verbatim
A continuity layer is the part of an AI system that carries forward governed state across sessions, tools, and models: what is currently true, what changed, why it changed, and which evidence supports it. It sits above memory and retrieval, and below agent execution, turning stored history into usable, auditable continuity.
Eight axes
Memory: What is stored.
Context: What is available right now, in this call.
State: What persists — the current shape of a project or task.
Provenance: Where each piece of truth came from.
Agents: Who acts, and under what authority.
Workflows: How continuity survives a handoff — session to session, tool to tool, agent to agent.
Evaluation: How any of this is measured, and against what standard.
Infrastructure: Where the layer actually lives — protocol, runtime, product, or process.
Seven properties
Persistence beyond a session: Does state outlive the conversation that created it?
Update handling: When a fact changes, is the old value superseded with a reason, or silently overwritten?
Temporal ordering: Can the system say what was true at a given time, not just what's true now?
Disambiguation: Can it tell apart two similar-looking facts or entities instead of merging them?
Reconstruction: Can it rebuild the current shape of a project or task, not just retrieve fragments of it?
Model independence: Does the same state work if the model underneath changes?
Operational usefulness: Does it actually change what a person or agent can do, or is it a record nobody consults?
Hypotheses
Hypothesis Ours, unvalidated, stated so they can fail in the open.
H1 Forgetting is a provenance problem. A system can delete, to any rung of the ladder, only what it can trace; the completeness of the lineage graph bounds the completeness of erasure.
What would settle it: A study that achieves verified non-influence (rung 12) without item-level provenance, or one that shows provenance completeness does not predict residue.
H2 The five obligations are sufficient. Any continuity failure a user can name is a failure of carry, govern, evolve, prove or forget.
What would settle it: A reproducible failure class that none of the fifteen questions would have caught.
H3 Governance will become the differentiator. Recall scores on LoCoMo and LongMemEval are converging across memory systems; the next separation will come from state mutation, recovery and erasure, which almost no benchmark scores yet.
What would settle it: Two more years of leaderboards. If recall keeps separating products and governance scores stay unpublished, this was wrong.
H4 Portable memory will be adopted before verifiable memory. Export formats will ship years before signed receipts for deletion are common, because the first is a product feature and the second is a liability.
What would settle it: A major assistant shipping deletion receipts before a memory export.
Version history and signature
v2.07 November 2026
The Continuity Taxonomy becomes the Continuity Framework. The seven continuity properties fold into five obligations (carry, govern, evolve, prove, forget) with fifteen evaluation questions; the eight reading axes retire as a framework element and survive as the landscape's categories. Added: the lifecycle of one carried fact, the erasure ladder of twelve operations, and the distinction between context, memory, knowledge, state, identity and continuity. Every block is labeled established, emerging, ours or hypothesis. The working definition is reissued as v2 to name authority, portability and forgetting. The signature is reissued for the new version.
v1.0July 2026
Initial publication as the Continuity Taxonomy: the canonical continuity-layer definition, eight reading axes, and seven continuity properties, fixed as a versioned asset.
A SHA-256 over the canonical serialization of this version: the version and a fixed publication timestamp, the working definition, each obligation with its questions, and each rung of the erasure ladder with what it guarantees. Reproducible from the text on this page and the erasure ladder; a copy whose text drifts from this digest is self-evidently altered. Versioning this asset is the project practicing continuity on its own core framework, the same supersede-with-a-reason discipline it asks of everyone else (see the Constitution).