# Why I’m Building “doll”: A Personal AI Continuity System > Source: > Published: 2026-06-19 15:58:36+00:00 High-performance AI is available to far more people than it used to be. But there is no guarantee that access will continue under the same conditions. Prices may change. Usage limits may become more restrictive. Models may be discontinued. Accounts, regional restrictions, regulation, provider policies, or service shutdowns may make an AI system unavailable even if it worked the day before. This is not an argument about whether any particular company should or should not be trusted. The problem is that the continuity of a personal AI environment currently depends on conditions the user does not control. That is why I started building **"doll"**, an open-source personal AI continuity system. doll is not a new foundation model. Nor is it intended to replace model runners or interfaces such as Ollama, llama.cpp, Open WebUI, or LM Studio. Its purpose is to preserve the parts of a personal AI environment that should remain usable even when models, providers, applications, runtimes, interfaces, or machines change or disappear. AI systems are often described as though the model were the center of everything. But the model itself is not necessarily the part a person most needs to preserve. The durable parts may include: Models can be replaced. A more capable model may become available. A provider may retire an older one. A user may need to move to a smaller local model because the available hardware has changed. Changing the model should not automatically mean losing the state the user has accumulated. The central idea behind doll is: Models are replaceable reasoning engines. The user's state is the durable core. Running a model locally is an important way to reduce external dependency. A local model may remain usable when a cloud service is unavailable. It can eliminate ongoing API costs and allow data to remain on hardware controlled by the user. But local execution alone does not guarantee continuity. What happens if conversations and memory are stored inside an application-specific database belonging to a single local AI application? What happens if that application is no longer maintained, changes its storage format, stops working on a new operating system, or cannot be moved to another machine? A local application can become another form of lock-in. For this reason, doll does not treat the format of ChatGPT, an OpenAI-compatible API, Ollama, Open WebUI, or any other provider, runtime, or interface as the canonical representation of user state. Data imported from another AI environment must be mapped into a documented and inspectable representation. The result of that mapping must also be honest about loss. An import or export may be: Information that cannot be transferred should not silently disappear. One of doll's governing principles is: Local-complete, cloud-optional. The local system should remain useful without API keys, account registration, or a permanent internet connection. Cloud models may eventually be used as optional performance extensions. In many cases, they will be more capable than the models a user can run locally. But a cloud service must not become the source of truth for: Losing access to the cloud may reduce performance. It should not erase the user's state or remove the path to recovery. At the time of writing, doll is **pre-alpha**. No model runtime is connected yet, and it is not a daily-use AI assistant. That is intentional. Many AI projects begin by connecting a model and building a chat interface. doll is taking a different path because the boundaries a model must not cross need to be defined and enforced before the model is introduced. The model-independent foundation currently being built includes: A model is not automatically trustworthy simply because it runs locally. Local applications, plugins, imported conversations, documents, search results, and tool output must not gain authority merely because they have been placed into a model's context. Adding these controls only after connecting a model would risk turning them into secondary protections around a system whose authority model was never clearly defined. doll is therefore building the boundary first. doll is not intended to be: Moving to another model may change response quality, behavior, personality, or reasoning ability. Moving to less capable hardware may reduce what the system can do. Continuity does not mean that performance never changes. It means preserving what should survive those changes: doll is not a finished product. It cannot yet be installed and used as a complete personal AI assistant. The current focus is on establishing model-independent state management, transfer, backup, restoration, portability, and safety boundaries before local model integration begins. Development is divided into small specifications, issues, branches, and pull requests. The repository records not only what has been implemented, but also the reasoning behind the implementation order, its acceptance requirements, and the expected recovery behavior when something fails. Project website: Source code, specifications, architecture decision records, and implementation history: [https://github.com/badjoke-lab/doll](https://github.com/badjoke-lab/doll) The goal at this stage is not to attract a large number of users. Right now, criticism of the design is more useful than promotion. I am particularly interested in questions such as: I would also like to learn about existing standards, projects, research, and documented failures that address the same problems. doll is still at an early stage. That is precisely why I want to define what must survive, what should remain replaceable, and where authority must stop before presenting it as a finished AI system. *Disclosure: This article was prepared with AI assistance and was reviewed, edited, and approved by the project maintainer.*