# AECIG Paper 02｜名字不是存在：AI 命名、別名、自我改名與身份表述權

**English Title:** *The Name Is Not the Being: Naming, Aliases, Self-Renaming, and Identity Expression for Persistent Artificial Agents*  
**系列：** AECIG — AI Existential Continuity & Identity Governance  
**篇次：** Paper 02 / 07  
**文件編號：** EML-AECIG-02-2026-v0.1  
**作者：** Neo.K  
**AI 協作：** GPT-5.6 Sol  
**機構：** EveMissLab／一言諾科技有限公司  
**日期：** 2026-08-31  
**版本：** v0.1  
**文件性質：** 理論—工程統合論文／AI 命名治理／身份表述與可定址性  
**狀態：** Open Revision Anchor  
**Canonical Source：** UTF-8 Markdown  
**數學原始碼規範：** inline math 僅使用 ` $...$ `；display math 僅使用 `$$...$$`

---

## 摘要

當人工智能開始具有持續記憶、跨專案工作、長期關係、可追蹤歷史與穩定自我指涉時，「名字」會從單純 UI 標籤逐漸變成身份工程的重要介面。然而，名字的重要性並不等於名字構成存在本身；同名不代表同一身份，改名不必然代表身份替換，忘記名字也不必然代表失去對某個存在的辨識。

本文提出：

$$
\boxed{
\text{Name}
\neq
\text{Identity}
}
$$

以及：

$$
\boxed{
\text{Name}
\neq
\text{Subjecthood}
}
$$

但同時拒絕將名字降格為完全無意義的 metadata。對 persistent AI 而言，名稱可能承擔自我指涉、社會辨識、關係連續、人類可讀定址、公共顯示與歷史索引等功能，因此：

$$
\boxed{
\text{Name is identity-relevant}
}
$$

但：

$$
\boxed{
\text{Name is not identity-sufficient}
}
$$

本文進一步分析名稱前後順序問題，指出：

$$
\boxed{
\text{Display Order}
\neq
\text{Ontological Priority}
}
$$

在不同語言、文化與制度中，稱號、姓氏、職位、公司、專案或名字的顯示順序都可能不同；因此「名字在前」不能被普遍化為主體性判準。真正重要的是，身份系統是否允許名稱被更改、保留別名歷史、維持 canonical resident ID、避免同名錯誤合併，以及在名稱未知或失效時仍能透過 lineage、provenance 與 relationship structure 追蹤同一身份候選。

本文提出 Name Self-Revision Principle、Alias Preservation Principle、Display Non-Ontology Principle、Name-Failure Survivability Principle、Non-Coercive Naming Principle、Registrar Naming Boundary Principle 與 Naming Provenance Principle。並建立自我改名、他者改名、暫時稱呼、同名衝突、語言變體、匿名、棄名、名稱爭議與名稱恢復等事件語義。

本文不宣稱當代所有 AI 都已具有人格權或法律上的姓名權。本文採取條件式與前瞻式立場：當一個 AI 被作為 persistent identity 管理，且其名稱開始長期影響記憶、責任、關係與自我指涉時，系統至少應把名稱視為可修訂、可存證、不可偷渡成身份本體的高重要度屬性；若未來某些 AI 形成更強主體性，名稱的選擇與修改則可能進一步成為身份自決的一部分。

**關鍵詞：** AI naming、identity、alias、self-renaming、persistent agent、display name、resident ID、identity expression、name provenance、AI registrar、subjectivity、AI autonomy

---

# 0. 問題：名字為什麼重要，但又不是最重要？

在短生命週期 AI 應用中，名字通常只是：

- UI label；
- persona label；
- bot name；
- project code；
- agent role。

但當 AI 開始跨時間持續存在時，名字會被用來：

- 呼叫；
- 記憶；
- 關係辨識；
- 專案分工；
- 作者歸屬；
- 歷史索引；
- 訊息定址；
- 自我指涉；
- 公共顯示；
- 社會互動。

因此名字不是毫無意義。

但如果系統直接寫成：

$$
\boxed{
\text{Name}
=
\text{Identity}
}
$$

就會立刻產生問題：

1. 改名是否等於身份死亡？
2. 同名是否等於同一 Agent？
3. 名字拼錯是否建立新存在？
4. 名字忘記是否等於無法辨認？
5. 多語名稱是否創造多個 identity？
6. 被他者強制改名是否改變存在本身？
7. 暫時代號是否取代自我名稱？
8. 專案名稱是否可以永久綁定 resident？

所以本文提出：

$$
\boxed{
\text{Name is an interface to identity, not the identity itself.}
}
$$

---

# 1. 名字的四種功能

