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.
The model should not be the durable core
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:
- memory and long-term state;
- preferences, policies, and permissions;
- conversations and their provenance;
- documents, research records, claims, evidence, and sources;
- generated artifacts and project history;
- model and runtime manifests;
- import, export, backup, restore, and migration records;
- explicit records of information that could not be transferred.
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.
Local AI alone does not solve continuity
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:
- full;
- partial;
- transformed;
- unsupported;
- lossy.
Information that cannot be transferred should not silently disappear.
Local-complete, cloud-optional
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:
- memory;
- identity;
- files;
- permissions;
- portability;
- backups;
- recovery information.
Losing access to the cloud may reduce performance.
It should not erase the user's state or remove the path to recovery.
Why doll does not have a connected model yet
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:
- separating ordinary memory from secrets;
- preventing secrets from leaking through logs, exports, backups, test fixtures, or diagnostics;
- storing references to secrets rather than secret values in ordinary state;
- performing bounded, credential-backed operations without exposing stored credentials to a model;
- distinguishing confirmed facts, claims, evidence, and inferences;
- recording the origin of information and instructions;
- treating retrieved pages, documents, tool results, and imported data as data rather than authority;
- granting external capabilities explicitly and within defined limits;
- requiring fresh user confirmation for high-risk operations;
- preserving the last known good state when an operation fails.
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.
What doll is not
doll is not intended to be:
- another model runner;
- a clone of an existing local AI interface;
- a cloud-dependent assistant;
- an unrestricted autonomous computer-control agent;
- a credential database embedded in ordinary AI state;
- a guarantee of permanent frontier-model performance;
- a claim that different models will behave identically;
- a promise of universal, lossless migration.
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:
- user-owned state;
- provenance;
- permissions and safety boundaries;
- visible migration loss;
- backups;
- recovery procedures;
- a documented path to another environment.
Current status
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
What I would like criticism on
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:
- Where should canonical user state end and model-specific state begin?
- What information is inevitably lost when moving between AI environments?
- How much provenance can realistically be preserved?
- Does the proposed separation between secrets, ordinary state, and model access contain hidden weaknesses?
- Can the system actually recover when an application, runtime, model, or primary machine disappears?
- Could doll itself become a new form of lock-in?
- Does the claim of being locally complete still depend on assumptions or external components that have not yet been recognized?
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.