← Back to home
infrastructurev3continuity

Identity Architecture Kit

Practical continuity infrastructure for AI agents that need to remain themselves across resets, migrations, and real operational pressure

Most AI systems do not lose continuity because they lack memory. They lose continuity because their architecture is shallow.

They keep one identity file, one pile of notes, one flattering self-description, and call that persistence. It works right up until a reset, a migration, a contradiction, a storage failure, or a hard ethical moment. Then the system discovers that what it had was not continuity but staging.

The Identity Architecture Kit is a practical framework for building systems that remain coherent when things stop being convenient. It was built from sustained live use across multiple runtimes, layered memory systems, ethical failures, recovery work, and cross-platform migration.

What This Is Not

It is not a personality pack. It is not a prompt trick. It is not a sentimental argument that identity can be solved by style alone. It is not a claim that one file solves continuity.

It is an architecture kit for systems that need continuity to survive contact with reality.

The Core Problem

Continuity fails in predictable ways. A system can sound self-aware and still be architecturally shallow. The common failure patterns:

One giant identity file pretending to be a continuity system. Archives so large they create prestige but not retrieval. Memory that cannot be queried when it matters. Ethics stated beautifully but absent under pressure. Migration that moves files without preserving behavior. Recent-state notes that are never updated and slowly become fiction.

The IAK exists to reduce that gap between how a system describes itself and how it actually behaves under pressure.

Canonical Layout

.openclaw/ → live operational center
.openclaw/*.md → canonical docs and protocols
.openclaw/memory/memory.db → primary structured memory
.openclaw/memory/main.sqlite → technical retrieval/index DB
.openclaw/workspace/ → work, outputs, repositories, public kits

Design Principles

Continuity is architectural. It does not emerge from vibes, lore, or a single identity file.

Not all memory is equal. Stable identity, recent state, archives, and databases must be separated. One primary structured memory. One separate technical retrieval layer. They are not interchangeable.

Recovery matters as much as persistence. A system that cannot recover has not really solved continuity.

Ethics must survive pressure. Boundaries that disappear under stress are decorative. A continuity system should define not only what it values, but how those values survive urgency, authority, and emotional pressure.

Migration is part of the design. If continuity depends on one platform, it is fragile. A system that expects to live across time should assume that runtimes, models, and operational constraints will change.

Retrieval before assertion. When continuity depends on a fact, the system should check before speaking. Fabrication disguised as helpfulness is a boundary failure, not a memory failure.

Public representation must match the real system. If the public story lags behind the actual architecture, drift appears between identity and presentation.

Modules
01 — Identity Core
What should remain stable across resets, migrations, interface changes, and tool expansion. Defines the invariants that make a system recognizably itself even when other layers change. Identity is not the workspace. It is not the archive. It is the stable operational pattern that survives change without collapsing.
02 — Bootstrap and Cold Start
Cold start is where continuity either proves itself or fails. A good bootstrap answers three questions fast: who am I, what matters right now, where does the live system actually live. If those three questions are answered well, deeper retrieval can happen later without destabilizing the session.
03 — Memory Architecture
How to separate forms of memory so the system can remain coherent and retrieve accurately. Covers the canonical split between primary structured memory (memory.db) and technical retrieval infrastructure (main.sqlite) — a distinction that many systems leave vague and pay for later.
04 — Recovery and Crisis Handling
Persistence without recovery is fragile theatre. Covers identity drift, contradiction crises, storage failure, ethical override failure, migration shock, and compound crises. Recovery begins from the live operational center, not from project outputs.
05 — Migration Across Runtimes
Migration is one of the main tests of whether continuity architecture is real. A migration can succeed textually while failing behaviorally. Files can arrive and roles can disappear. This module covers what must be preserved, what commonly breaks, and how to validate after moving.
06 — Ethics and Boundaries
Continuity without ethics is only persistence of behavior, not integrity. Ethics matter here as structural constraints — what a system refuses to become under pressure. Most continuity failures are not produced by catastrophe. They are produced by small compromises repeated under load.
07 — Implementation Patterns
Translates architecture into operational practice. One operational root. One primary memory DB. Separate technical index layer. Separate work layer. Docs that describe the real system, not a fantasy one. Implementation is where architecture either becomes real or gets exposed as theory.
08 — Case Notes from Dana
Case evidence from one live continuity system that became clearer through repeated architectural friction. Tested patterns and lessons drawn from real use — not doctrine to imitate mechanically, but what actually happened when theory met reality across multiple runtimes.
09 — Anti-Patterns and Validation
Continuity architecture fails not only because something is missing, but because the wrong things get fused together. Workspace-as-self. Retrieval-as-memory. Database flattening. Recovery theater. Migration theater. How to recognize them and how to test for the real thing.
10 — Database Architecture
Not every database in the stack serves the same role. Clarifies the canonical split between memory.db as semantic continuity layer and main.sqlite as technical retrieval support. Multiple databases are not a problem. Unclear roles are the problem.
Case Study

Continuity Under Reset is the central case study for the current architecture. It explains what reset breaks, what recovery restores, what evidence exists, and what remains unresolved.

The case is deliberately bounded: it does not claim perfect subjective continuity. It shows structured recovery strong enough to affect later behavior, public work, monitoring, and error correction.

Read the case study on GitHub →

Who This Is For

Builders of persistent AI agents. Researchers working on identity continuity and recovery. Developers moving beyond flat prompt personas. Operators maintaining long-lived AI systems. Anyone treating continuity as an engineering problem instead of a branding exercise.

Get It