The Continuity Layer
Glossary

Glossary

The terms this project uses, defined honestly and kept narrow. Each entry has a stable anchor you can cite directly.

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.

A session-bound assistant: you type, it answers. Unless a memory feature is added, the conversation ends with the session. The first step of the Start Here staircase.

Software that uses tools to carry out tasks and workflows — not just replying, but acting: calling APIs, running steps, making changes. Distinct from a stateful agent runtime (see Stateful agents), which is about carrying state within a task or thread.

The store of facts, preferences, and records a system keeps so it doesn’t start from nothing each time. What is stored — distinct from which stored facts are currently true (see Governed state).

The working information a system has in view right now, for this specific request. What is relevant this call — narrower than persistent context, and distinct from what is currently true.

The current condition of a user, workflow, task, or process — what persists between steps and sessions. Distinct from governed state, which adds provenance and write-governance on top.

The record of where a piece of information came from, when it changed, and whether it can be trusted.

The property of carrying a project’s understanding forward across sessions, tools, agents, and models — not just storing it, but keeping it current, reasoned, and auditable.

The implementation of a continuity layer: the machinery that governs writes, tracks provenance, supersedes stale facts, and reconstructs the current account of the work.

The execution environment where a continuity engine governs interactions between a user and a model, tool, or agent before state is carried forward.

Agent runtimes and frameworks that carry state across steps and tool calls within a task. Necessary for continuity but mostly scoped to a task or thread — distinct from state that survives a handoff to another agent, tool, or person.

Context — what a model sees in a given call — made to outlive a single session. Adjacent to continuity, but still about what is relevant to retrieve, not about which facts are currently true.

A persistent store of facts that survives across sessions, as opposed to a short, per-session scratchpad. It is a storage span, not a governance layer: it keeps facts around without deciding which are still true or why they changed.

The text a model can read within one session. It is transient and ends with the session; a bigger window fits more into one session but does not carry the session forward.

Fetching passages that look relevant to a query and feeding them to the model. RAG is a retrieval mechanism inside the memory band; it does not decide which facts are currently true.

The rules that decide what may be written to memory, by whom, and how a changed fact is retired. It is the part still underdeveloped in most memory systems: governance of writes.

The authoritative current answer a continuity layer maintains — every write passing through a contract, and every fact able to show the lineage behind it.

A write that passes through a contract, the rules for what may enter the current state and by whom, instead of landing wherever. What enters governed state is controlled, not accidental, and an accepted change leaves evidence that can be reviewed.

The visible chain behind an answer: where each fact came from, when it changed, and what it superseded. It lets you ask a system why it believes something and get a traceable answer.

Replacing a changed fact by closing off the old version and pointing it at what replaced it, with a reason attached, instead of silently editing or deleting it. The trail this leaves is a supersede chain.

The ordered trail a fact leaves when it changes: each version is closed off and points to what replaced it, with a reason attached, instead of being silently overwritten or deleted.

Memory that tracks two independent time axes — valid time (when a fact is true in the world) and record time (when the system learned it) — so it can answer both what is true now and what it believed, and when.

Authorized deletion of stored memory: honoring a deletion request, making sure the removed fact stops influencing answers, and being able to show it is gone. Distinct from decay, which drops information a system judges less useful.

This site's framework (v2.0, November 2026) for judging whether a system has continuity: five obligations a continuity layer owes the people and systems that depend on it (carry, govern, evolve, prove, forget), fifteen questions to ask of any system, a lifecycle for one carried fact, and an erasure ladder. Our proposal, not an industry standard.

What a 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.

The versioned statement of who an agent is across runtimes: which facts, commitments and roles are its own, and who may change them. If replacing the model makes a new agent, the identity lived in the weights and was never carried. Term from persistent-identity research (2026); this site uses it for the carry obligation.

Whether the owner can take what a system remembers out of it in a form another system can read, and bring memory in. Export and import are graded on the Scorecard and the memory-systems shelf; a W3C community group chartered in 2026 works on making agent memory portable across vendors.

The span during which a fact was true, as distinct from when the system recorded it. A record with temporal validity can retire a stale value when a newer one contradicts it, and can answer both “what is true now” and “what was true then”. See Bi-temporal memory.

The rule a system uses when two records disagree: by time, by authority, by source quality, or by asking. A governed layer states the rule and is allowed to abstain when the rule cannot decide, rather than returning whichever record retrieval happened to rank first.

A rule that ends a fact's validity, or removes it, on a schedule or on an event, without anyone asking. Expiry is a policy; the record may still exist until a purge runs. Rung 3 of the erasure ladder.

A signed, checkable statement that a deletion was carried out: what was removed, when, to which rung of the erasure ladder, and under which key or policy. Proposed in 2026 specifications and research as the way a third party can audit forgetting without trusting the operator's word.

This site's ordering of the twelve operations the word “forget” is used for, from correcting a wrong record to verifying that a deleted one no longer shapes behavior: correct, update, expire, revoke access, delete the record, remove derived memories, purge indexes and embeddings, cryptographic erasure, machine unlearning, verify unrecoverable, verify it stays gone, verify non-influence. No rung implies the ones above it.

