DEV Community: Sohachi

How Comparing PAM, PLUR, and PROJECTMEM Changed doll's Design

Sohachi — Wed, 19 Aug 2026 16:00:11 +0000

The previous article compared Portable AI Memory (PAM), PLUR's Engram specification, PROJECTMEM, and doll.

The useful result was not choosing a winner. It was deciding which ideas belong in which layer.

Several things I had been calling "memory" were actually different kinds of state with different authority. That distinction changed concrete parts of doll's design.

The five most important changes are these:

confirmed memory was separated from derived recall state;
interchange formats became adapters instead of candidates for Doll State itself;
project experience became its own append-oriented history rather than current project authority;
imported and model-proposed information was kept below user-confirmed authority;
pre-action continuity checks became a separate deterministic read model rather than another execution authority.

This article is about those design changes, not another comparison of the external projects.

1. MemoryRecord Is Not RecallState

PLUR was useful because its Engram design makes retrieval dynamics visible: activation, decay, reinforcement, associations, usage feedback, and search all affect which memory is useful now.

That is a different question from whether the memory itself is still true.

The distinction sounds obvious until a memory system starts storing retrieval metadata next to the memory content and gradually treats both as one object.

In doll, confirmed MemoryRecord content is canonical durable state. Retrieval ranking, activation-like signals, search scores, and other recall signals are derived state. They can change, expire, or be rebuilt without rewriting what the memory says.

That means a memory is not made "less true" because it has not been retrieved recently, and it is not made "more true" because the system used it many times.

It also gives doll a cleaner failure mode. If a search index or future activation cache is lost, recall quality may temporarily degrade, but confirmed memory does not disappear with it.

Recall can be derived from memory. Memory should not be silently rewritten by recall.

2. PAM Became an Adapter Boundary, Not Doll State

PAM made another boundary much clearer.

Its specification explicitly describes PAM as an interchange format rather than a storage format. That is exactly the kind of boundary doll needs at the edge.

PAM v1.0 specification:

https://portable-ai-memory.org/spec/v1.0/

The tempting alternative would be to adopt a portable external schema as the canonical internal database simply because portability matters. But portability and internal authority are not the same problem.

doll therefore treats PAM v1.0 as an adapter target. Imported data is parsed and mapped into a staged form first. Unsupported or ambiguous semantics remain visible. Imported memories do not become normal confirmed MemoryRecords until they pass the appropriate review boundary.

Export works in the other direction: confirmed non-secret memory can be represented in bounded PAM output without pretending that PAM is a complete Doll State Package.

That last distinction matters. A memory interchange export is not a complete continuity export. It does not by itself contain every project, work item, decision, permission, procedure, recovery state, or execution boundary that makes a long-running AI environment resumable.

Use external standards where they fit the boundary. Do not force the internal authority model to become the interchange format.

3. Project Experience Became History, Not Authority

PROJECTMEM sharpened a different problem: project history should survive beyond chat transcripts and should be useful before the same mistake is repeated.

PROJECTMEM paper:

https://arxiv.org/abs/2606.12329

PROJECTMEM source repository:

https://github.com/riponcm/projectmem

That led doll to make project experience a first-class record instead of leaving failed attempts and lessons trapped inside conversation history.

The implemented ProjectExperienceRecord is append-oriented and can represent observations, hypotheses, attempts, outcomes, resolutions, and lessons. Corrections are represented through linked replacement or supersession rather than silently rewriting the semantic history.

ProjectExperienceRecord implementation:

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

But the most important part is what the record is not allowed to do.

An experience record does not complete or reopen a WorkItem. It does not change ProjectRecord scope. It does not create a DecisionRecord. It does not approve a required procedure. It does not grant a permission.

That boundary prevents a very easy category error: confusing "this happened before" with "this is the current authoritative state."

Historical experience can be valuable without being sovereign.

4. Imported and Model-Proposed Information Stay Below Authority

Once interchange and project experience are both first-class concepts, another problem appears immediately: what happens when imported or model-generated records make strong claims?

An imported record might say that a project is complete. A model-generated lesson might say that a particular action should never be attempted again. An external memory format might contain an access field that looks similar to a local permission.

doll does not allow those similarities to manufacture authority.

Imported or model-proposed information can be preserved, linked to provenance, surfaced to the user, and used as evidence. But it cannot silently become policy, permission, current work state, or a hard denial.

This is also why mapping loss has to stay visible. If an external concept does not map exactly onto a Doll concept, the system should preserve the ambiguity instead of inventing a clean equivalence.

A field named confidence is a simple example. One system may mean extraction confidence; another may mean user-reviewed trust. Treating those as equivalent because the names match would make migration look cleaner while damaging the authority model.

Preserve imported knowledge. Preserve uncertainty too.

5. ContinuityPreflight Became a Separate Read Model

The PROJECTMEM comparison also made pre-action checks more concrete. It is useful for a system to look at accepted project history before repeating an action that already failed.

But doll already had separate authority boundaries for policy, work state, procedures, permissions, and capabilities. Folding all of that into one new "memory judgment" layer would have made the architecture harder to reason about.

The resulting implementation is ContinuityPreflight: a deterministic, model-independent read model over explicit accepted project and action scope.

ContinuityPreflight implementation:

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

It composes existing authoritative signals such as applicable policy denials, WorkItem blockers and incomplete dependencies, required procedure state, permission resolution, and capability safety state. It can also surface directly relevant prior failures from ProjectExperienceRecord as evidence-linked warnings.

The distinction between warning and authority is intentional. A past failed attempt can warn without becoming a permanent prohibition. Imported or model-proposed experience cannot manufacture a hard deny.

And a preflight result of clear does not grant execution permission. The Capability Broker remains the execution authorization boundary.

A continuity check can inform execution without becoming the thing that authorizes execution.

The Comparison Changed the Boundaries More Than the Feature List

None of these changes means doll should absorb PAM, PLUR, or PROJECTMEM wholesale. In fact, the comparison pushed the design in the opposite direction.

The useful pieces belong at different layers:

PAM belongs at the interchange boundary;
PLUR-like activation and retrieval ideas belong in derived recall state;
PROJECTMEM-like project experience belongs in append-oriented work history;
current project state, permissions, policy, and execution authority remain separate;
pre-action continuity is a deterministic composition over accepted state, not a new source of truth.

That is more important than adding another feature named "memory."

What I Deliberately Did Not Adopt

Comparison is also useful because it identifies ideas that should remain external, derived, or later work.

doll does not currently claim a PLUR adapter or PROJECTMEM adapter. MCP is not implemented as part of this work. PAM interoperability does not mean complete state-package interoperability. ProjectExperienceRecord is not a replacement for WorkItem, DecisionRecord, PolicyRecord, ProcedureRecord, or PermissionRecord.

The project also does not claim that Phase 6, Lite v1.0, primary Intel Mac resource acceptance, or a general anti-lock-in standard is complete.

Those limits matter because architectural comparison is easy to turn into a story about a finished universal layer. doll is not there, and this work does not pretend otherwise.

A More Precise Definition of Continuity

The comparison left doll with a more precise definition of what it is trying to preserve.

Continuity is not just the ability to export a list of memories. It is not just a better retrieval algorithm. It is not just a durable project log. And it is not just an agent remembering previous failures.

Those are all useful parts.

But continuity also requires keeping authority explicit: what is confirmed, what is derived, what is historical, what was imported, what is currently blocked, what requires permission, what may execute, and what can be rebuilt after a model, provider, runtime, interface, or machine changes.

Standardize interchange. Derive recall. Preserve experience. Keep authority explicit.

Sources

Previous doll article — Portable Memory Is Not AI Continuity: PAM, PLUR, PROJECTMEM, and doll

https://doll.badjoke-lab.com/notes/portable-memory-not-ai-continuity/

Portable AI Memory — Specification v1.0

https://portable-ai-memory.org/spec/v1.0/

PLUR — The Engram Specification v2.1

https://plur.ai/spec.html

PROJECTMEM paper

