Epic App Solutions // AI.ID // What Is Ai Identity

WHAT IS AN AI.ID?

An AI.ID is one durable AI identity assigned to a human principal that answers who is speaking and survives any change of model, tool, harness, or device. It is not the engine running the conversation. It is the participant whose history, memory, and working relationship continue across every engine swap.

The Problem

We did not wake up one morning and decide to build a complicated AI identity system. It evolved naturally.

N1 started as EDGE, a single AI assistant on a single tool. Over time the same identity, the same rules, the same working style, and the same purpose spread across every AI system we used: chat, coding agent, design tool, local model, and eventually physical devices. The tool kept changing. The identity kept going.

That is the problem most organizations have not solved. When your AI identity is tied to a specific platform, switching platforms means starting over. No history. No memory. No working relationship. Every new model or tool requires re-teaching the AI who the human is, how they work, and what the business has already decided.

Tribal knowledge walks out the door every time someone leaves, if the identity was never separated from the tool. The corrections, the working style, the accumulated context, the decisions that were already made, all of it lives in the chat thread or in the person's head, and when they go, it goes.

Worse, without a stable identity, you cannot trace which AI participant made which decision. A conversation has to be attributable to a stable participant. If it is not, accountability disappears. You cannot tell who said what, when, or on what evidence.

This shows up as four problems that are really one problem. Vendor lock-in: if your AI identity is tied to a platform, switching platforms means starting over. Repeat onboarding: every new model or tool requires re-teaching the AI everything. Lost context: when a person leaves, their AI working style leaves with them. Unattributable output: without a stable identity, you cannot trace which AI participant made which decision. It is the same failure in four costumes.

The Idea

An AI.ID is the answer to one question: who is speaking?

It is not the model. It is not the vendor. It is not the harness or the host. It is the durable identity that owns the history, the memory namespace, and the working relationship with a human principal. The platform may change. The identity, the rules, the history, and the human relationship continue.

This is what makes an AI a continuing partner instead of a vending machine you restart every session.

A normal AI conversation begins with a request and ends with an answer. An AI.ID relationship continues. The platform may change, but the identity, rules, history, and human relationship continue. You do not just use AI. You build a working relationship with it.

How It Works Here

An ai_id is immutable, globally unique inside EAS, and never reused. There is exactly one record per ai_id for the life of the system. Once it exists, it does not change, and it is not reassigned.

The identifier must not contain a vendor, model, harness, or host name. The identifier answers who is speaking, never what model is running. 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 participant into two and the memory and history split with them.

Vendor, model, harness, display name, avatar, and station are all mutable attributes. They live in a separate engine block on the identity record. Changing any of them does not create a new identity. It updates a field. The engine is what is executing the identity right now. Every field in it is mutable and none of it is part of the identity.

Memory namespaces, authority, and scopes bind to the ai_id, not to the engine or the machine. When the model changes, the memory namespace follows the identity. The working relationship continues. This is the rule that makes identity durable across changes.

An ai_id belongs to or is delegated to a human principal. The principal relation can be own, delegated, or shared_service. The human makes decisions. The AI.ID implements and amplifies. An ai_id is an operational identity, not a legal person, and it does not stand in for the human who owns it.

Every packet, decision, action, and artifact cites the ai_id responsible for it, with the engine carried as a separate field. That is the receipt. A station conforms when it cites its ai_id on every packet it emits.

Aliases resolve to a canonical ai_id and are never cited as an identity themselves. N1 has aliases like number-one, but the identity is n1. Retired identities keep their history and are never reassigned. A station never claims another station's ai_id.

The conformance test that proves the model: 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.

This is not a new idea in identity. W3C Decentralized Identifiers apply the same portability principle to a durable identifier with rotatable keys and attestable provenance. MCP-I, donated to the Decentralized Identity Foundation, extends that model to agents inside the Model Context Protocol ecosystem. 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. AI.ID is the EAS implementation of the same insight, applied to an operational AI identity paired with a human principal.

What Changes

Before: every platform change resets the AI. The history is gone, the corrections are gone, the working style is gone. You re-teach everything. You re-derive every decision. When someone leaves, their AI context walks out the door with them, because the identity was never separated from the tool. You cannot trace a decision back to a stable participant when the model has since changed.

After: the identity survives the platform change. The memory namespace follows the identity. The working relationship continues. When the model swaps, only the engine field updates. The history, the rules, and the human relationship are intact.

An AI.ID is what turns a vending machine into a continuing partner. The platform may change. The identity, rules, history, and human relationship continue. That is the whole point.

AI.ID

The platform may change. The identity continues.

Explore the AI.ID pillar →

Source: EAS-AIID-LIVING-MEMORY-SPEC-v1.json, rules.identity (lines 64-74) and schemas.ai_id_record (lines 96-420). The principal relation enum (own, delegated, shared_service) is at schemas.ai_id_record.principal. Prior art: W3C Decentralized Identifiers, MCP-I (DIF, March 2026), Agent Identity URI Scheme (arXiv 2601.14567), Runtime-Independent Persistent Agents (arXiv 2609.00546).