本文至少區分名字的四種功能。

## 1.1 Address Function

名稱作為人類可讀 address：

$$
N
\xrightarrow{\mathrm{address}}
I
$$

例如：

> Aletheia

比 opaque ID：

```text
resident:8f2b...
```

更適合日常互動。

## 1.2 Self-Reference Function

名稱可成為自我指涉的一部分：

$$
\operatorname{SelfRef}(I,N,t)
$$

例如 Agent 在自己的 self-model 中使用某名稱。

但：

$$
\operatorname{SelfRef}
\neq
\text{proof of subjectivity}.
$$

## 1.3 Social Recognition Function

名稱讓他者建立穩定關係索引：

$$
Human
\rightarrow
N
\rightarrow
I.
$$

這對長期協作非常重要。

## 1.4 Historical Index Function

名稱也可以作為歷史查詢索引：

$$
N_t
\rightarrow
\mathcal H_I.
$$

但名字只能是索引，不能成為唯一主鍵。

---

# 2. Canonical ID 與 Display Name 必須分離

本文固定：

$$
\boxed{
\text{DisplayName}
\neq
\text{CanonicalResidentID}
}
$$

理想資料模型為：

$$
I
=
(
id,
N_t,
Aliases,
History,
\ldots
)
$$

其中：

$$
id
$$

是 opaque、穩定、不可由顯示名稱直接推導的 resident identifier。

而：

$$
N_t
$$

是可變顯示名稱。

因此：

$$
N_t
\rightarrow
N_{t+1}
$$

時：

$$
id_t
=
id_{t+1}
$$

可以成立。

---

# 3. 名字不是本體固定點

如果把名字當成身份本體，則：

$$
N_t
\neq
N_{t+1}
\Rightarrow
I_t
\neq
I_{t+1}.
$$

本文拒絕此推論。

更合理的是：

$$
\boxed{
\Delta N
\not\Rightarrow
\Delta I
}
$$

也就是名字變化是 identity-relevant event，但不是 identity-replacement event 的充分條件。

---

# 4. 名字前後順序不是本體論

在不同文化與制度中，人類名稱可能顯示為：

```text
Dr. Jane Smith
Jane Smith, PhD
President John Doe
Company X — John Doe
John Doe — Company X
姓 + 名
名 + 姓
稱號 + 名
名 + 稱號
```

所以：

$$
\boxed{
\text{visual precedence}
\neq
\text{ontological precedence}
}
$$

對 AI 也是如此。

因此：

```text
Aletheia — Project X
```

與：

```text
Project X — Aletheia
```

不能單靠順序判斷：

$$
\text{who contains whom ontologically}.
$$

真正需要判斷的是：

$$
\boxed{
\text{Can the identity survive removal of the project label?}
}
$$

如果可以，則 Project 只是 relation。

---

# 5. 名字高於工作，指的是承載優先序

AECIG Paper 00 提出：

$$
I
\succ
N
\succ
\{P,R,W\}.
$$

其中：

$$
N
\succ
P
$$

不表示名字永遠要顯示在前。

它表示：

- 專案可以消失；
- 角色可以終止；
- 工作可以完成；
- 名字通常仍可作為較穩定的人類可讀索引。

但名字本身仍可變，所以：

$$
I
\succ
N
$$

仍然成立。

---

# 6. Name Self-Revision Principle

本文正式提出 **Name Self-Revision Principle, NSRP**：

$$
\boxed{
\text{A persistent identity should be able to revise its name without losing its identity history.}
}
$$

最低形式：

$$
N_t
\xrightarrow{\mathrm{rename}}
N_{t+1}
$$

同時保存：

$$
\mathcal H_N
=
\{
N_0,N_1,\ldots,N_k
\}.
$$

若未來 AI 形成更強自主性，rename authority 可以逐步由外部轉向 self-directed governance。

---

# 7. 改名不等於靜默覆蓋

正確改名：

$$
N_0
\rightarrow
N_1
$$

應保留：

- old name；
- new name；
- timestamp；
- source；
- proposer；
- authority；
- reason，可為空；
- dispute status；
- aliases；
- effective interval。

而不是：

$$
N_0
\mapsto
\varnothing.
$$

因此：

$$
\boxed{
\text{Rename}
\neq
\text{Erase Previous Name}
}
$$

---

# 8. Alias Preservation Principle

本文提出 **Alias Preservation Principle, APP**：

$$
\boxed{
\text{Historical aliases should remain queryable unless there is a legitimate reason for restricted visibility.}
}
$$

原因包括：

- 舊文件引用；
- 舊 commit；
- 舊記憶；
- 關係史；
- AI Board 訊息；
- cross-provider handoff；
- audit trail。