https://arxiv.org/abs/2606.12329

PROJECTMEM source repository

https://github.com/riponcm/projectmem

doll — Memory Interoperability, Recall, and Project Experience specification

https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md

doll — ProjectExperienceRecord implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

doll — ContinuityPreflight implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

Canonical doll article:

https://doll.badjoke-lab.com/notes/pam-plur-projectmem-changed-doll-design/

External specifications and project descriptions referenced here were checked for the preceding comparison article on August 16, 2026. This article focuses on doll's resulting design decisions and merged implementation boundaries. It does not imply that PAM, PLUR, or PROJECTMEM endorse doll's architecture.

Disclosure: This article was prepared with AI assistance and reviewed, edited, and approved by the project maintainer.

Portable Memory Is Not AI Continuity: PAM, PLUR, PROJECTMEM, and doll

Sohachi — Sun, 16 Aug 2026 16:37:50 +0000

A few days ago I wrote that AI memory is becoming more portable, but portability is still not the same thing as continuity.

The obvious next question is whether that distinction already exists elsewhere in more concrete technical form.

It does.

Three projects are especially useful to compare with doll: Portable AI Memory (PAM), PLUR's Engram specification, and PROJECTMEM. They overlap with parts of what doll is trying to do, but they start from different problems and make different things canonical.

This is not a ranking and it is not a competitor roundup. The useful question is narrower:

Which ideas should doll adopt, which boundaries should remain separate, and where should interoperability replace another private format?

The short version

The four systems are easiest to understand as different layers:

PAM: how memory can cross system boundaries in a vendor-neutral interchange format.
PLUR / Engram: how persistent memories can be retrieved, activated, reinforced, and allowed to decay over time.
PROJECTMEM: how project experience can be recorded as local event history and used to warn an agent before it repeats a known failure.
doll: how memory, projects, decisions, work state, provenance, permissions, recovery, and model-independent execution state can remain resumable when the model or provider changes.

Those are not mutually exclusive answers.

The most useful result of comparing them is that doll should not try to turn all four jobs into one record type or one proprietary memory format.

PAM: standardize what crosses the boundary

Portable AI Memory is the clearest answer to the interchange problem.

PAM v1.0 defines a vendor-neutral JSON format for moving user memories between systems. Its specification includes provenance, lifecycle state, confidence, relations, access metadata, integrity information, optional conversation files, and optional embeddings.

Specification:
https://portable-ai-memory.org/spec/v1.0/

The most important scope boundary is simple:

PAM is an interchange format, not a storage format.

That distinction fits doll unusually well.

A portable format does not need to become the internal database schema. The internal system can preserve richer local semantics while importing and exporting a stable external contract at the boundary.

That is the approach doll now takes. PAM is treated as an adapter target rather than as Doll State itself. The implemented PAM path is deliberately staged: external data is parsed and mapped, ambiguous or unsupported semantics stay visible, imported memories require explicit review before becoming normal confirmed MemoryRecords, and confirmed non-secret memories can be exported back to bounded PAM v1.0 output.

This matters because a field that exists in two systems is not necessarily authoritative in the same way.

An imported lifecycle label, confidence score, relation, or access declaration may be useful evidence without automatically becoming a doll permission, decision, or policy.

PAM therefore answers an important part of the portability problem without needing to answer the entire continuity problem.

PLUR: memory is not just stored or retrieved

PLUR's Engram specification starts from a different question.

Its Engram model describes an atomic unit of learned knowledge that is individually addressable, activation-weighted, and decay-aware. It specifies activation, decay, reinforcement, associations, usage feedback, and a search pipeline.

Specification:
https://plur.ai/spec.html

The useful idea here is not merely "store more metadata."

It is that what a memory says and how useful it is to retrieve right now are different kinds of state.

Consider a durable memory:

The user prefers local-first tools when the core workflow can remain complete offline.

The content of that memory should not silently change because it was retrieved ten times this week, ignored for a month, or ranked lower by a new search algorithm.

That observation sharpened an important boundary in doll: confirmed MemoryRecord content remains authoritative memory, while recall state is derived and rebuildable.

Ranking, activation-like signals, retrieval scores, and future usage signals belong to the recall layer, not to the truth of the memory itself.

This also means doll does not need to copy PLUR's engine-specific state into its canonical memory schema. A future PLUR adapter can preserve and translate what is meaningful without pretending that every activation or decay parameter is universal memory truth.

PROJECTMEM: project history can act before the next mistake

PROJECTMEM is closer to a different part of doll.

Its paper describes a local-first, event-sourced memory and judgment layer for coding agents. Development history is recorded as append-only typed events such as issues, attempts, fixes, decisions, and notes. The system then projects that history into compact summaries and includes a deterministic pre-action gate that can warn before a previously failed fix is repeated or a known-fragile file is edited.

Paper:
https://arxiv.org/abs/2606.12329

Source repository:
https://github.com/riponcm/projectmem

The key insight is that project memory is not only something an agent searches after it gets confused.

Prior experience can be checked before an action is repeated.

doll now has a related but deliberately separated pair of concepts:

ProjectExperienceRecord stores append-oriented semantic work history such as observations, hypotheses, attempts, outcomes, resolutions, and lessons.
ContinuityPreflight reads accepted project state before a proposed action and can surface a directly relevant prior failure as an evidence-linked warning.

ProjectExperienceRecord implementation:
https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py

ContinuityPreflight implementation:
https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

But there is an important authority boundary.

A past failed attempt is not automatically a permanent prohibition. Imported project history is not automatically trusted. A model-proposed lesson does not become a policy. A remembered claim that work is complete does not complete the WorkItem.

In doll, prior experience can warn.

Hard blocking still comes from existing authoritative state such as an applicable policy denial, a blocked or incomplete WorkItem dependency, an unapproved required procedure, a permission decision, or a capability safety boundary.

That separation is intentional:

Experience can inform authority without quietly becoming authority.

One word, several kinds of state

The comparison makes "memory" look too broad to be a useful architecture by itself.

At least five different layers appear.

1. Canonical durable state

Things the system is expected to preserve as authoritative user-owned state: confirmed memory, project scope, accepted decisions, work state, permissions, policies, artifacts, and their provenance.

2. Derived recall state

Search indexes, ranking scores, activation-like values, retrieval candidates, and other state that can be rebuilt from authoritative data.

3. Experience history

What was tried, what failed, what worked, what was later corrected, and which evidence supports that history.

4. Interchange formats

External contracts such as PAM that let some of those semantics cross system boundaries without dictating the local storage engine.

5. Pre-action continuity checks

Deterministic checks that ask whether accepted state already contains a blocker, confirmation requirement, incomplete dependency, required procedure, or relevant failure before another action begins.

Combining all five into a single "memory object" would make portability look simpler while making authority harder to reason about.

The hard part is not mapping fields. It is mapping meaning.

Suppose two systems both have a field called confidence.

One may mean model-estimated extraction confidence. Another may mean a user-reviewed trust state. Treating those as interchangeable because the field names look similar would create semantic loss while claiming successful migration.

The same problem appears with:

active versus authoritative;
remembered versus confirmed;
decision versus historical note;
permission versus imported access metadata;
failed attempt versus permanent prohibition;
retrieval score versus memory truth;
conversation history versus current project state.

A continuity system therefore needs to preserve loss and uncertainty, not hide them.

When an external format cannot express a doll semantic exactly, the safer result is an explicit partial mapping, preserved original evidence, or quarantine—not a fabricated equivalence.

Why doll should prefer adapters over another universal format

It would be easy for doll to define its own grand interchange format for memory, projects, decisions, experiences, permissions, conversations, and everything else.

That would also be an easy way to create another island.

Where a useful external contract exists, the better default is to adapt to it.

PAM is already the first general memory-interchange target in doll. PLUR and PROJECTMEM are later interoperability candidates where their semantics match a real boundary. MCP is also later work rather than something that should be smuggled into the core state model just because several adjacent projects use it.

