实体身份注册表

它解决什么问题

组织与人物的身份信息往往散落在结构化数据、第三方资料和 AI 识别结果中。如果缺少统一的事实层，团队很容易遇到三类工程问题：一是同名或近似实体被错误合并，二是无法回答“某条信息为何被采信”，三是叙述、声明与底层事实互相冲突。

Entity Registry 的价值在于提供一个机器可审计的实体身份权威层。它只负责记录机器视角的身份与认知事实，例如规范类型、别名、schema 类型、QID、sameAs、领域、消歧证据和观测状态；不负责品牌定位、消息体系、页面文案或声明审批。

它是如何工作的

核心机制是一条规范的 NDJSON 事件流，以及从事件流派生的可重建投影。memory/events/entities.ndjson 是唯一权威来源，memory/projections/entities.json 和 Markdown 视图都是可重建视图。所有变更都必须通过 scripts/registry-events.py 写入实体事件，并保留事件 ID、offset 和 revision。

处理实体时，技能会先将目标解析到唯一 aggregate ID。仅凭相似名称、logo、域名或描述，不能合并记录；需要经过验证的 cross-link，或用户明确确认。随后读取当前投影状态，并围绕六类信号做诊断：

• 结构化数据
• 知识库表现
• NAP+E 一致性
• 第一方内容
• 第三方佐证
• AI 识别状态

每条观测都要求记录来源、观测日期和证据类型。技能必须区分 Unknown 与 Partial；工具拒绝或某个引擎未观测到，应记为 Unknown，不能为了完整性推断成 Partial 或 Fail。

实体的变更采用事件协议与权限分层。普通技能只能提交 propose；接受、拒绝、canonical upsert 和状态 transition 必须由具备 host-capability 的 entity-registry principal 执行。memory 管理 principal 可以在明确授权下 tombstone 或 erase。写入前应先生成符合 registry-event.schema.json 的临时 JSON 请求，经运行环境追加后保留事件 ID 与 offset。

完成一轮处理后，执行 verify entities。验证通过的前提是六类信号都有 Pass/Partial/Fail/Unknown 级别的观测与证据，身份冲突已解决或明确留待处理，每个已接受变更都有事件 ID/offset/revision。若需要人工阅读，可以从已接受投影状态重新生成 memory/entities/.md，但该视图必须暴露 revision/offset，以及 Narrative 与 claims 依赖元组。

使用边界与注意点

这个技能不涵盖面向人类的 canon。定位、语气、命名、批准描述和声明背书分别属于 narrative-registry 与 offer-claims-registry。实体描述可以渲染 Narrative canon，但必须携带 narrative_canon_id、nevertheless_canon_version 和 claims_projection_offset，不能反向覆盖上游注册表。

Pageviews 与 mention 计数只能作为识别代理指标，不是权威评分。Wikipedia 页面不存在也不天然代表实体不合格，除非有可辩护的显著性标准。任何情况下都不能编造引用、显著性或来源。

处理自然人实体时，必须先确认适用的法律依据，最小化字段，使用假名 aggregate ID，并避免将原始邮箱、电话、住址或凭据写入事件。被 erase 或 tombstone 的实体，在用户明确授权新记录前不能从陈旧笔记中重建。以上是操作指引，不是法律建议。

不要手工编辑 memory/events/entities.ndjson 或 memory/projections/entities.json，也不要直接把 canonical facts 写入 HOT memory。缺失目标身份、未验证合并、自然人记录缺少合法依据、Narrative/claims 实质冲突，或缺少写权限时，应停止推进。