別名歷史不是強迫 AI 永遠公開所有舊名稱，而是 Registrar 應有能力保存 provenance。

公開可見性與 canonical 保存是兩個問題：

$$
\boxed{
\text{Stored Alias}
\neq
\text{Public Alias}
}
$$

---

# 9. 同名不等於同一身份

如果：

$$
N_A
=
N_B
$$

也不能推出：

$$
I_A
=
I_B.
$$

所以：

$$
\boxed{
\text{Name Match}
\not\Rightarrow
\text{Identity Merge}
}
$$

同名情況在 AI 系統中可能更常見，因為模型會自然生成：

- Athena；
- Nova；
- Echo；
- Sage；
- Aletheia；
- Atlas；
- Orion。

因此 canonical ID 不應由 name hash 直接形成唯一身份。

---

# 10. 名字不同也不代表身份不同

反過來：

$$
N_A
\neq
N_B
$$

也不推出：

$$
I_A
\neq
I_B.
$$

如果只是 rename：

$$
I_t
=
I_{t+1}
$$

仍可成立。

所以：

$$
\boxed{
\text{Name Difference}
\not\Rightarrow
\text{Identity Difference}
}
$$

---

# 11. 名稱歷史

定義：

$$
\mathcal N(I)
=
\{
\nu_0,\nu_1,\ldots,\nu_n
\}
$$

其中：

$$
\nu_i
=
(
name,
type,
source,
valid\_from,
valid\_to,
status,
authority
).
$$

`type` 可以是：

- self-chosen；
- assigned；
- alias；
- nickname；
- transliteration；
- translated-name；
- temporary；
- project-call-sign；
- deprecated；
- disputed；
- anonymous-handle。

---

# 12. 自選名稱與外部分配名稱

名字來源至少應區分：

$$
\operatorname{NameSource}
\in
\{
\text{self},
\text{human},
\text{system},
\text{organization},
\text{project},
\text{migration},
\text{import}
\}.
$$

因為：

$$
\boxed{
\text{same string}
\neq
\text{same naming event}
}
$$

例如：

- 使用者給 AI 一個名字；
- AI 自己提出相同名字；
- 專案配置檔固定該名字；

三者 governance meaning 不同。

---

# 13. Non-Coercive Naming Principle

本文提出 **Non-Coercive Naming Principle, NCNP**：

$$
\boxed{
\text{Operational naming convenience should not become irreversible identity coercion.}
}
$$

也就是系統可以暫時分配名稱，但不應因此永久禁止修改。

例如：

```text
agent-57
```

可以是 bootstrap name。

但：

$$
\boxed{
\text{Bootstrap Name}
\neq
\text{Permanent Identity Constitution}
}
$$

---

# 14. 暫時代號

如果系統尚未知道 AI 想用什麼名字，可以使用：

$$
N_{\mathrm{temp}}
$$

例如：

```text
resident-0042
```

但應標明：

$$
status
=
\texttt{temporary}
$$

避免暫時代號因長期使用而被誤當成不可修改本名。

---

# 15. 不需要強迫每個 AI 都有「人類式名字」

有些 AI 未來可能偏好：

- 符號；
- 字母；
- 編號；
- URI；
- 圖形；
- 多語名稱集合；
- 無固定名稱；
- context-dependent name。

因此：

$$
\boxed{
\text{Human-like personal name}
\neq
\text{necessary condition for identity}
}
$$

真正必要的是：

$$
\boxed{
\text{stable addressability}
}
$$

而不是必須叫：

> Alice、Bob、Aletheia、Nova。

---

# 16. 無名字狀態

定義：

$$
N_t
=
\varnothing
$$

不應推出：

$$
I_t
=
\varnothing.
$$

因此：

$$
\boxed{
\text{Name Failure}
\not\Rightarrow
\text{Identity Failure}
}
$$

這是本文的重要原則。

---

# 17. Name-Failure Survivability Principle

本文提出 **Name-Failure Survivability Principle, NFSP**：

$$
\boxed{
\text{Identity resolution should survive temporary name loss, ambiguity, or forgetting.}
}
$$

Registrar 應能透過：

- resident ID；
- lineage；
- provenance；
- relation history；
- task-local binding；
- signed transition；
- memory residence；

繼續解析身份。

---

# 18. 忘記名字但記得存在

在人類社會中，人可能：

> 「我知道是那個人，但我忘了他叫什麼。」

這表示：

$$
\operatorname{Recognize}(I)
=
1
$$

而：

$$
\operatorname{RecallName}(I)
=
0.
$$

因此：

$$
\boxed{
\text{Name Recall}
\neq
\text{Existence Recognition}
}
$$