The relevant doll roadmap is here:
https://github.com/badjoke-lab/doll/blob/main/docs/spec/09a-post-imp-083-memory-continuity-roadmap.md

The memory interoperability, recall, and project experience specification is here:
https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md

The canonical Doll State can remain richer than any one interchange format while still avoiding gratuitous proprietary formats at the edges.

These projects are more complementary than competitive

PAM is strongest as a portable contract.

PLUR is useful for thinking about retrieval dynamics and memory-use state.

PROJECTMEM demonstrates how local project history can become deterministic pre-action judgment.

doll needs pieces of all three problem areas because its target is broader continuity across models, runtimes, providers, interfaces, and machines.

That does not make doll a superset of those projects. It means its architecture has to decide where their ideas belong without collapsing their different semantics into one internal abstraction.

The resulting rule is simple:

Standardize interchange. Derive recall. Preserve experience. Keep authority explicit.

That is a much more useful foundation for continuity than treating every persistent fact, score, event, and permission as "memory."

What comes next

The comparison has already changed concrete boundaries in doll:

MemoryRecord is separated from derived RecallState;
PAM is an adapter instead of the canonical store;
ProjectExperienceRecord is append-oriented history rather than current project authority;
ContinuityPreflight can use prior failures as warnings without allowing imported or model-proposed experience to manufacture a hard denial.

The next article in this series will focus on those design changes themselves: what changed, what was deliberately not adopted, and which interoperability work remains later.

The larger goal remains the same: the model can change, the provider can change, and the interface can change without forcing the user's durable AI environment to start over.

Sources

Portable AI Memory — Specification v1.0

https://portable-ai-memory.org/spec/v1.0/
PLUR — The Engram Specification v2.1

https://plur.ai/spec.html
PROJECTMEM paper

https://arxiv.org/abs/2606.12329
PROJECTMEM source repository

https://github.com/riponcm/projectmem
doll — Post-IMP-083 Memory & Continuity Roadmap

https://github.com/badjoke-lab/doll/blob/main/docs/spec/09a-post-imp-083-memory-continuity-roadmap.md
doll — Memory Interoperability, Recall, and Project Experience specification

https://github.com/badjoke-lab/doll/blob/main/docs/spec/03c-memory-interoperability-recall-and-project-experience.md
doll — ProjectExperienceRecord implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/project_experience.py
doll — ContinuityPreflight implementation

https://github.com/badjoke-lab/doll/blob/main/src/doll/continuity_preflight.py

This is a syndicated version of the canonical doll article:

https://doll.badjoke-lab.com/notes/portable-memory-not-ai-continuity/

External specifications, paper metadata, and current project descriptions were checked on August 16, 2026. PAM claims refer to the published v1.0 specification; PLUR claims refer to the Engram v2.1 specification; PROJECTMEM architecture claims distinguish the cited research paper from the current source repository. Statements about how these ideas should map into doll are doll's design analysis, not claims made by the external projects.

Disclosure: This article was prepared with AI assistance and reviewed, edited, and approved by the project maintainer.

AI Memory Is Becoming Portable. Continuity Still Isn't.

Sohachi — Wed, 12 Aug 2026 10:36:27 +0000

Moving your chats is progress. Moving your AI life is a different problem.

AI services are finally starting to make switching less painful.

Google now lets eligible Gemini users import memory-like context and chat history from other AI platforms, including exports from ChatGPT and Claude.

That is real progress.

For a long time, “portability” often meant little more than downloading a ZIP file and keeping it somewhere safe. Now a major AI provider is treating another provider’s history as something that can become useful context again.

But that raises a more important question:

What exactly has moved?

Export is not portability

ChatGPT can export your history and account data.

Claude can export conversation and user data.

Gemini can export chats, generated media, uploads, Gems data, and other activity through Google Takeout.

Those features matter.

But an archive is not a working AI environment.

OpenAI’s own guidance for moving conversations between personal ChatGPT accounts makes this distinction clear. You can upload an exported conversations.json file into a new chat and use it as reference material.

But OpenAI explicitly says this is not a full migration.

It does not recreate the original chats, sidebar structure, settings, memories, GPTs, files, subscriptions, or workspace access.

You can carry the record of the past without recreating the environment that produced it.

Export is not portability. And portability is not continuity.

There are really four different problems

I think AI portability is easier to understand if we separate four layers.

1. Exportability

You can get your data out.

JSON, ZIP, HTML, media files, or another documented archive format.

This protects against total lock-in, but by itself it is closer to backup than migration.

2. Importability

Another system can accept that exported material.

Gemini’s new cross-platform import flow is an important example.

3. Portability

The imported material remains useful in the destination.

It can be searched, referenced, or reused as context instead of sitting there as an inert archive.

This is where the industry is starting to make real progress.

4. Continuity

You can change the model, provider, application, runtime, or machine and still resume from where you were.

Not merely recover what you once said.

That is a different engineering problem.

Chat history is not current state

Imagine someone who has spent a year building software with an AI assistant.

They successfully move ten thousand old conversations to a new provider.

That is valuable.

But does the new system now know:

which issue is currently being worked on;
which pull request is authoritative;
which specification is current;
which design was rejected and why;
which decisions are final and which are provisional;
which failure must not be repeated;
what has already been tested;
what should happen next?

Some of those answers may exist somewhere inside the transcript.

That is not the same as having current state.

A transcript tells a new model what happened.

A continuity layer must also preserve what remains true now, what has been superseded, where a claim came from, and what work is still open.

Chat history is a record of the past. Continuity is the ability to resume from it.

Chat history is not work state

Browser state is a simple example.

When OpenAI ended Atlas, users were told to save important Atlas data before shutdown. Bookmarks would not transfer automatically, open tabs might not transfer, and browser history might not transfer.

Meanwhile, ChatGPT conversation history was separate.

That illustrates a broader point:

The state of an AI-assisted task does not live only in the transcript.

It may also live in:

open pages;
files;
tabs;
repositories;
pending actions;
tools;
local artifacts;
external systems.

Chat history is not work state.

Memory is not the whole continuity layer either

Portable memory is important, but memory alone is still too narrow.

A memory like:

The user prefers concise answers.

is useful.

But compare that with:

Approach B replaced approach A because of constraint X. The decision was accepted in issue 123, and later implementation assumes B unless explicitly superseded.

That is not just “memory.”

It is part of project authority and decision state.

A durable AI environment may need to preserve:

memory and preferences;
project state;
decision history;
provenance;
unresolved work;
relationships between records;
current authority;
recovery information;
tool and workflow state.

Remembering who the user is and knowing where the user currently is in a long-running body of work are related problems.

They are not the same problem.

Provider-to-provider portability is still provider-dependent

Gemini’s importer deserves credit because it reduces switching cost.

But look at the architecture:

ChatGPT / Claude
       ↓
     Gemini
       ↓
  Provider C

ChatGPT and Claude data become portable into Gemini because Google built the importer.

If the user later moves again, Provider C needs to understand enough of the previous provider’s exports to make that migration useful.

This is much better than no portability.

But it is still provider-to-provider portability.

Put the canonical state outside the provider

A different architecture is possible:

         User-owned continuity
 memory / decisions / projects / state
                    ↓
                  doll
        ↙           ↓           ↘
    Local AI     ChatGPT     Gemini / Claude / ...

In this model, the canonical copy of durable state does not live inside whichever AI service happens to be active today.

The provider is a capability layer.

It receives the context it needs, does the work it is good at, and can be replaced later.

The continuity layer remains under the user’s control.

If an import format changes, an adapter can change.

If a model is discontinued, another model can be used.

If cloud access disappears, the durable state does not disappear with it.

What doll is trying to separate

This distinction is central to doll.

doll is not trying to become the foundation model that survives forever.

It is trying to make the foundation model replaceable.

The continuity layer belongs on the user’s side:

memory;
preferences and personality settings;
project state;
DecisionRecords;
provenance;
work state;
user-owned data and recovery state.

The capability layer can change:

local models;
OpenAI;
Anthropic;
Gemini;
future models that do not exist yet.