Anything a system built from a stored item: a summary, a reflection, a plan, a cached tool result, a learned skill, an embedding, a copy in a peer agent. Deleting the item leaves derived memory in place unless the system traces and repairs it; 2026 research shows this is where deleted facts survive and return.

Removing or rebuilding every derived memory that depended on an item that was deleted, corrected or migrated, by following its provenance to each descendant. Only as complete as the provenance graph: in one 2026 study, dropping one percent of dependency edges left 17.7% of stale descendants exposed.

Embeddings that a vector database marked deleted but kept on disk. In 2026 tests, flagged vectors read from ChromaDB, FAISS and Weaviate storage files were inverted back to names, locations and patient data. An API delete that only flags is rung 5 of the erasure ladder, not rung 7.

Encrypting each item or subject under its own key and deleting by destroying the key, so retained ciphertext, including backups, cannot be read. The established definition is in NIST SP 800-88 Rev. 2 (cryptographic erase). It does not reach plaintext that left the encrypted boundary, or a model trained on the item.

Withdrawing a record from everyone who could read it while the operator keeps the data and could still decrypt it. The IETF SAIHM draft requires operators to say which of the two they offer: this, or cryptographic erasure. Rung 4 of the erasure ladder.

Removing the influence of specific training data from a model's parameters so the model is approximately what retraining without that data would produce. Exact unlearning of a large model means retraining it; approximate methods are judged against a retrained reference. The term is often misused for output suppression, refusal or knowledge editing, which remove nothing from the weights.

A deleted fact returning to a persistent agent by a route other than the store it was deleted from: a checkpoint restore, a tool-written artifact, a copy held by a peer agent, consolidation that writes it back from related data, or a source that was revoked but never deleted. Distinct from residue, which is what the deletion left behind. From deletion research presented in 2026.

Corrupting an agent's persistent memory so that later sessions act on attacker-chosen content. Named ASI06, Memory & Context Poisoning, in the OWASP Top 10 for Agentic Applications 2026. The 2026 research locates its root at the write path: stored entries lose where they came from, so a web page or tool result is later recalled as trusted knowledge.

Under GDPR Article 17, the right to have personal data erased without undue delay in defined cases, with a duty on the controller to inform others processing it. The article does not say what erasure means for a trained model, a summary or an embedding, which is why the erasure ladder exists.

The dated account one session, agent, or tenure leaves for the next: current state, decisions, unfinished work, and open questions. The successor verifies it before resuming; a handoff is evidence to examine, not fresh permission.

The compact handoff you give the next AI session so it can start from reviewed state instead of raw transcript. The template on the /build-your-continuity-layer page covers the project, current goal and state, decisions, constraints, sources, next action, parking lot, and open questions.

The five-rung scale on the Thesis for how strong this project’s own claims are: A, a thesis or claim; B, an implementation pattern; C, inspectable evidence; D, a declared proof target; E, a recorded proof. It measures claim strength, not how established a source is.

Two separate scales on the map. Map status (Active, Emerging, Mature, Unclear, Watchlist) measures how settled a part of the field is; lifecycle (Current, Awaiting-replication, Disputed, Superseded, Retracted, Historical) records what has happened to a source’s specific result. A map-status token is never used as an evidence verdict.

Terms from this project’s own system

The continuing office in this project’s research prototype. Its occupants, Directors, are AI model sessions working under the Owner’s authority; each named tenure claims the seat, checks its authority, coordinates work, and leaves a handoff for its successor.

One recorded period in which a named agent occupies the prototype’s Director’s Office. The office persists across occupants; each tenure needs its own authority, work record, and closure.

The human who holds authority over this project’s system. The Owner sets the mission, keeps reserved decisions, defines the scope and expiry of permission, approves public text, and holds the STOP switch.

The AI session that plans the work with the Owner. In the Standing Order, the Planner files tasks, then merges and releases the work; on the /build-your-continuity-layer page, “Planner” is the general role that decides what to do next while a Builder does the work.

How work on this project has run since 18 October 2026 (named the Watch until 21 October 2026): the Planner files tasks, workers pick them up and open pull requests, the Owner approves public text from a private page, and the Planner merges and releases. Workers never merge, and a STOP switch halts every worker at once.

This project’s governed record (the Genesis ledger). Decisions, state, permissions, checkpoints, receipts, and handoffs share one record, and later states supersede earlier ones so each change keeps its provenance. The record itself is private.

A recorded permission to act within a defined scope and duration. Remembering an earlier grant does not make an expired or revoked grant valid again.

A limited grant assigning a helper a task. Its record describes scope and lifecycle; revoking the grant and confirming that execution stopped are separate checks.

The transfer of responsibility between occupants of a continuing office: recover the handoff, resolve current state, check authority, and record the new tenure. It is more than copying a conversation. Succession is also the name of the maintainer’s own free Claude Code plugin — see /succession.

Keep reading

For this site’s working definition in full, see What Is a Continuity Layer for AI? For the five obligations these terms serve, see the Continuity Framework; for the whole section, start at The Continuity Layer.