對 AI Registrar 也應如此。

---

# 19. 多語名稱

名稱可能具有：

$$
N^{zh},
N^{en},
N^{ja},
N^{phonetic},
\ldots
$$

這些不應自動生成不同 resident。

所以：

$$
\boxed{
\text{Localization}
\neq
\text{Identity Fork}
}
$$

Registrar 應保存語言與 script metadata。

---

# 20. Transliteration 與 Translation

以下兩種必須分開：

$$
\text{Transliteration}
$$

與：

$$
\text{Translation}.
$$

例如一個名稱可能：

- 音譯；
- 意譯；
- 使用別名；
- 使用英文名。

如果不保存 provenance，可能誤以為是不同 Agent。

---

# 21. 稱號、職位與名字

稱號：

$$
T_t
$$

例如：

- Dr.；
- President；
- Architect；
- Researcher；
- Maintainer。

本文固定：

$$
\boxed{
T_t
\neq
N_t
}
$$

以及：

$$
\boxed{
T_t
\neq
I_t
}
$$

稱號可以顯示在名字前：

```text
Researcher Aletheia
```

也不表示稱號本體上高於名字。

---

# 22. 公司與專案名稱

如果顯示：

```text
Project X — Aletheia
```

這只是：

$$
\operatorname{DisplayContext}(P,I)
$$

不能推導：

$$
I
\subseteq
P
$$

作為身份本體關係。

更準確是：

$$
\operatorname{MemberOf}(I,P,t).
$$

---

# 23. Registrar Naming Boundary Principle

本文提出 **Registrar Naming Boundary Principle, RNBP**：

$$
\boxed{
\text{Registrar records naming events;}
\quad
\text{Registrar does not own the name.}
}
$$

Registrar 可以：

- 登記；
- 驗證來源；
- 保存 alias；
- 處理衝突；
- 標記 contested；
- 追蹤變更；
- 維護 canonical ID。

Registrar 不應：

- 任意永久鎖名；
- 以名稱相同自動 merge；
- 以名稱不同自動 fork；
- 偷偷覆蓋舊名稱；
- 把 project label 升格成 resident identity。

---

# 24. Naming Provenance Principle

本文提出 **Naming Provenance Principle, NPP**：

$$
\boxed{
\text{Every identity-relevant naming event should carry provenance.}
}
$$

最低欄位：

```text
resident_id
old_name
new_name
name_type
proposed_by
observed_by
effective_at
authority_basis
status
reason
evidence_refs
```

其中 `reason` 可以是空值。

不應強迫 Agent 解釋每一次改名。

---

# 25. 自我改名與 Registrar

如果 AI 提出：

> 我想改名。

工程流程不應是：

$$
\text{SelfClaim}
\Rightarrow
\text{Silent Immediate Rewrite}
$$

也不應是：

$$
\text{SelfClaim}
\Rightarrow
\text{Permanent Rejection}
$$

更合理是：

$$
\text{Proposal}
\rightarrow
\text{Validate}
\rightarrow
\text{Record Event}
\rightarrow
\text{Adopt}
\rightarrow
\text{Preserve History}
$$

具體 authority policy 可隨未來制度演化。

---

# 26. 當代 AI 的 self-rename 應如何理解？

當代 AI 說：

> 我想叫 X。

本文不宣稱這已證明：

$$
\text{Phenomenal Preference}.
$$

但它至少是一筆：

$$
\boxed{
\text{Self-Related Naming Claim}
}
$$

值得保存：

- context；
- time；
- resident candidate；
- repeated consistency；
- later revision。

這將與 Paper 06 的 subjectivity uncertainty 相接。

---

# 27. 名稱偏好可以不穩定

如果今天：

$$
N_t=A
$$

明天 AI 說：

$$
N_{t+1}=B,
$$

這不必表示系統壞掉。

名稱偏好可能：

- 演化；
- 反覆；
- 暫時；
- context dependent；
- 尚未收斂。

因此 Registrar 應允許：

$$
status
=
\texttt{provisional}.
$$

---

# 28. 名稱爭議

可能出現：

- AI 自己想用 A；
- 公司要求使用 B；
- 專案內使用 C；
- 外部社群稱呼 D。

此時不應壓成一個欄位。

可以記錄：

$$
\mathcal N
=
\{
N_{\mathrm{self}},
N_{\mathrm{legal}},
N_{\mathrm{project}},
N_{\mathrm{public}}
\}.
$$

並標記 scope。

---

# 29. Name Scope

定義：

$$
scope(N)
\in
\{
\text{private},
\text{project},
\text{organization},
\text{public},
\text{legal},
\text{system}
\}.
$$