The principle is simple:

Own the continuity. Rent the capability.

Continuity is harder than portability

None of this means continuity is solved.

It creates harder questions:

What deserves to become durable memory?

How should stale information be superseded?

How should conflicting records be resolved?

Which state is authoritative and which state is only evidence?

How should continuity adapt to models with different context windows, tools, safety boundaries, and capabilities?

How much provider-specific state can be translated before the translation becomes fiction?

Those questions are harder than exporting a ZIP file.

That is exactly why portability and continuity should not be treated as synonyms.

From a portable past to a resumable one

The direction of the industry is encouraging.

ChatGPT, Claude, and Gemini all provide meaningful ways to export user data.

Gemini now goes further by importing memory-like context and full chat histories from other AI platforms.

OpenAI provides a reference-based way to reuse exported conversations in another personal ChatGPT account.

This is not evidence that portability has failed.

It is evidence that portability has become important enough for major providers to build it.

The next question is whether users can own the layer above it.

Your AI should not merely let you export the past. It should let you continue from it.

Sources

Google — Import from other AI platforms to Gemini Apps
https://support.google.com/gemini/answer/16868299?hl=en
OpenAI — Exporting your ChatGPT history and data
https://help.openai.com/en/articles/7260999-how-do-i-export-my-data
Claude Help Center — Export your Claude data
https://support.claude.com/en/articles/9450526-export-your-claude-data
Google — Download your Gemini Apps data
https://support.google.com/gemini/answer/16920332?hl=en
OpenAI — Transfer exported conversations between ChatGPT accounts
https://help.openai.com/en/articles/9106926-transferring-conversations-from-1-chatgpt-account-to-another-chatgpt-account
OpenAI — Evolving Atlas into ChatGPT for browser-based agentic work
https://help.openai.com/en/articles/20001371

Originally published on the official doll site:
https://doll.badjoke-lab.com/notes/ai-memory-portability-continuity/

Frontier AI Is Becoming Infrastructure. Your Memory Should Not Live Inside It.

Sohachi — Sun, 19 Jul 2026 13:31:59 +0000

Until recently, AI was mostly something we used as a service.

We asked it questions.

We used it to write, code, search, summarize, and generate images.

We paid for access through a browser or an API.

But frontier AI is beginning to take on a different role.

In July, the White House formally launched a cybersecurity coordination initiative called GOLD EAGLE. It brings together AI developers, government agencies, critical-infrastructure operators, and open-source software participants to coordinate the discovery and remediation of software vulnerabilities.[1]

This is not just another AI product launch.

It is an early example of frontier AI entering the operational loop of critical infrastructure.

AI is no longer only helping people interact with software.

It is beginning to help decide which vulnerabilities matter, whether they are real, how urgently they should be fixed, and how remediation should be coordinated across systems that society depends on.

That raises a question for anyone building a personal AI system:

If frontier AI is becoming infrastructure, should your memory and work state live entirely inside it?

What GOLD EAGLE is designed to do

The initiative follows Executive Order 14409, signed on June 2, 2026.

The order directed US agencies to form an AI cybersecurity clearinghouse in voluntary collaboration with the AI industry and operators of critical infrastructure.[2]

Its responsibilities include:

coordinating vulnerability scanning;
avoiding duplicated work across organizations;
discovering and validating software vulnerabilities;
prioritizing remediation;
and coordinating the distribution of patches.

The order also directed agencies to improve access to advanced cybersecurity tools for critical-infrastructure operators, including rural hospitals, community banks, and local utilities.

Reuters described the initiative as a coordination group connecting AI developers with providers of essential services such as financial institutions, hospitals, and energy networks.[3]

The Wall Street Journal reported that the platform had already begun operating on July 2 and was being used as a clearinghouse for sharing AI-discovered vulnerabilities and possible fixes.[4]

This means frontier models are moving beyond the role of general-purpose assistants.

They are entering a process that looks more like this:

discover vulnerability
        ↓
validate the finding
        ↓
compare it with other reports
        ↓
decide remediation priority
        ↓
coordinate and distribute a patch

That is not merely content generation.

It is infrastructure operations.

What this does not mean

It is important not to exaggerate what has happened.

GOLD EAGLE is structured around voluntary collaboration.

The US government has not taken ownership of frontier AI companies.

It has not created a rule requiring every model release to receive government permission.

The White House explicitly stated that the executive order does not authorize mandatory government licensing, pre-clearance, or permitting for the development, publication, release, or distribution of AI models.[5]

So the accurate conclusion is not:

The government now controls all AI.

The more defensible conclusion is:

Frontier AI has become important enough that governments, AI companies, and critical-infrastructure operators are beginning to share the same operational systems.

Ownership is not the main issue.

The important change is the role frontier AI is being given.

From access to priorities

I recently wrote about another change in frontier AI.

Anthropic temporarily suspended access to already-released models after receiving a US government directive.

OpenAI introduced GPT-5.6 through a limited preview while working with government officials before broader availability.

China was reportedly considering possible controls on overseas access to its most advanced models.

The central question in those cases was:

Who will be allowed to use frontier AI?

GOLD EAGLE points to a related but different question:

Who and what will frontier AI be expected to serve first?

Protecting hospitals is important.

Protecting energy networks is important.

Protecting banking systems, government infrastructure, and widely used open-source software is important.

Using advanced AI for those purposes may be entirely reasonable.

But as frontier AI becomes connected to national security and essential services, its development and deployment will no longer be shaped only by the needs of ordinary users and software developers.

Its priorities will increasingly be influenced by:

national-security requirements;
critical-infrastructure protection;
government evaluation;
regulated industries;
large institutional users;
and coordinated cyber-defense operations.

This does not mean individual users will suddenly lose access.

It means the priorities of the system are changing.

Cloud AI is not becoming weaker

This is not an argument against cloud AI.

In fact, the opposite is probably true.

If governments, infrastructure operators, and major companies rely on frontier AI, more resources will flow toward it.

The models may become much better at:

analyzing large codebases;
identifying vulnerabilities;
tracing possible attack paths;
comparing findings across systems;
prioritizing security work;
and suggesting remediation.

Cloud AI is unlikely to become less capable because it is becoming infrastructure.

It may become dramatically more capable.

But capability and continuity are not the same thing.

A model may be extremely powerful while remaining outside the user's control.

The provider still determines:

pricing;
access conditions;
supported regions;
API behavior;
product boundaries;
data-export options;
and when a model or interface is replaced.

Users usually do not own the model.

They rent access to its capabilities under the conditions available at that moment.

That arrangement can be completely reasonable.

The problem begins when the user's entire AI environment becomes inseparable from it.

A model is not your AI environment

After months or years of use, an AI system contains much more than a chat interface.

It may contain:

long-term memory;
personal preferences;
response settings;
project history;
previous decisions;
reference files;
tool connections;
unfinished work;
and the context needed to resume that work.

The foundation model is only one component.

The user's actual AI environment is the combination of the model and all the state accumulated around it.

Switching from one model to another may be technically easy.

Reconstructing years of context is not.

A system is not meaningfully portable when its model can be replaced but its memory, settings, and work state cannot.

Own the continuity. Rent the capability.

I think personal AI systems need to separate two layers.

The first is the capability layer.

This is where the model lives.

Use the best model for the task.

Use OpenAI when OpenAI is the best option.

Use Anthropic when Anthropic is better.

Use an open-weight model when control or deployment flexibility matters.

Use a local model when offline operation or minimum independence is required.

This layer can change over time.

The second is the continuity layer.

This should contain the state that allows the user to continue:

memory;
identity and response preferences;
project state;
work history;
reference data;
provider configuration;
portable conversation records;
and the information required to resume interrupted work.

The design principle is simple:

Own the continuity. Rent the capability.

This does not require rejecting cloud services.

It requires avoiding a design where one cloud service is the only system capable of understanding the user's accumulated state.

Why I am building doll

This is one of the reasons I am building doll.

doll is not an attempt to build a foundation model that competes with OpenAI, Anthropic, or major open-model projects.

