If your AI's name is gpt-5-assistant, switching to Claude means creating a new entity with no history. Your memory, your corrections, and your working relationship are gone. You start over.
It gets worse. When the identifier carries the model, changing models forks the memory namespace. The organization now has two partial histories that cannot be reconciled. Decisions made under the old name cannot be traced to the new one. Accountability is lost, because the participant you were tracing no longer exists.
Every platform change requires re-teaching the AI everything: who the human is, what was decided, what mistakes were made. The identity reset with the model, so the working relationship reset too.
This is vendor lock-in expressed as identity. The model is baked into the name, so the name breaks when the model changes. You are not locked into the vendor by contract. You are locked in by the fact that leaving means losing your own history.
The identifier must not contain a vendor, model, harness, or host name.
The lowercase slug n1 is correct. A compound like n1codex is a violation, because the moment the engine changes from codex to something else, that identifier forks one identity into two. The memory and history split with it.
The engine block (vendor, model, harness, and the timestamp of the current engine) is entirely mutable and none of it is part of the identity. Swapping any of it does not create a new ai_id. It updates a field.
The memory namespace survives every engine change because it is bound to the ai_id, not to the engine. When the model changes, the memory namespace follows the identity.
The engine field has four mutable sub-fields: vendor (for example, openai or anthropic), model (for example, gpt-5.2 or claude-opus-5), harness (for example, codex or devin-cli), and since (the timestamp of the current engine). All of them are mutable. None of them is part of the identity.
This is not hypothetical. The spec's own example shows n1 running on openai/gpt-5.2. The editorial standards for this project show n1 running on anthropic/claude-opus-5. Same ai_id. Same memory namespace. Different engine. The identity continued. Only the engine field updated.
Changing the engine is a routine field update. It does not require a migration or an approval process. It is not the same thing as replacing one ai_id with another ai_id, which is an identity migration. An identity migration is recorded, approved, and uses the supersedes field to link the old identity to the new one. An engine change is just an engine change. The conformance test treats an engine change as something a station must survive unchanged.
The conformance test that proves it: move an ai_id to another engine and another station operating system, then replay a packet. Same identity cited. Same memory namespace reached. Same answers returned. If anything differs, an identifier is carrying a mutable attribute somewhere.
Key rotation preserves the historical chain. Rotating the signing key does not create a new identity, for the same reason that rotating the model does not. The signing key and the packet identity must resolve unambiguously to one canonical ai_id. Key rotation preserves the historical chain; it does not break it.
This is not a new idea. The Agent Identity URI Scheme independently reaches the same core rule: an identifier that embeds a mutable attribute breaks identity when that attribute changes. Runtime-Independent Persistent Agents describes one identity retained across models, harnesses, and servers. W3C Decentralized Identifiers are designed to be durable and portable with rotatable keys. MCP-I extends the W3C identity model to agents in the MCP ecosystem, making the same separation between identity and runtime that AI.ID enforces. AI.ID applies the same principle: rotating the key, or the model, preserves the historical chain and the identity.
Before: every platform change resets the AI. The identifier forks. The memory splits. The history is lost. You re-teach everything, and you cannot trace a decision back to a stable participant when the model has since changed. Vendor lock-in is baked into the name.
After: swap the engine. The ai_id is unchanged. The memory namespace is unchanged. The history is intact. The working relationship continues. The platform may change. The identity, rules, history, and human relationship continue. You are not locked in by your own identity.