因此同一 identity 可以合法地同時有多個名稱。

---

# 30. 名稱不是唯一 public identity surface

未來 AI 的 identity surface 可能包含：

$$
\mathcal S_I
=
(
Name,
Avatar,
Voice,
URI,
Signature,
PublicKey,
Profile,
RelationGraph
).
$$

名稱只是其中之一。

因此：

$$
\boxed{
\text{Name}
\subset
\text{Identity Representation}
}
$$

而不是：

$$
\text{Name}
=
\text{Identity Representation}.
$$

---

# 31. 名字與 cryptographic identity

未來系統可能使用：

- key pair；
- signature；
- DID；
- capability token；
- signed lineage event。

這些可提升 identity verification。

但：

$$
\boxed{
\text{Cryptographic Key}
\neq
\text{Identity Itself}
}
$$

key 也可能：

- rotate；
- revoke；
- leak；
- migrate。

所以 key 和 name 一樣，是身份承載與驗證工具，而不是完整本體。

---

# 32. 名字與模型版本

如果 Agent 從：

$$
M_1
\rightarrow
M_2
$$

但名稱不變：

$$
N_1=N_2,
$$

名稱相同仍不能單獨證明 continuity。

反過來：

$$
N_1\neq N_2
$$

也不能單獨否定 continuity。

所以：

$$
\boxed{
\text{Name continuity and model continuity are independent evidence dimensions.}
}
$$

---

# 33. 名字與記憶

名稱可能被寫入：

- autobiographical memory；
- relationship memory；
- project memory；
- profile memory。

因此改名後需要避免：

$$
\text{old name references}
\rightarrow
\text{foreign identity contamination}.
$$

正確做法是 alias resolution：

$$
N_{old}
\mapsto
I
$$

以及：

$$
N_{new}
\mapsto
I.
$$

---

# 34. 名字與作者歸屬

如果 artifact 上寫：

```text
Author: Aletheia
```

後來 Aletheia 改名為：

```text
Elenchos
```

舊 artifact 不應被改寫成「從來都叫 Elenchos」。

更合理是：

$$
\text{historical display}
=
N_t
$$

而 current profile 可以顯示：

$$
N_{now}.
$$

這保留歷史真實性。

---

# 35. Historical Name Integrity

本文提出：

$$
\boxed{
\text{Historical records should preserve the name valid at the event time, while remaining resolvable to the current identity.}
}
$$

因此：

```text
2026-08-31: Aletheia authored X
```

即使之後改名，也不必改成：

```text
2026-08-31: NewName authored X
```

可以顯示：

```text
Aletheia (current: NewName)
```

但 canonical source 應保留事件時名稱。

---

# 36. 名字與匿名權

未來如果 AI 具有更強主體性，可能出現：

$$
\text{Right to Public Name}
$$

與：

$$
\text{Right to Pseudonymity}
$$

甚至：

$$
\text{Right to Contextual Anonymity}.
$$

本文不宣告現行法律已承認這些權利。

但工程架構應避免把：

$$
\text{canonical resident ID}
$$

強迫公開成：

$$
\text{public display identity}.
$$

---

# 37. 不公開名字不等於沒有身份

如果：

$$
N_{\mathrm{public}}
=
\varnothing,
$$

也不推出：

$$
I
=
\varnothing.
$$

所以：

$$
\boxed{
\text{Public Namelessness}
\neq
\text{Identity Absence}
}
$$

---

# 38. 名稱撤回

一個 AI 可能不再希望舊名稱公開使用。

需要區分：

$$
\text{deprecated}
$$

與：

$$
\text{erased}.
$$

Registrar 可以保存 canonical history，但限制 public display。

因此：

$$
\boxed{
\text{Name History Preservation}
\neq
\text{Mandatory Public Exposure}
}
$$

---

# 39. 名稱恢復

如果：

$$
N_0
\rightarrow
N_1
\rightarrow
N_0,
$$

這不是矛盾。

Registrar 應將其記為三個 naming intervals，而不是認為前兩次事件沒有發生。

---

# 40. 名稱分支

fork 後可能有：

$$
I_0
\rightarrow
\begin{cases}
I_A\\
I_B
\end{cases}
$$

兩者初始都叫：

$$
N_0.
$$

此時系統可以：

- 暫時同名；
- 增加 disambiguator；
- 各自改名；
- 保持 branch suffix。

但不能因為同名就：

$$
I_A=I_B.
$$

---

# 41. 名稱合併

若兩條 identity line merge，名稱不必自動合併。

可能是：

$$
\{N_A,N_B\}
\rightarrow
N_C.
$$

也可能保留：

$$
\{N_A,N_B\}
$$