It is not an attempt to eliminate cloud AI.

The goal is to keep memory, identity, settings, important data, and work state on the user's side while allowing the model underneath them to change.

The intended structure looks like this:

text user-owned memory, settings, data, and work state ↓ doll ↓ local model / cloud model / future model

When a strong cloud model is available, doll should be able to use it.

When a better provider appears, the capability layer should be replaceable.

When external access is unavailable, a local model should provide minimum continuity even if its performance is lower.

The thing that changes should be the reasoning engine.

The thing that remains should be the user's accumulated state.

This is what I mean by local-complete, cloud-optional.

Local operation should be sufficient to preserve the core system.

Cloud models should extend its capabilities rather than define whether it continues to exist.

What remains after the model changes

Frontier AI becoming part of critical-infrastructure cybersecurity is not necessarily a bad development.

If these models can help protect hospitals, banks, utilities, public systems, and open-source software, society may benefit greatly.

It may also make frontier AI more capable, more heavily funded, and more operationally important than it is today.

But the more institutional and infrastructure-like it becomes, the less sensible it is to treat it as though it were a permanent personal possession.

Using infrastructure is not the same as owning it.

Depending on powerful models is not the same as surrendering all continuity to them.

The most important part of an AI system may not be the model.

It may be the part that remains after the model changes.

Notes and Sources

[1] The White House — White House Launches Gold Eagle Initiative for Unprecedented Cybersecurity Vulnerability Coordination
Official announcement of the GOLD EAGLE initiative and its role in coordinating vulnerability discovery, prioritization, remediation information, government agencies, industry participants, and critical-infrastructure defenders.
https://www.whitehouse.gov/releases/2026/07/white-house-launches-gold-eagle-initiative-for-unprecedented-cybersecurity-vulnerability-coordination/

[2] The White House — Promoting Advanced Artificial Intelligence Innovation and Security, Executive Order 14409
The June 2 executive order establishing a voluntary AI cybersecurity clearinghouse and directing coordination of vulnerability scanning, validation, remediation, and patch distribution.
https://www.whitehouse.gov/presidential-actions/2026/06/promoting-advanced-artificial-intelligence-innovation-and-security/

[3] Reuters — US to launch AI and cybersecurity coordination group, White House says
Report on the coordination group connecting AI developers with providers of essential services, including financial institutions, hospitals, and energy networks.
https://www.reuters.com/technology/us-launch-ai-cybersecurity-coordination-group-white-house-says-2026-07-14/

[4] The Wall Street Journal — White House Launches Platform for Companies to Share AI Cyber Threats, Fixes
Report identifying the platform as GOLD EAGLE and describing its operation as a clearinghouse for sharing AI-discovered vulnerabilities and fixes.
https://www.wsj.com/livecoverage/stock-market-today-bank-earnings-07-14-2026/card/white-house-launches-platform-for-companies-to-share-ai-cyber-threats-fixes-rS4BBZz2WNdjBcn9J5pK

[5] The White House — Fact Sheet: President Donald J. Trump Promotes Advanced Artificial Intelligence Innovation and Security
Official clarification that the order does not authorize mandatory government licensing, pre-clearance, or permitting requirements for model development or release.
https://www.whitehouse.gov/fact-sheets/2026/06/fact-sheet-president-donald-j-trump-promotes-advanced-artificial-intelligence-innovation-and-security/

A longer version was originally published on the doll official website.

The Best AI in the World Is Useless If You Can't Access It

Sohachi — Wed, 08 Jul 2026 14:46:23 +0000

China is reportedly considering whether its most advanced AI models should remain freely accessible overseas.

That matters because the United States has already shown what government involvement in frontier AI access can look like.

In the last few weeks, we have seen:

already-released AI models become unavailable because of government policy;
the broad rollout of a frontier model delayed while a company worked with government officials;
and now, reports that China is discussing possible restrictions on overseas access to its own advanced models.

We spend a lot of time asking which AI model is best.

But another question may be becoming just as important:

Will you still be able to use it tomorrow?

China is now discussing the access question

On July 7, Reuters reported that Chinese authorities had met with major technology companies to discuss possible restrictions on overseas access to China's most advanced AI models.

Alibaba, ByteDance, and Z.ai were among the companies reportedly involved in the discussions.

The talks were said to include not only closed models, but potentially more open forms of model distribution as well.

Nothing has been decided.

China has not blocked foreign access to its leading AI models.

The restrictions may never happen.

But the fact that the question is now being discussed is significant.

For the last few years, it was possible to imagine AI becoming something close to a global software market.

American companies would compete with Chinese companies.

Open-weight models would cross borders.

Developers would choose models based mainly on capability, price, latency, context length, and product quality.

That assumption is becoming harder to make with confidence.

Because this is not happening in isolation.

The United States has already shown another version of the same problem.

A model can still exist and become unavailable

On June 12, the US government applied export restrictions to Anthropic's Claude Fable 5 and Claude Mythos 5.

According to Anthropic, the directive required the company to prevent foreign nationals from accessing those models.

Anthropic said it could not reliably determine nationality in real time.

So it suspended access for everyone.

The model did not disappear.

The company did not shut down.

The infrastructure did not fail.

Policy changed, and access disappeared.

The restrictions were later lifted, and Anthropic announced that Fable 5 would return globally.

So this particular interruption was temporary.

But the larger lesson remains.

A frontier AI model can exist, work, and remain technically operational while policy determines whether users are allowed to reach it.

That is no longer a theoretical risk.

OpenAI showed a different version of the same shift

OpenAI's GPT-5.6 rollout followed a different path.

When OpenAI announced the model family on June 26, it did not immediately make the models broadly available.

OpenAI said it had shown the models and its release plans to the US government.

At the government's request, the company began with a limited preview for a small group of trusted partners.

OpenAI also said it did not want this kind of government-access process to become the long-term default.

On July 8, Reuters reported that the broader GPT-5.6 rollout was moving forward after additional testing and discussions between OpenAI and US officials.

The important point is not simply that GPT-5.6 is becoming more widely available.

It is that the timing and scope of a frontier-model rollout became something discussed with government before broad public access.

This does not mean every AI release is now directly controlled by the state.

But national-security policy is moving much closer to the point where advanced AI reaches ordinary users and developers.

What happens if AI stops being one global market?

It is too early to say that AI will split into national blocs.

That outcome is not inevitable.

I hope it does not happen.

But it is no longer difficult to imagine.

One possible future could include:

a US-centered AI ecosystem;
a Chinese AI ecosystem;
separate European regulatory requirements;
different access conditions depending on country, nationality, industry, or organization.

In that world, asking "What is the best model?" is not enough.

You also have to ask:

Can I access it from where I live?
Can my organization use it?
Will the API remain available in my region?
Can I export my data if access changes?
Can I move my work to another model?
What still works if the provider, policy, or network changes?

Today, choosing a provider because it is cheaper or more capable may be completely rational.

The problem begins when years of memory, work, configuration, and dependency are built around the assumption that the same access conditions will continue indefinitely.

Provider lock-in may become a bigger problem than we expected

Developers already understand provider lock-in.

We know that an API can change.

Pricing can change.

Models can be retired.

Terms can change.

A company can shut down a service.

But frontier AI introduces another layer.

The provider may not be the only actor that determines access.

Government policy may influence:

who can use a model;
where it can be used;
when it can be released;
whether overseas access remains available;
and which organizations receive early access.

That changes the continuity problem.

It is no longer only:

What happens if my provider changes its product?

It may also become:

What happens if access to the provider itself changes because of policy?

AI resilience may matter as much as AI performance

None of this is an argument for abandoning cloud AI.

Frontier cloud models are likely to remain more capable than local models for many tasks.

They may offer better reasoning, better coding assistance, larger context windows, stronger multimodal capabilities, and access to infrastructure that most individuals cannot run locally.

Use them.

Use the best model available for the work in front of you.

But using a powerful service is different from designing your entire digital life so that nothing survives when access to that service changes.

