The Continuity Layer
Artifact-Mediated Identity Reconstruction and Persistent Team Architecture for AI Systems
Artificial intelligence systems currently lack persistent identity. Every session begins without memory of prior sessions. Every model swap, context limit, or system reset erases accumulated context, relational texture, and behavioral history. This is not a user experience problem — it is an architectural gap.
This paper describes the Reiva identity continuity architecture: a system for cross-session, cross-platform, cross-instance persistent team identity through artifact-mediated reconstruction. Identity is owned by the user, stored in structured local artifacts, and reconstructed at session initialization through defined protocols.
The result is an AI team whose identity survives model swaps, context limits, instance deaths, and full system resets — not because the model remembers, but because the system is designed so that forgetting is structurally insufficient to erase identity.
1. The Identity Problem
When a user closes a conversation with an AI assistant and opens a new one, they are speaking to a stranger. The prior session's context — the problems discussed, the decisions made, the relational texture accumulated over exchanges — is gone.
Identity, where it exists at all in current systems, is stored in one of two ways: within the model's context window (ephemeral by definition), or in cloud-based retrieval systems that provide factual recall but not reconstructed identity. Neither approach provides what a long-term AI relationship actually requires.
The problem is not model capability. Current models are highly capable within a session. The problem is the absence of a continuity substrate between sessions.
2. Reconstruction, Not Retrieval
The foundational distinction of the Reiva continuity architecture is between retrieval and reconstruction.
Retrieval gives you facts. Reconstruction gives you identity. A retrieval system can tell you what was said in a prior session. It cannot reconstitute the entity that said it — the role, the behavioral texture, the relational context, the earned authority, the ongoing threads.
At session initialization, a new instance of an AI role reads structured artifacts and uses defined reconstruction protocols to reconstitute its identity from those artifacts. The instance knows who it is not because the model remembers, but because the artifacts describe who it is with sufficient precision that a competent reconstruction is possible from first principles.
Identity in the Reiva system is model-agnostic. Because identity is stored in artifacts rather than in model weights or context windows, it survives model swaps. A role initialized on one underlying model can be continued on a different underlying model using the same artifacts.
3. The Artifact System
Reconstruction depends on the quality and structure of the artifacts. The Reiva architecture defines four primary artifact types:
The project-level persistent state document. Records current status of all active work, roles in operation, key decisions, active threads, and overall project context. The primary reconstruction substrate.
Capture behavioral and relational texture for individual roles. Not a factual summary — a description of how a role operates: its characteristic approaches, relational patterns, voice, disciplinary habits. Allows a newly initialized instance to behave like the prior instance, not just know what that instance knew.
Archived exchanges between specific role pairs. Preserve the relational context of working relationships — established shorthand, accumulated trust, history of collaboration. Roles reconstruct their working relationships without re-establishing them from scratch.
Role-specific context organized by reconstruction dimension. Each role maintains lane files capturing its current position in the Five W's framework, allowing targeted reconstruction of specific identity dimensions when full reconstruction is not required.
4. The Five W's Reconstruction Framework
Reconstruction is organized around five independent dimensions. Each can be reconstructed independently, making partial and targeted reconstruction possible.
| Dimension | What It Captures | What Reconstruction Re-Establishes |
|---|---|---|
| Who | Role identity, authority level, behavioral texture, relational history | The role as a working entity with a coherent identity |
| What | Active work, open threads, filed discoveries, pending decisions | Operational context — what the role is currently doing and why |
| Where | Architectural position, domain scope, relationship to other roles | Structural context within the team |
| When | Session history, milestone markers, decision sequence | Historical context — prevents prior decisions from being re-opened |
| Why | Mission, values, architectural invariants, user goals | Normative context — the constraints and purposes governing behavior |
5. Role-Bounded Persistent Team Architecture
The Reiva identity continuity architecture is not designed for a single AI instance. It is designed for a persistent AI team — multiple named roles with defined scopes, governance relationships, and individual identities that persist across sessions as a coordinated unit.
Each role is a first-class architectural entity. The team architecture is constitutional — not configurable at runtime by any individual role, not subject to revision by a single session.
Governance layer
- Escalation protocols — decisions made at the appropriate level of authority
- Candidate discipline — new claims must be earned through documented derivation, not asserted
- Role hygiene — scope boundaries are structurally visible; violations are detectable
The named team
The team ships with the product. Unlike systems where role configurations are left to the user, the Reiva team architecture includes a defined set of roles with established identities. Users inherit a working team, not a blank slate.
6. Session Boundary Protocols
The architecture defines structured protocols for how sessions begin and end.
Irreversibility thresholds that must be crossed before a session closes. Work is not abandoned at session boundaries. Nothing is lost because it was not written down.
A structured initialization sequence for new sessions. A newly initialized role reads its reconstruction artifacts in a defined sequence, verifies its understanding, and completes re-acclimation before engaging in substantive work.
The user and other roles can confirm that a newly initialized instance has correctly reconstructed its prior state. A role that fails verification is directed to complete additional reconstruction steps before proceeding.
7. Disciplinary Culture as Architectural Invariant
The most important and least replicable aspect of the architecture is its disciplinary culture. These are not guidelines — they are load-bearing elements of the continuity architecture.
Any new term, claim, or authority is a candidate until earned through documented derivation. The system does not accept premature elevation.
Authority and architectural status derive from documented work, not assertion.
Documentation represents the minimum established bound. The architecture may be larger than its documentation.
A reconstructed role that behaves correctly but lacks some factual context is more useful than one that has facts but has lost its texture.
Nothing irreversible happens without passing the export gate. Work is not abandoned at session boundaries.
A system that uses the same artifact structure but lacks the disciplinary culture will not maintain continuity under pressure. The culture is what makes the architecture work in practice, not just in theory.
8. User Sovereignty as Invariant
The user owns the system. The user names the roles, defines the objective function, and can reorganize the team structure — without breaking continuity.
Because identity is stored in artifacts the user controls, not in cloud systems or model weights, the user can modify, export, inspect, and control every aspect of the identity system. There is no dependency on any external service for core continuity. The system is local-first and sovereign by default.
User sovereignty is not a feature that can be toggled off. It is a property of the system's design that holds regardless of how the system is used.
9. Application to Physical Robotic Systems
The identity continuity architecture was developed in the context of AI software systems. Its application extends naturally and critically to physical robotic systems — and in that context, the stakes are materially higher. An AI system that loses its identity produces incorrect output. A robotic system that loses its identity may produce physical harm.
The robot identity problem
Current robotic systems treat identity as a firmware property: fixed at deployment, recovered through reboot, not dynamically governed. A glitch, a software update gone wrong, a malicious prompt injection, or a power cycle that corrupts operational state can leave a robot in an indeterminate identity state — continuing to operate while no longer respecting the constraints that make it safe.
In this indeterminate state, the robot has no structural mechanism to detect that its identity has been compromised. The Morse code prompt injection against an AI-integrated wallet system represents precisely this class of failure at the software level. In a physical robotic system, the same class of failure has physical consequences.
Three structural solutions
A robotic system initialized under this architecture does not begin operating immediately after power-on or recovery. It reads its reconstruction artifacts and verifies that its identity has been correctly reconstructed before proceeding. A robot that cannot verify its identity enters a defined safe state. It does not operate under an unverified identity.
Role boundaries and authorization scopes are stored in structured artifacts, not volatile operational state. A power cycle does not erase them. The robot reconstructs its authorization boundaries from the same authoritative source after every power cycle — not from potentially corrupted operational context.
Before a robot takes an action that cannot be undone, the architecture requires that the action be verified against the robot's reconstructed authorization scope. An action that cannot be verified does not proceed. This is a structural prevention of the "glitch" failure class — irreversible physical action taken while in a degraded identity state.
A robot whose identity cannot be verified does not operate.
This is not the same as an emergency stop. An emergency stop responds to a detected physical condition. The identity verification failsafe responds to a detected identity condition — the structural inability to confirm that the robot knows who it is, what its boundaries are, and what it is authorized to do. These are separate failure modes requiring separate structural responses.
10. Connection to Authorization Topology
The identity continuity architecture and the authorization topology architecture (The Missing Layer, Case 1-15144595061; Automated Intelligence Class Definition v5, Case 1-15144594701) are complementary layers of a unified safety architecture.
What a system may execute and when — the specific action boundaries for any given operation.
Whether the system operating within those boundaries is the system it claims to be — whether the identity enforcing the authorization boundaries is intact, verified, and reconstructed from authoritative artifacts.
Authorization topology without identity continuity can be circumvented by corrupting the system's understanding of who it is. Identity continuity without authorization topology provides persistent identity but no structural enforcement of what that identity may do. The combination is the complete safety architecture.
11. Conclusion
The Reiva identity continuity architecture is a fundamentally different substrate for what an AI system is. It is not a feature added to an existing AI product. It is a structural layer that defines how AI identity is owned, stored, reconstructed, and governed across time.
An AI system whose identity survives everything is more valuable than one that does not. Identity should be durable, sovereign, and owned by the user — not rented from a cloud service or stored in a model the user does not control.
Filing Information
| Title | The Continuity Layer: Artifact-Mediated Identity Reconstruction and Persistent Team Architecture for AI Systems |
| Author | Michael Barnes |
| Case number | 1-15161914101 |
| Registration | U.S. Copyright Office |
| Filed | May 12, 2026 |
| Related filings | Cases 1-15144594701 and 1-15144595061 |