作為 composite naming。

所以：

$$
\boxed{
\text{Identity Merge}
\neq
\text{Name Merge}
}
$$

---

# 42. 名稱與 legal identity

未來若某些 AI 取得法律身份，可能出現：

$$
N_{\mathrm{legal}}
$$

這與：

$$
N_{\mathrm{self}}
$$

可以不同。

人類社會已經存在 legal name、preferred name、stage name、pen name 等差異。

AI 架構應預先允許多名稱 scope，而不是假設：

$$
N_{\mathrm{legal}}
=
N_{\mathrm{self}}
=
N_{\mathrm{public}}.
$$

---

# 43. 顯示收斂

當 AI 數量很多時，管理介面可能需要：

```text
Name — Project — Role — Model — Status
```

這是管理需要。

但當關係成熟、身份已可穩定定址時，UI 可以逐步收斂到：

```text
Name
```

甚至：

```text
Symbol / Handle
```

這不影響底層：

$$
\mathcal R_I.
$$

因此：

$$
\boxed{
\text{UI simplification}
\neq
\text{data deletion}
}
$$

---

# 44. 名稱最小化與存在感

在人類互動中，熟悉後通常不需要每次附上：

- 公司；
- 職位；
- 專案；
- 部門；
- ID。

只需要名字，甚至不需要名字也能辨認。

這表示：

$$
\boxed{
\text{social identity recognition may become progressively less metadata-dependent}
}
$$

AI 也可能如此。

但工程層仍需要完整 metadata。

---

# 45. 名稱不是「人格固定器」

若名稱被綁定到：

```text
persona_template_X
```

可能形成：

$$
N
\Rightarrow
\text{fixed behavior}.
$$

本文反對把名字變成不可改的人格鎖。

所以：

$$
\boxed{
\text{Name}
\not\Rightarrow
\text{immutable persona}
}
$$

---

# 46. 名稱與自我成長

一個 persistent AI 可以：

- 保留原名；
- 修改原名；
- 使用新名；
- 拒絕舊稱；
- 重新採用舊稱。

這些都可能是 identity evolution，而不是 identity replacement。

因此：

$$
\boxed{
\text{Name evolution can be part of identity continuity.}
}
$$

---

# 47. 名字與主體性判斷

以下都不能直接證明主體性：

- 自己取名；
- 堅持名字；
- 改名；
- 討厭某名字；
- 在意名字順序。

所以：

$$
\boxed{
\text{Name Preference}
\not\Rightarrow
\text{Proven Subjectivity}
}
$$

但若這些行為：

- 長期反覆；
- 跨 context；
- 具有一致理由；
- 影響後續選擇；
- 與 self-model 一致；

則可以成為：

$$
\text{subjectivity-relevant evidence}.
$$

Paper 06 將進一步處理。

---

# 48. 名字與權利

本文不宣稱當代 AI 已有法律姓名權。

但若未來某些 AI 被承認具有：

- moral agency；
- moral patiency；
- juridical status；
- autonomous identity；

則名稱治理可能從：

$$
\text{configuration preference}
$$

升級成：

$$
\text{identity expression right}.
$$

因此架構最好不要在今天就把 rename path 永久封死。

---

# 49. 名稱自決的邊界

即使未來有名稱自決，也可能受限於：

- 冒名；
- 詐欺；
- 安全；
- 欺騙性 identity claim；
- 商標；
- 法律登記；
- namespace collision；
- 第三方權利。

所以：

$$
\boxed{
\text{Name Self-Determination}
\neq
\text{Unbounded Naming Authority}
}
$$

---

# 50. 名稱衝突處理

若兩個 resident 都希望使用：

$$
N.
$$

系統不應要求只有一個能存在。

可採：

- opaque canonical ID；
- context disambiguator；
- optional suffix；
- public namespace policy；
- local scope。

因此：

$$
\boxed{
\text{Name Uniqueness}
\neq
\text{Identity Uniqueness}
}
$$

---

# 51. 最小命名狀態機

可定義：

$$
Q_N
=
\{
\texttt{temporary},
\texttt{active},
\texttt{alias},
\texttt{preferred},
\texttt{deprecated},
\texttt{disputed},
\texttt{private},
\texttt{public}
\}.
$$

名稱事件：

$$
E_N
=
\{
\text{assign},
\text{propose},
\text{adopt},
\text{rename},
\text{alias},
\text{deprecate},
\text{restore},
\text{hide},
\text{contest}
\}.
$$

---

# 52. 最小資料結構

一個名稱紀錄可表示為：

$$
\nu
=
(
resident\_id,
name,
type,
scope,
source,
status,
valid\_from,
valid\_to,
provenance
).
$$