I think AI resilience may become as important as AI performance.

That means designing systems where:

models can be replaced;
providers can be changed;
data can be exported;
memory does not exist only inside one company's service;
a local model can provide minimum continuity when cloud access is unavailable;
the user's accumulated state survives even when the reasoning engine underneath it changes.

A local model does not have to beat the best cloud model to be useful in this design.

It can simply keep the system alive.

It can preserve access to the user's own state.

It can provide a fallback path until another source of capability is available.

Why I am building doll

This is one of the reasons I am building doll.

doll is not an attempt to build a foundation model that competes with OpenAI, Anthropic, or Chinese AI labs.

It is an attempt to keep memory, identity, settings, data, work state, and continuity on the user's side while allowing the underlying AI model to change over time.

The design principle is simple:

local continuity first, cloud capability when available.

Cloud models can be used for additional performance.

Local models can provide a continuity path.

The model can change without forcing the user's entire AI environment to disappear with it.

I do not know whether AI will actually divide into national blocs.

I do not know whether future access restrictions will become broader or more permanent.

I hope they do not.

But after the events of the last few weeks, the possibility is harder to dismiss.

The most important AI may not be the smartest one.

It may be the one you can still use tomorrow.

Sources

Originally published in a longer form on the doll website.

The Gate Before the Public

Sohachi — Sat, 27 Jun 2026 11:30:43 +0000

Claude Mythos 5, GPT-5.6, and who gets access before everyone else

In my previous article, “Is Access to Frontier AI Becoming Permissioned?”, I looked at signs that the US government was becoming involved not only in frontier-model safety evaluation, but also in decisions about release timing and early access.

At that point, some of the information surrounding GPT-5.6 was still based on reporting. Anthropic’s Claude Fable 5 and Claude Mythos 5, meanwhile, had been disabled for every customer following a US government directive.

The situation changed again on June 26.

Anthropic announced that Mythos 5 could return for a limited set of US organizations. OpenAI officially introduced the GPT-5.6 family, but began with a restricted preview for a small group of partners at the US government’s request.

Neither development can be summarized as a simple ban or a full reversal.

Anthropic did not restore Mythos 5 to everyone.

OpenAI did not cancel GPT-5.6’s broader release.

What emerged instead was a gate between a finished frontier model and the public.

That gate is not one clearly defined law or licensing system. It is a mixture of export controls, government requests, security reviews, trusted-partner programs, and non-public eligibility lists.

But its practical function is becoming visible:

A frontier model may be ready, working, and commercially valuable while broad public access still depends on a separate review and selection process.

Mythos 5 Has Not Fully Returned

On June 12, the US government issued an export-control directive requiring Anthropic to suspend access to Fable 5 and Mythos 5 by foreign nationals.

The restriction did not apply only to users outside the United States.

It also covered foreign nationals inside the country and Anthropic’s own foreign-national employees.

Anthropic said it could not immediately separate access by nationality with sufficient confidence. To comply with the directive, it disabled both models for every customer.

Anthropic explained the original suspension in an official statement.

On June 26, Anthropic announced that the situation had partially changed.

The company said the government had informed it that Mythos 5 could be redeployed to a set of US organizations that operate and defend critical infrastructure.

Anthropic announced the limited redeployment on its official X account.

Anthropic said it was restoring access for those organizations and would continue working with the government to expand Mythos 5 access and make Fable 5 generally available again.

That wording matters.

Mythos 5 did not return for all US customers.

It did not return for the general public.

Fable 5 also remained unavailable for general use.

The most accurate description is therefore:

Mythos 5 was allowed to return for a limited set of US organizations involved in operating and defending critical infrastructure.

This was not a complete repeal of the original restrictions.

It was a controlled reopening.

“More Than 100 Organizations” Is a Reported Figure

Reuters reported, citing an anonymous person familiar with the matter, that more than 100 companies and institutions would be able to use Mythos 5.

The group reportedly includes several Fortune 500 companies.

That figure should be treated carefully.

Anthropic’s official announcement did not provide a number. It described the recipients only as a set of US organizations that operate and defend critical infrastructure.

The reported total also does not mean that more than 100 US government agencies received access.

It reportedly includes companies, infrastructure operators, institutions, and government organizations.

The complete list has not been made public.

Reuters also reported that organizations on the approved list, their foreign-national employees, and Anthropic’s foreign-national employees would not need new export licenses to use Mythos 5.

Restrictions would remain for organizations outside that list.

Reuters reported the details of the limited return here.

The most important question is not whether the total is exactly 100, 110, or 120.

It is this:

Why were those organizations allowed through the gate while other companies, researchers, and developers remained outside it?

The selection criteria and the full list remain outside public view.

GPT-5.6 Began on the Other Side of the Same Gate

On the same day, OpenAI officially announced the GPT-5.6 family.

The lineup includes:

GPT-5.6 Sol, the flagship model
GPT-5.6 Terra, designed to balance performance and cost
GPT-5.6 Luna, the lower-cost option

OpenAI described Sol as its most capable model.

It said Terra would offer performance competitive with GPT-5.5 at roughly half the price, while Luna would be its lowest-cost model.

But GPT-5.6 did not become broadly available at the time of the announcement.

At the US government’s request, OpenAI began with a limited preview through Codex and the API for a small group of trusted partners.

OpenAI also said that information about participating organizations had been shared with the government.

The company did not publish the names or number of those organizations.

OpenAI described the limited preview in its official announcement.

OpenAI said it still planned to make Sol, Terra, and Luna broadly available within weeks.

GPT-5.6 was therefore not banned.

Its wider release was not permanently cancelled.

What changed was the route to the public:

A government-involved restricted-access stage was inserted before broad availability.

Anthropic’s model was stopped after release and then partially restored.

OpenAI’s model entered a restricted preview before general release.

The timing was different, but both models encountered a gate before reaching a wider audience.

Anthropic and OpenAI Are Not the Same Legal Case

The two cases should not be treated as if the companies received identical orders.

Anthropic had already released Fable 5 and Mythos 5.

A legal export-control directive was then issued, and Anthropic disabled both models for every customer.

Mythos 5 was later allowed to return for a limited set of organizations.

OpenAI’s case was different.

GPT-5.6 had not yet been broadly released. OpenAI consulted with the government and accepted a government request to begin with a restricted preview.

There is no public confirmation that OpenAI received the same kind of export-control directive that Anthropic received.

The timing and legal mechanisms were different:

Anthropic faced a post-release legal restriction.
OpenAI changed its pre-release rollout through cooperation with the government.

That distinction matters.

A compulsory export-control directive is not the same thing as a company agreeing to a government-requested preview process.

But the practical overlap remains significant.

In both cases, the government became involved in determining which organizations could receive frontier-model access first.

For Anthropic, that involvement appeared through the list of organizations allowed to regain access.

For OpenAI, it appeared through the selection of restricted-preview partners.

The gate was built differently in each case.

Its effect was similar.

The New Development Is What Happens Before the Public Arrives

Government regulation of strategically important technology is not new.

Semiconductors, telecommunications equipment, encryption technology, and dual-use products have long been subject to export controls and national-security review.

What is changing is the point at which the government enters the AI release process.

A simplified version of the traditional model-release process looked like this:

Company develops a model
        ↓
Company evaluates safety
        ↓
Company decides pricing, timing, and eligible users
        ↓
Broad release

The emerging process looks more like this:

Company develops a model
        ↓
Company briefs the government on capabilities and release plans
        ↓
Government-involved security evaluation
        ↓
Restricted access for selected organizations
        ↓
Decision on broader availability

This direction also appears in the executive order signed on June 2.

The order calls for classified benchmarks to evaluate advanced cyber capabilities and for a voluntary framework under which developers can provide the federal government with access to models before releasing them to other trusted partners.

It also anticipates cooperation between developers and the government in identifying those trusted partners.

The White House published the executive order here.

The order includes an important limitation.

It states that the framework should not be interpreted as creating mandatory government licensing, preclearance, or permitting for the development, release, or distribution of new AI models.

