Project brief

核心结论与边界

T79 解决的不是某一条功能需求，而是此前多版本 Ontology 设计之间的基线分叉。

为什么需要收口

Object Registry 已完成 MVP0 契约冻结和 MVP1 物化实现，但 Ontology 内核概念、扩展模式与推进顺序仍散落在多份讨论材料中，并出现三类冲突：

  • 内核概念存在“含 Lens、不含 Receipt”和“含 Receipt、不含 Relation”等不同版本。
  • operating-object-model.md 与 Object Registry v1 在 project / solution 语义上存在相反措辞。
  • Query 被移出一等对象后，“经营主题”表达方式没有统一承接。

2026-08-17 五项裁决

  1. 内核定为七概念

    Object / Relation / Action / Operator / Evidence / Policy / Receipt。Relation 一等，Lens 挂起。

  2. 原型模型延后升级

    operating-object-model.md 暂不修改，待 Ontology 就绪后在 R6 升级或替换。

  3. 经营主题继续悬置

    不恢复已裁掉的 Query 类型，等 MVP2 产生真实使用分布后再评估。

  4. MVP2 与内核设计并行

    MVP2 只消费已冻结身份层契约，并为后续设计提供错配与 unmapped 分布。

  5. 主线聚焦 Registry + Ontology

    CRM、采购、PMO、HR 的接口梳理另线推进，不混入本议题。

扩展模型七项结论

适配是主要瓶颈

通用性投入优先落在适配自动化，而不是持续扩大本体。

Agent 只参与生成期

运行时必须是确定性代码；模型可生成映射草案和样板代码，不能静默转换生产事实。

扩展包按信任分级

第三方不得提供 Domain Pack；模型生成仅限 Interaction 与只读 Operator，并强制人工预览。

零代码不是硬目标

语义映射必须声明式；认证、分页、写回、重试允许代码实现。

默认卡片由内核推导

Interaction Pack 负责覆盖，而不是为每个对象从零定义基础呈现。

业务系统位于 Ontology 外部

自建与外购是商业判断；接入协议和架构地位保持一致。

Workflow 按权威划分

A/B/C 取决于状态权威归属，不按流程复杂度或系统归属划分。

采纳状态

设计正文已按终版口径书写，但不等于全部进入部署合同。

特别是四类 Pack 扩展体系，仍保持 T78 §9 的候选地位。要升格为正式架构主线，需要 Owner 另行裁决，并版本化扩展现有 Deployment Profile。

不授权范围

不直接改代码

不授权 runtime、客户端或服务端实现。

不直接改合同

不授权数据契约、Prompt、Migration 或权限策略变更。

不替代立项

R1–R6 每一步都必须有独立受益者、验收和授权。