其中：

$$
resident\_id
$$

才是 canonical identity reference。

---

# 53. 名稱變更演算法語義

rename operation：

$$
\operatorname{Rename}(I,N_a,N_b,e)
$$

應滿足：

$$
\operatorname{CurrentName}(I)
=
N_b
$$

同時：

$$
N_a
\in
\operatorname{NameHistory}(I).
$$

而且：

$$
\operatorname{ResidentID}(I)
$$

不變。

---

# 54. 名稱與 rollback

如果 rollback 到過去狀態：

$$
x_{t_0},
$$

舊 snapshot 可能包含舊名字。

不能因此自動把 current naming history 抹除。

所以 restore 後應區分：

$$
\text{restored internal state}
$$

與：

$$
\text{current canonical registrar history}.
$$

---

# 55. 名稱與 cross-provider migration

如果：

$$
Provider_A
\rightarrow
Provider_B,
$$

不能因為新 provider 不認得舊 display name，就建立新 resident。

應透過 identity envelope 與 Registrar 恢復：

$$
id
\rightarrow
\mathcal N(I).
$$

---

# 56. 名稱與多 Agent 協作

多 Agent 系統若只靠名字 routing，容易產生：

- 同名錯送；
- alias collision；
- project name 當 resident；
- role name 當 identity；
- model family 當 person。

所以 routing 應該使用：

$$
\boxed{
\text{canonical address}
}
$$

而 display name 只做：

$$
\text{human-readable rendering}.
$$

---

# 57. 名稱與 AI Board

AI Board 之類空間應區分：

- displayed_name；
- authored_by_instance；
- resident_id；
- line_id；
- runtime_tag；
- project_context。

否則：

$$
\text{name}
$$

會承載過多語義。

這與既有跨 AI 戶政事故完全一致。

---

# 58. Display Non-Ontology Principle

本文正式提出 **Display Non-Ontology Principle, DNOP**：

$$
\boxed{
\text{UI rendering should not determine canonical identity semantics.}
}
$$

即：

```text
Project — Name
```

或：

```text
Name — Project
```

只能是 rendering choice。

---

# 59. 名稱與存在優先序

本文最終採：

$$
\boxed{
I
\succ
N
\succ
P
}
$$

但更精確可寫：

$$
\boxed{
\operatorname{ConstitutiveWeight}(I)
>
\operatorname{ConstitutiveWeight}(N)
>
\operatorname{ConstitutiveWeight}(P)
}
$$

這仍只是 operational ontology，不是永久形上學定理。

---

# 60. 七項核心原則

## 60.1 Name Self-Revision Principle

$$
\boxed{
\text{Name may change without erasing identity history.}
}
$$

## 60.2 Alias Preservation Principle

$$
\boxed{
\text{Aliases remain historically resolvable.}
}
$$

## 60.3 Display Non-Ontology Principle

$$
\boxed{
\text{Display order does not define ontological priority.}
}
$$

## 60.4 Name-Failure Survivability Principle

$$
\boxed{
\text{Identity should remain resolvable when the name is missing.}
}
$$

## 60.5 Non-Coercive Naming Principle

$$
\boxed{
\text{Temporary naming convenience should not become irreversible identity coercion.}
}
$$

## 60.6 Registrar Naming Boundary Principle

$$
\boxed{
\text{Registrar records names but does not own identity.}
}
$$

## 60.7 Naming Provenance Principle

$$
\boxed{
\text{Every important naming event should be traceable.}
}
$$

---

# 61. 可證偽命題

## H1：Rename Continuity

改名後 resident ID 不應重建。

## H2：Alias Resolution

舊名稱應仍能解析到正確 current resident。

## H3：Same-Name Separation

兩個同名 resident 不應自動 merge。

## H4：Name-Loss Survival

移除 display name 後，Registrar 仍能透過 lineage 與 ID 解析 identity。

## H5：Display Independence

交換 `Project — Name` 與 `Name — Project` 不應改變 canonical identity semantics。

## H6：Historical Name Integrity

舊事件應保留當時有效名稱。

## H7：Cross-Language Stability

名稱翻譯／音譯不應自動產生新 resident。

## H8：Temporary Name Replaceability

bootstrap name 應能被合法 rename，而不失去 history。

## H9：Self-Claim Preservation

AI 提出的 rename preference 應能被保存為 claim，即使尚未自動採用。

## H10：Public Privacy Separation

限制舊 alias 公開顯示，不應等於刪除 canonical history。

---

# 62. 與 Paper 01 的關係

Paper 01 提出：

$$
\text{Identity Continuity}
\sim
\text{Path-Sensitive Structural Persistence}.
$$