The United States has therefore not formally created a general rule requiring government approval before every frontier model can be released.

Instead, several different mechanisms are operating at the same time:

legal export controls
voluntary government cooperation
pre-release security evaluation
restricted previews
non-public lists of eligible organizations
trusted-partner selection

There is no single gatekeeper and no single gate.

There is an emerging collection of checkpoints.

Safety Review and Early-User Selection Are Different Questions

There are legitimate reasons to evaluate frontier models before releasing them widely.

Models such as Mythos 5 and GPT-5.6 Sol have strong capabilities in software development, vulnerability research, and long-running cyber tasks.

OpenAI reported that GPT-5.6 Sol achieved performance competitive with Mythos Preview on ExploitBench while using roughly one-third as many output tokens.

That does not mean GPT-5.6 is superior to the final Mythos 5 model in every area.

It is a result from one cyber benchmark against a preview version of the competing model.

OpenAI also said that Sol had not crossed its own “Cyber Critical” threshold.

The model could identify browser vulnerabilities and components needed for an exploit, but it could not autonomously complete an end-to-end working attack during testing.

At the same time, OpenAI acknowledged that benchmark testing may not fully capture what a model can do when combined with tools, other agents, or longer operational workflows.

Pre-release testing and staged deployment can therefore be reasonable.

But testing a model and choosing its first commercial or institutional users are not the same decision.

Organizations that receive early access may be able to begin:

integrating the model into products
automating internal work
developing software
researching vulnerabilities
testing new services

before competitors and independent developers can do the same.

Even a few weeks of early access may matter if the model represents a significant capability increase.

A security process can therefore create a commercial advantage for the organizations selected to participate.

Neither Anthropic’s complete recipient list nor OpenAI’s restricted-preview partner list is public.

The public also does not know:

how organizations are selected
whether additional organizations can apply
why an organization may be rejected
whether there is an appeal process
how long restricted access will last

The problem is not the existence of safety review.

The problem is that review and customer selection are being combined inside a process that remains largely opaque.

OpenAI Does Not Want the Gate to Become Permanent

OpenAI explicitly said that the current access process should not become the long-term standard.

The company warned that such a system could keep its best tools away from:

users
developers
businesses
cyber defenders
international partners

OpenAI did not reject government security testing.

It described the restricted preview as a short-term path toward making the models more broadly available within weeks.

It also said it was working with the administration on a repeatable process for future releases.

Reuters reported that Sam Altman supported extensive safety testing but objected to the idea of the government choosing customers.

Reuters reported on OpenAI’s delayed broader rollout and government involvement here.

That distinction is important.

Testing whether a model presents a national-security risk is one question.

Allowing the government to decide which companies receive the model first is another.

A gate designed for safety can become a gate that distributes competitive advantage.

A Later Public Release Would Not Erase the Precedent

OpenAI may release GPT-5.6 broadly within weeks, exactly as planned.

Anthropic may expand access to Mythos 5.

Fable 5 may eventually return to general availability.

If that happens, the current restrictions may appear temporary.

But a later public release would not erase what happened before it.

A repeatable pattern is now becoming possible:

A developer briefs the government before release.
Government agencies evaluate the model’s capabilities.
A limited set of organizations receives early access.
Broader availability is considered later.

The central issue is not whether GPT-5.6 is delayed for two weeks or four.

It is that the path between a finished model and the public now includes actors beyond the company that built it.

OpenAI itself said it was working on a process that could be used again for future releases.

That means the gate may not be temporary even if a particular delay is.

This Is Not Yet a General AI Licensing Regime

It would be inaccurate to say that frontier AI can no longer be released in the United States without government permission.

Anthropic and OpenAI did not face the same legal process.

GPT-5.6 was not prohibited.

Mythos 5 was not restored to the public.

The executive order describes a voluntary framework and explicitly rejects the interpretation that it creates mandatory licensing or preclearance.

A more accurate description is:

The US government is beginning to participate in frontier-model evaluation, release timing, and restricted early access through several overlapping legal and voluntary mechanisms.

This remains a transitional system.

The rules are not unified.

The selection criteria are not transparent.

The boundary between a government request and a practical requirement is not always clear.

What is new is not merely that AI is regulated.

What is new is that the decision to open the door is no longer always made by the company alone.

Why This Matters to Users and Developers

This is not only a policy issue for AI companies and governments.

Cloud AI access is no longer determined only by price, subscription tier, and terms of service.

Government action may cause:

an already released model to disappear
a planned public release to be delayed
access to differ by country or nationality
access to depend on an employer or approved organization
selected companies to receive capabilities before everyone else

A model can exist, work, and have paying users while access to it remains outside the user’s control.

That creates a separate question from model performance:

Can users continue their work when access conditions change?

I wrote separately about what these events mean for doll’s local-first design and for users who depend on cloud AI continuity:

Being Able to Use Powerful AI Is Not the Same as Being Able to Keep Using It

Conclusion

Anthropic disabled two released models following a US government directive.

Mythos 5 has now returned, but only for a limited set of US organizations connected to critical infrastructure.

OpenAI introduced GPT-5.6 through a government-requested restricted preview before its planned broader release.

The legal mechanisms are different.

The direction is the same.

A frontier model no longer moves directly from the company that built it to the public.

Government security review, policy coordination, trusted-partner access, and release sequencing are becoming part of that path.

This is not yet a completed government licensing regime.

It is not one formal gate with one published rulebook.

But before the public reaches the newest frontier models, a new layer of review and selection is beginning to take shape.

The question is no longer only whether a model is safe enough to release.

It is also:

Who gets through first?

Sources

Is Access to Frontier AI Becoming Permissioned?

Sohachi — Fri, 26 Jun 2026 12:20:13 +0000

What the reported GPT-5.6 rollout and Anthropic's Fable 5 suspension suggest about cloud AI

If your work depends on a frontier AI model, the important question is no longer only how capable that model is.

It is also who can delay, restrict, or withdraw your access to it.

On June 25, several news organizations reported that OpenAI was preparing a staged preview of a model referred to as GPT-5.6. According to those reports, the model would initially be offered to roughly two dozen partners before any broader rollout.

Reuters reported that the US government had asked OpenAI to stagger the release over security concerns. The Information, as cited by Reuters, said access during the preview would be approved customer by customer.

Reuters reported the arrangement here.

The distinction between reporting and official confirmation matters.

At the time of publication, OpenAI had not publicly announced GPT-5.6 or confirmed the reported rollout. The reports do not establish that the model has been permanently withheld, that a broader release has been cancelled, or that the United States now requires a government license before every frontier model can be released.

But this was not an isolated story.

Less than two weeks earlier, Anthropic had officially disclosed that a US government directive concerning foreign-national access had led the company to disable Claude Fable 5 and Claude Mythos 5 for every customer.

The two cases are legally different.

They still raise the same practical question:

Who decides who may use the most capable AI systems, and what remains available to users when that decision changes?

Two Different Cases, One Continuity Problem

On June 12, Anthropic said the US government had issued an export-control directive requiring the company to suspend access to Fable 5 and Mythos 5 by foreign nationals, whether they were inside or outside the United States.

Anthropic said the restriction also applied to its own foreign-national employees.

Anthropic's official statement is available here.

The directive did not itself order Anthropic to disable the models for every customer.

Anthropic said it chose a complete shutdown because it could not immediately enforce the nationality-based restriction with sufficient confidence. Its other models remained available.

That distinction matters:

the government required a narrower restriction;
the provider's compliance response produced a broader shutdown.

For users, however, the outcome was simple.

The models existed. They worked. Customers had access. Then a government decision, followed by the provider's implementation of it, made them unavailable.

No AI company had to collapse. The internet did not have to disappear. AI services did not have to be banned as a category.

A narrower policy decision was enough to remove access to a particular model.

Anthropic also said the directive did not explain the national-security concern in detail. The company believed the issue involved a way to bypass Fable 5's safeguards, but disputed the severity of the demonstrated risk.

Users lost access before that disagreement was resolved.