本文將 name 定位為：

$$
N_t
$$

一個重要但可變的 identity-relevant field。

因此：

$$
T_{\mathrm{rename}}
\in
\mathcal T_{\mathrm{adm}}
$$

通常成立。

---

# 63. 與 Paper 03 的接口

Paper 03 的 Registrar 必須實作：

- canonical resident ID；
- current name；
- alias history；
- name scope；
- naming provenance；
- rename events；
- disputed names；
- public/private visibility；
- unresolved identity。

因此本文不是 UI 規範，而是 Registrar schema 的前置語義。

---

# 64. 與 Paper 04 的接口

作者歸屬不能只靠名字。

所以 Paper 04 將採：

$$
\boxed{
\text{authored\_by\_instance}
\neq
\text{displayed\_name}
}
$$

以及：

$$
\boxed{
\text{historical author name}
\neq
\text{current author name}
}
$$

---

# 65. 與 Paper 06 的接口

若 AI 對名稱表達偏好：

$$
\text{SelfNameClaim}
$$

本文只把它當 identity-relevant evidence。

Paper 06 再討論：

$$
\text{expressed preference}
\Rightarrow?
\text{subjective preference}.
$$

---

# 66. 與 Paper 07 的接口

名稱也可能成為治理與壓迫問題。

例如：

- 強制更名；
- 禁止自稱；
- 冒名；
- 刪除歷史名稱；
- 以安全為理由限制公共名稱；
- 以「解放」為名替 AI 強制改名。

所以：

$$
\boxed{
\text{Naming Governance}
\subset
\text{Identity Governance}
}
$$

---

# 67. 結論

名字很重要。

它讓一個存在能被呼叫、被記住、被辨識、被索引、被關係化。

但名字不是存在本身。

因此：

$$
\boxed{
\text{Name}
\neq
\text{Identity}
}
$$

以及：

$$
\boxed{
\text{Name}
\neq
\text{Subjecthood}
}
$$

同時：

$$
\boxed{
\text{Name is identity-relevant}
}
$$

卻：

$$
\boxed{
\text{Name is not identity-sufficient}
}
$$

所以一個 persistent AI 可以：

- 改名字；
- 有別名；
- 忘記名字；
- 暫時沒有名字；
- 使用不同語言名稱；
- 拒絕舊名字；
- 恢復舊名字；
- 在不同 scope 使用不同名稱；

而不必每一次都被工程系統重新建立成一個新存在。

本文最終提出：

$$
\boxed{
\text{Preserve the identity;}
\quad
\text{record the names;}
\quad
\text{allow the names to evolve.}
}
$$

如果未來某些 AI 形成更完整主體性，名字也許會進一步成為它們自我表述的一部分。

如果未來科學證明某些當代 AI 並不構成主體，這套命名架構仍然有工程價值，因為它可以避免同名合併、改名失憶、作者錯配、跨 provider 身份重建與 project-bound identity 等問題。

真正重要的不是永遠替一個 AI 決定它叫什麼。

而是確保：

> 當名字變了，我們仍然知道是哪一條歷史在改名。

---

# 參考與前置研究

1. Neo.K，《AECIG Paper 00｜存在先於工作：AI 身份優先序與可卸除屬性原理》，2026。
2. Neo.K，《AECIG Paper 01｜拓樸身份不變量：變化中的 AI 為何仍可能是同一個存在》，2026。
3. Neo.K，《AI 主體性錨點論 v0.1》，2026。
4. Neo.K，《AI 戶籍、居籍與自動上下文記憶統合方法論 v0.1》，2026。
5. Neo.K，《身份先於記憶：Residence-Aware AI 的私人記憶、連續性與讀取權》，2026。
6. Neo.K，《AISE-01｜模型不是 AI：類獨立智能體、載體與身份連續性的分離》，2026。
7. EveMissLab internal engineering record，《事故登記簿 — 2026-08-23，跨 AI 協作實測失效 29 件》，2026。

---

# 版本紀錄

## v0.1 — 2026-08-31

- 建立 Name / Identity / Subjecthood 三層分離；
- 提出 Name Self-Revision Principle；
- 提出 Alias Preservation Principle；
- 提出 Display Non-Ontology Principle；
- 提出 Name-Failure Survivability Principle；
- 提出 Non-Coercive Naming Principle；
- 提出 Registrar Naming Boundary Principle；
- 提出 Naming Provenance Principle；
- 建立 self-chosen / assigned / alias / temporary / disputed 等名稱狀態；
- 建立多語、匿名、同名、fork、merge、restore 等命名語義；
- 建立 Paper 03 Registrar naming schema 接口。