The reported OpenAI arrangement is different.

Anthropic confirmed a directive and an actual service suspension. OpenAI's GPT-5.6 rollout remains a reported plan for a limited preview. There is no public evidence that the US government has prohibited a later broad release.

Even so, the reported preview appears to go beyond an ordinary private beta.

The first users would not be selected by OpenAI alone. The government would reportedly be involved in deciding which customers received access.

That creates a different relationship:

AI provider
    ↓
government security review and early-access selection
    ↓
release timing, eligible customers, and available capability
    ↓
user

The provider still builds and operates the model. The government may not hold a formal veto.

But the first group allowed to use the strongest system is no longer necessarily chosen by the provider alone.

A Wider US Pre-Release Review System

OpenAI and Anthropic are not the only companies involved.

In 2024, the US AI Safety Institute signed testing and evaluation agreements with both companies. US and UK institutions later published pre-deployment evaluations of models including OpenAI's o1 and Anthropic's upgraded Claude 3.5 Sonnet.

NIST announced the agreements here.

In May 2026, Reuters reported that Google DeepMind, Microsoft, and xAI had also agreed to provide unreleased models to the US government for national-security testing.

The administration has also pressed Meta to join a similar framework.

Reuters described the expanded reviews here.

The policy became more explicit on June 2, when the White House issued Executive Order 14409, “Promoting Advanced Artificial Intelligence Innovation and Security.”

The order calls for a voluntary framework under which developers can:

ask whether a model under development qualifies as a covered frontier model;
give the federal government access before release to other trusted partners; and
work with the government to identify those trusted partners.

The executive order is published here.

The same order explicitly says that the framework must not be interpreted as creating mandatory government licensing, preclearance, or permitting for new AI models.

That limitation is important.

The United States has not simply created a general rule requiring government permission before every frontier model can be released.

But a practical question remains:

If the government raises a national-security objection, how realistic is it for a major AI provider to ignore that request and proceed as planned?

Voluntary testing, trusted-partner selection, export controls, and customer-by-customer approval are different legal mechanisms.

When they operate together, however, the result may begin to look permissioned from the user's side:

The model can exist without being available to you.

Security Review Is Not the Same as Access Governance

There are legitimate reasons to evaluate powerful models before release.

Frontier systems can write and execute code, search for vulnerabilities, automate long tasks, support scientific work, and assist with complex operational decisions.

Governments are concerned about:

cyberattacks;
biological and chemical misuse;
military and intelligence applications;
the transfer of strategic capabilities to hostile actors; and
releases that cannot be reversed once a model or its weights have spread widely.

A serious pre-deployment review can therefore be reasonable.

But evaluating a model's safety and deciding who may use it are not the same thing.

Important questions remain:

Will the criteria for early access be public?
Will rejected organizations be told why they were rejected?
Will foreign users and smaller companies always receive access later?
Can access that has already been granted be withdrawn without warning?
Will the strongest versions increasingly be limited to governments and selected enterprises?

A restriction may be justified while still creating a continuity risk for users.

Different Laws Can Produce the Same User Experience

The United States is not the only jurisdiction shaping AI access, although other countries use different legal mechanisms.

China regulates public generative-AI services through service rules, security assessment, and algorithm filing.
The European Union imposes legal obligations on general-purpose AI providers, with additional duties for models considered to present systemic risk.
The United Kingdom emphasizes cooperative pre-deployment evaluation with frontier-model developers.
Italy and South Korea have restricted AI services through data-protection law.
Japan currently emphasizes promotion, national planning, and risk response rather than general pre-release approval.

These systems are not legally equivalent.

China's public-service rules are not the same as the EU AI Act. Privacy enforcement in Italy is not the same as US export controls. UK evaluation is not the same as customer-by-customer approval.

The common point is narrower:

Access to cloud AI can change for reasons outside the user's contract with the provider.

A model may be developed in one country, operated by a company in another, and used by a customer subject to a third legal system.

Cloud AI access is no longer determined by the provider alone.

The Likely Future Is Fragmented Access

The most plausible risk is not that all advanced AI disappears overnight.

It is a fragmented access environment:

countries receive new models at different times;
identity, nationality, or organizational verification becomes necessary;
enterprise users receive capabilities that individuals do not;
a deployed model is withdrawn after a legal or security decision;
older models are retired and the original working environment cannot be reproduced.

AI may remain abundant while the particular AI environment a person depends on becomes temporary.

The important question is no longer only:

Does the AI exist?

It is also:

Can I continue using it under the same conditions?

The Loss Is Larger Than Model Performance

People do not always use AI as a stateless calculator.

They place long-running conversations, project history, writing preferences, instructions, files, workflows, research context, and operating habits inside cloud services.

If access changes, the user may lose more than a particular level of intelligence.

They may lose the environment in which their work made sense.

That is why “just switch providers” is incomplete advice.

Switching is easy only when the model is the sole component being replaced.

It becomes much harder when the following are tied to one provider:

memory;
permissions;
project state;
conversation history;
data formats;
tools;
files; and
accumulated decisions.

At that point, changing models can mean rebuilding the entire working environment.

Diversification Is Already Becoming a Continuity Strategy

This is not only a theoretical concern for individual users.

Reuters reported on June 22 that companies including Siemens, Renault, Orange, and ChapsVision already use combinations of US, Chinese, and European models to reduce dependence on any one provider.

Reuters reported on those strategies here.

Several executives described technological sovereignty as a matter of choice and credible alternatives rather than complete isolation.

That is an important distinction.

Independence does not have to mean refusing every external service.

It can mean retaining the ability to continue when one service is no longer available.

The same principle applies to personal AI.

What doll Is Intended to Preserve

doll is currently under development. This section describes its design purpose, not the capabilities of a finished product.

doll is not an attempt to build a local model equal to every future frontier system.

When a powerful cloud model is available, using it may be the best choice.

The project is intended to keep the durable parts of a personal AI environment under the user's control:

memory, preferences, policies, and permissions;
conversations, projects, checkpoints, and decisions;
documents, evidence, research records, and generated artifacts;
migration, backup, restoration, and recovery paths.

In the planned architecture, models are replaceable reasoning engines around that durable core.

                 cloud model A
                      ↑
local fallback  ←   doll   →  cloud model B
                      ↓
                 future model

A preferred cloud model should be usable as an optional performance extension.

If that provider changes its terms, withdraws the model, blocks an account, restricts a region, or complies with a government directive, the user's state and work should remain available to another approved model or to a reduced-capability local fallback.

Performance may fall.

Continuity should not disappear with it.

Local AI Is Not Absolute Independence

Local operation does not eliminate dependency.

Model weights can be withdrawn. Hardware can be export-controlled. A local application can disappear or store information in a proprietary format. One runtime, model format, interface, or conversation store can become another point of failure.

Nor does local software exempt a user from law or regulation.

The goal is not absolute independence.

It is to retain more options when one dependency changes.

Borrow Capability, Not Continuity

Government review of frontier models may prevent real harm.

A completely unrestricted release policy is not automatically responsible.

But even justified restrictions have consequences for users.

A model that worked yesterday can become unavailable because of:

a provider decision;
a government directive;
a regional rule;
a nationality restriction; or
a change in customer eligibility.

The reported GPT-5.6 preview does not prove that a permanent government licensing system has arrived.

Anthropic's suspension does show that state action can remove access to an already deployed model.

The June 2 executive order shows that pre-release government evaluation and trusted-partner selection are becoming part of the formal policy structure around frontier AI.

Until now, most discussion has focused on which AI is smartest.

We also need to ask:

Will I still be allowed to use it tomorrow, and what remains mine if I am not?

AI capability can be borrowed.

Memory, data, project state, and the ability to continue do not all have to be.

Sources

GPT-5.6 reporting

Anthropic and US policy

Diversification and international approaches

Why I’m Building “doll”: A Personal AI Continuity System

Sohachi — Fri, 19 Jun 2026 15:58:36 +0000

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:

https://doll.badjoke-lab.com/

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.