一页摘要
三个判断。① Snowflake 没有"做一个本体"，它把本体拆成四个各自可售卖、各自成熟的层，每一层的产物都是仓里的对象，由同一套 RBAC 治理——这是"数据平台公司做本体"的范式 B。你 7 月写下的"原始数据 → 湖仓 → 本体 → 应用 / Agent"与白板上的"事实层 / 语义层 / SOP 层 / Agent 层 / 应用层"是同一范式，而且在 Scan（九域抽取 + 代码反解出行为语义）和信任包络（证据 / 置信 / 探针 / Gap）上比 Snowflake 深一个量级。② 真正的分歧只有一处，而且是你有意选的：Snowflake 把本体当 context substrate（提示素材），你把本体当 "执行时强制关口"（受治理的决策空间）——这是叙事与定价的分界，不该为了对标而放弃。③ 但有三件事 Snowflake 做了、你设计了却没落地：本体成为湖仓里的一等对象（研发本体的实体 / 关系注册表仍在 Python）、统一节点边表 + 多跳遍历（RelationAssertion 契约定了，图没建，三本体 0 条完整跨本体闭环）、把使用痕迹当本体输入（Sense 吃查询历史与 BI 看板；我们的拒答日志、MCP 审计没有接回推荐边与同义词）。下一程就补这三件，并把你 OKR 草稿里"元模型放哪一层？？"的问号拉直：本体层是湖仓里独立的第六套 schema（onto / obr），与 DWD / DWS 同实例、同发布机制，不是 DWS 的一部分。
五项决策（建议）
- 本体入仓：研发本体注册表 + OBR 元模型用同一套 spec 语法导出为版本化契约包
ontology.yaml；发布后物化onto.kg_node/onto.kg_edge——边用你的 RelationAssertion 包络（证据 / 置信 / 时间 / 环境 / 冲突），不是裸 KG_EDGE。这就是 L1 归一层的首个交付物，用途 = 影响面三件套。 - 语义层成为一等公民：OBR 已有对象 / 行为 / 规则 / 关系 / 证据，补上 Semantic View 另外两件事——度量与同义词；词表工厂、人工校正层、候选审核收成控制台"本体页"一个界面（Semantic Studio 的穷人版），不做拖拽建模。
- 给 Agent 一份全局基底，但只做"只读上下文"：Manifest（"LLM 友好本体表示四件套"的压缩版，≤32 KB、零数字）作为 MCP
instructions下发；决策面仍走受治理的命名查询与预检。准确率按三色盲评 + 判对规则 + 分母报，不自报 47→83。 - 图在仓里、事实表不进图、不上图数据库：2,800 万调用边留在事实表与物化线索；节点 / 边数只披露不考核（禁止规模 KPI）。
- Action 只做只读半身：变更意图预检（改表 / 改接口 / 改配置 / 下线）作为"受治理决策空间"的第一个执行面；TACO 式反馈回灌只放开驳回方向（裁决 2）。
三阶段节奏（全部属于底座 / 轨道 B，不占灯塔 90 天窗口，单独预算与 KPI）
A · 本体入仓 · 归一层立项（2026-10 → 12）：契约包、kg 两表、neighborhood / path_between、Manifest v0、三色盲评对照、明文凭据收口、北极星看板挂牌。
B · 语义层一等公民 · 语义工厂（2027-01 → 06）：度量 + 同义词进 spec、使用痕迹回流、推荐边（候选 + 人审 + 留出集精确率）、本体页、命名查询 = 验证查询库、OBR 无源码模式试验（回答 Q1）、快照导出期权。
C · 企业上下文基底（2027-07 → 12）：业务本体试点（票税 / 销项一条 CQ 跨仓）、变更意图预检协议、跨引擎消费（仅当第二消费者）、评测与漂移报告常态化。
每阶段有失败即停的闸门（§5）；与《查询服务架构 v2.0》P0–P3 并行、共用契约包；与 2026H2 规划的条目一一衔接（§5 末表）。
Snowflake 的四层堆法：自下而上，每一层都是仓里的对象
文章的核心观察是一句话：Snowflake 走的是自下而上的路——先有目录（Catalog），再有语义层（Semantic），再有图（Knowledge Graph），最后是给智能体的统一接口（Cortex Sense）；与 Palantir"从业务对象出发、自顶向下"正好相反。把四层按时间排开，能看到它用了两年把"仓库里有什么"一步步推到"智能体知道仓库里有什么"。
L1 Horizon Catalog —— Polaris 之上的 AI 目录
2025-11-04 GA。三个组件：Collect（结构化 + 非结构化资产统一收集，带上下文）、Maintain（数据质量 + 自动化运维监控）、Extend（跨引擎读写——底层是 Apache Polaris / Iceberg REST，Spark / Trino / Dremio / Databricks 能直接读）。治理栈是 RBAC + FGAC + ABAC。
关键不是"又有一个 catalog"，而是把治理边界从 Snowflake 内部扩到跨引擎：Polaris 由 Dremio 与 Snowflake 共创、2024-08 捐赠、2026-02-18 升为 Apache 顶级项目（约 100 位贡献者、2,800+ PR、6 个版本，PMC 含 Google / Microsoft / Confluent / LanceDB）。这是对 Databricks Unity Catalog 的"开放标准之战"。
L2 Semantic Views + Semantic Studio —— 在 SQL 上盖一层受控词汇
Semantic View 是 schema 级的保存对象：定义哪些表构成一个业务实体、实体间的关系、哪些维度可分析、哪些度量可聚合，带同义词。DDL 2025-06 GA，派生度量 2025-09-30 GA，标准 SQL 查询 2026-03-02 GA，Autopilot（自动建议语义视图）2026-03 GA。
Semantic Studio 是编辑工具：选表 → 自动建议实体 / 维度 / 度量 / 关系 → 命名 + 同义词 → 提交 git 评审 → publish。2026-08-26 公开预览。它是 Cortex Analyst（NL→SQL，文章引述内部 benchmark 85–90%）、CoWork、CoCo、Cortex Sense 四个下游的共同输入。
L3 Knowledge Graph —— 节点边存进 warehouse，递归 CTE 遍历
2026-05-25 工程博客公开实现：图作为一组节点 / 边表存在仓内（KG_NODE、KG_EDGE、KG_NODE_PROPERTY、KG_EDGE_PROPERTY 等约 28 张元数据表），用递归 CTE 遍历；一组存储过程提供 CRUD；GraphRAG 接口把检索结果喂给 Cortex LLM 函数；Term Mappings 对齐不同 KG 的术语。Snowflake-Labs 有开源参考实现。
取舍：不要独立图数据库——"数据不用搬、治理边界统一"，代价是亿级边的遍历性能不如专用引擎。Snowflake 的判断是 80% 的企业图场景在百万边以下，warehouse 跑得动。
L4 Cortex Sense —— 自动构建"全局本体"给智能体
2026-06-02 Summit 进私有预览。三步：Scan（扫描所有表 / 视图 / 列 / 度量定义 / 语义视图，以及查询历史、BI 看板）→ Build（自动生成全局本体：节点是实体、边是关系）→ Share（作为"context substrate"暴露给 CoWork + CoCo，按用户角色与行为实时增强）。
Snowflake 自报：启用后 CoWork / CoCo 在复杂业务问题上的准确率从 47% 提到 83%。这是内部 benchmark，非第三方审计；但即便打折，量级也说明智能体的瓶颈不是模型而是 context。Catalog 是 Sense 的输入，Sense 是 Catalog 之上的智能体接口——两者是不同抽象层。
事实核验：文章的哪些说法是一手来源、哪些是厂商自报、哪些需要更正
| 说法 | 核验结果 | 来源 |
|---|---|---|
| Horizon Catalog 2025-11-04 BUILD GA，底层 Polaris | 一手确认 Snowflake 博客明确 Horizon Catalog 的互操作层建立在 Polaris 之上 | Snowflake 工程博客《Apache Polaris: The End of Data Vendor Lock-In》 |
| Apache Polaris 2026-02-18 升顶级项目 | 一手确认 polaris.apache.org 2026-02-19 公告；≈100 贡献者、2,800+ PR | polaris.apache.org / Dremio / Snowflake 博客 |
| Semantic Views 2026-03-02 GA | 需补充 03-02 GA 的是"标准 SQL 查询语义视图"；DDL 本身 2025-06 已 GA，派生度量 2025-09-30 GA，2026-06-26 "SQL 查询作为逻辑表" GA | Snowflake 发布说明 2026-06-26；Atlan 指南 |
| Semantic Studio 2026-06-02 私有预览 | 已过时 2026-08-26 发布说明：公开预览，所有账户可用；带 CoCo 对话式编辑、YAML 直编、Git 版本控制 | Snowflake 发布说明 2026-08-26 |
| Knowledge Graph：KG_NODE / KG_EDGE + 递归 CTE | 一手确认 工程博客《Ontology in Snowflake: Building Cortex Agents》与 Snowflake-Labs/knowledge-graph-snowflake | Snowflake 工程博客 / GitHub |
| Cortex Sense 47% → 83% | 厂商自报 Summit 2026-06-02 公布，私有预览；Sense 的输入还包括查询历史、对象元数据、BI 看板与语义视图（Horizon Context） | SiliconANGLE / Constellation / Atlan / typedef 的 Summit 报道 |
| CoWork / CoCo 改名；ontology-stack-builder skill（2026-03-30） | 文章所述，未独立核验 不影响本文结论 | 原文 |
两种范式，以及文章没说透的三件事
文章用 Palantir 的四件套（Object / Link / Action / Function）做了六维对标。把 OntoOS 放进同一张表当第三列，差异立刻清楚——OntoOS 在 Link 这一维比 Snowflake 多一样东西（实测命中率），在 Object / Function / 入口三维是"有但散落"，在 Action 一维与 Snowflake 一样空白。
| 维度 | Snowflake（范式 B） | Palantir（范式 A） | OntoOS 今天 |
|---|---|---|---|
| Object / 实体 | Semantic View 实体 + KG_NODE；维度、度量、关系随实体定义 | Ontology SDK Object Type，带 property | 43 个实体（42 表实体 + 1 合成实体"服务"），定义在 console/registry/entities.py（Python），不在湖仓；OBR 侧另有 BO / BB / BR 三类实体落 obr.* 七表（销项第四靶 76 BO / 287 BB / 143 BR） |
| Link / 关系 | KG_EDGE 显式声明，GraphRAG 遍历 | Link Type，带 cardinality | 79 条登记关系（57 条 1:N / 10 条 N:1 / 7 条 N:M / 5 条 1:1），13 条跨域桥；每条带实测命中率与 confirmed / weak 置信度；OBR 关系闭合词表 12 种——两家都没有的一维 |
| Action / 写 | 无独立 Action 层；写走 SQL / ETL | Action Type：validate 前置条件 + 权限 + 副作用 | 无，且是刻意的：只读 + 交接（Apollo 控制台 / 发布流程 / 负责人线索）；立项报告定的自治分级 A0→A4，P0 为 suggest-only |
| Function / 逻辑 | Cortex 函数、存储过程、Sense 的智能体函数 | Function metadata，可声明可调用 | 7 条服务端命名查询（SQL 由服务端持有、启动期 lint）+ 36 个 DWD / DWS 派生视图 + 技能仓 48 张实测 SQL 模板 |
| 入口 | SQL + CoWork / CoCo 自然语言 + Semantic Studio（git） | Workshop 拖拽 + OSDK（TS / Python）+ AIP agents | 本体控制台（飞书登录、发布区 / 工作区角色）+ MCP 8 个只读工具（经公司网关、Keycloak 令牌）+ 4 个姊妹技能 + probe CLI；找票"语义路由器"是第一个垂直应用 |
| 治理 | RBAC + FGAC + ABAC；Polaris 跨引擎 | 资源级 RBAC | 发布区 / 工作区两套层、每日原子快照发布（黄灯门禁）、服务端脱敏、审计；无跨引擎 / 开放格式（ADB-PG 专有） |
文章没说透的三件事
① Semantic View 的要害不是"关系"，是"受控词汇 + 度量"
文章把语义层描述为"哪些表构成实体、实体间什么关系"。但对 NL→SQL 真正起作用的是另外两件事：同义词（业务名词 → 列 / 实体）与度量（可聚合的量及其口径）。Cortex Analyst 85–90% 的准确率来自"骨架 + 词表 + 口径"三者，不只是骨架。OntoOS 的报障场景（页面名词 → 微应用 → 仓）今天靠 ILIKE 兜底，缺的正是词表。
② "图存进仓"是一种分工，不是一种妥协
Snowflake 把 KG 限定在"本体级"（实体与关系），不把事实级的大图（点击流、调用图）塞进 KG_EDGE，所以百万边以下的判断成立。OntoOS 恰好有两种图：本体级的（工作负载 ↔ 仓 ↔ 库 ↔ 表 ↔ 接口）和事实级的（2,800 万调用边、404 万 SQL 字段引用）。前者该进 KG，后者该留在事实表并以"线索摘要"（code_call_threads，≈501 万行物化闭包）挂进本体。分工对了，递归 CTE 在 ADB 上才跑得动。
③ Cortex Sense 的 Scan → Build → Share，OntoOS 各做到了哪一步
Scan：OntoOS 比 Sense 深——不只扫仓内元数据，还扫 GitLab / K8s / DMS / Apollo / 云网络 / ECS / 门户 / 镜像反解 / 活体 JVM 九个域。Build：Sense 是自动的，OntoOS 是人工策展（ADR-0045 否决了纯自动推导，理由是零外键、同名列不可信、跨域桥全是带解析逻辑的推断）；OBR 管线则是"SQL 确定性骨架 + LLM 只做命名与因果解释"。Share：Sense 把全局本体作为基底一次性暴露给 Agent；OntoOS 是 Agent 按需调 8 个工具逐跳取。差距集中在 Build 的自动化辅助与 Share 的预加载形态。
范式结论。文章说"有数仓 + 数据团队的企业接 Snowflake 范式最顺"。OntoOS 的起点正是如此：已有湖仓、已有 ODS / DWD / DWS 分层、已有每日发布。所以不该去模仿 Palantir 的独立 ontology 层与 Action 语义，而应沿范式 B 把三样东西补齐——可声明的语义层、统一的节点边面、给 Agent 的全局基底——同时守住 OntoOS 独有的两件事：命中率是一等属性、行为语义边来自代码反解。
你 7 月的思考 × Snowflake：同构 12 处、超越 6 处、该借 4 处
wiki《关于从事实逐层构建业务本体》今天（2026-10-08）拉到的是 rev 995，比 7 月 23 日本地留存的 rev 91 多出"解决的问题""OntoOS 产品化构建"白板与大纲、"H2 重点工作"（湖仓分层与元模型落位、产品 / 业务元模型如何抽取、三个数字员工小胡 / 小微 / 小休）三块。白板 75 节点里有一条直接点到 Snowflake：Open Semantic Interchange（OSI，2025-09 由 Snowflake / Salesforce / dbt Labs / BlackRock / RelationalAI 发起），以及 TACO（arXiv 2606.21685）的反直觉结论——"按置信度选样人审与随机选样效果相当，增益来自把人工反馈回灌去修正剩余 90%"。把这些思考与文章里的 Snowflake 四件套逐条对照，结果如下。
| Snowflake 的做法 | 你已有的对应物（出处） | 关系 | 本次处置 |
|---|---|---|---|
| Horizon · Collect 统一收集结构化 + 非结构化资产 | L0 事实层：九域抽取 + 镜像静态反解 + 活体 JVM 内省；"原始数据 1:1 入湖（业务数据、元数据）"白板「事实抽取 · 结构平面（已建，五源 + call-thread）」；思维导图 ④ L0 | 同构且更深 | 保持；行为语义边（调用线索 / MQ 闭合 / 配置真值 / 错误签名）是对客差异化原料 |
| Horizon · Maintain 数据质量 + 运维监控 | 北极星质量看板三指标：部署溯源 none 68.6% / call-thread 对齐 15.9% / MQ 孤儿 3,425（闭合 565）；三个覆盖缺口；契约哨兵思维导图 ④ L1、⑨；OBR 05 §3.4 | 同构，更具体 | 挂牌为 L0 常态（A7）；"本质是治理工程，剩余靠组织配合" |
| Horizon · Extend Polaris / Iceberg REST 跨引擎开放 | 红线：90 天不做 OSI / dbt / OWL / SHACL 导出；平台化门槛 = ≥3 个独立生产消费者 + 毛利为正；白板"结构产出 SHACL? OWL2 / RDF??"仍是问号平台设计 v0.2 §7 第 13 条；思维导图 ⑤⑩ | 分歧（刻意） | 本体标准导出不做；数据快照 Parquet 导出降为期权，由第二消费者承诺触发（B5）；OSI 只跟踪不采用（Q7） |
| Semantic View 实体 / 维度 / 度量 / 关系 / 同义词，schema 级对象 | OBR 元模型：BO / BB / BR + 12 种关系 + 四件套（EvidenceRef / Confidence / VerificationProbe / Gap），落 obr.* 七表；找票"字段语义卡"OBR 02 §1、§1.6；06 §3 | 同构；信任包络超越 缺度量、同义词一等化 | 补度量（measure）与同义词进 spec（B1 / B2）；保留描述性 / 规范性双地位 |
| Semantic Studio CoCo 对话编辑 + YAML + git 评审 + publish | 词表工厂（LLM 溯源化起草 → 域架构师审定 → git）；人工校正层 overlay（correct / endorse / retire / annotate，证据指纹变了标 stale）；候选审核 B4OBR 05 §3.1、§3.4；平台设计 v0.2 轨道 B | 同构；治理模型超越 | 三件事收成控制台"本体页"一个界面（B4），不做拖拽建模 |
| Semantic View Autopilot / ontology-stack-builder 自动建议语义视图 | 原则："反向抽取优先；LLM 只产 candidate；🔴否决 LLM 自由建模"；传播仅驳回 + 双层留出集实测精确率思维导图 ②；平台设计 v0.2 裁决 2、3、7 | 同构；多一道实测闸 | 推荐边走候选 → 人审 → 留出集精确率（B3）；ADR-0045 真源不变 |
| Knowledge Graph KG_NODE / KG_EDGE 存仓 + 递归 CTE + GraphRAG | RelationAssertion 契约（边具象化：id / type / from / to / qualifiers / valid+system time / scope / modality / evidence / confidence / verification / conflicts / source mapping）；obr_relations；红线"不上图数据库"元模型规范 §5.2；三本体关系模型 §5；思维导图 ⑩ | 同构（都在仓里）；边包络超越；图没建 | 物化 onto.kg_node / kg_edge（A2），边用 RelationAssertion 包络；多跳走递归 CTE（A3） |
| Term Mappings KG 之间的术语对齐 | 域级概念索引（seller"预制发票" vs cherry"预制发票"各自保留、注差异）；跨本体映射 denotes / realizes / represents；🔴禁 name-only sameAsOBR 05 §3.3；思维导图 ④ L2 | 同构 | 并入同义词层（B2）；跨仓边沿用三谓词（C1） |
| Cortex Sense · Scan 扫对象元数据 + 查询历史 + BI 看板 | 拒答日志回流（表达失配 → aliases；未覆盖 → 下一批靶点）；真实问题采集（T5，100–200 条）；MCP 使用观测（ADR-0051 审计：subject / tool / target / rows）OBR 05 §3.4；ADR-0051 | 同构但没接通 | 把 MCP 审计 + 拒答日志当"查询历史"喂推荐边与同义词（B2）——Sense 最便宜的一招 |
| Cortex Sense · Build 自动生成全局本体 | OBR 十阶段管线："SQL 确定性重建骨架，LLM 只做中文命名与因果解释"；ID 幂等（物理自然键派生）；置信去数值化；互证防虚增OBR 02 §0、§2、§3 | 同构；工程纪律超越 | 保持；研发本体注册表也改成同一 spec 语法（A1） |
| Cortex Sense · Share 全局本体作为 context substrate 注入 CoWork / CoCo | "LLM 友好本体表示四件套"（catalog / relationships / scenarios / validate_schema）；语义路由器三分（结构语义自答 / 运行态转工具 / 未覆盖拒答 + 探针工单）；严格引用制 + 完备性披露思维导图 ④ 工具链；OBR 05 §1、§3.3 | 分歧（刻意，定价分界） | Manifest 只做"只读上下文"（A4）；决策面走受治理查询 / 预检（C2）——见下方引文 |
| Cortex Analyst + Verified Query Repository NL→SQL + 人工验证的问题—SQL 对 | 智能找票语义路由器（口语 → 字段语义卡坐标翻译 → 校验器（反幻觉 + 索引锚）→ 只读 SQL → 证据化候选；1,159 万张票池 8 场景 5 正确 + 3 高风险拦截）；命名查询 7 条 + 48 模板 + 启动期 lintOBR 06；ADR-0050 | 同构 | 把命名查询明确定位为"验证查询库"，黄金集回归进发布门禁（B6） |
| 47 → 83 自报准确率 | 准确率纪律：值 + 分母 + 判对规则 + 边精确率；三色盲评（绿答对 / 蓝诚实 unknown 计通过 / 红有害错零容忍）；VNV 三臂消融（A 人工 / B 最小契约栈 / C 轻本体，同数据同规则同 UI）思维导图 ②⑨；立项报告 §六 | 超越 | A5 对照实验按此设计；对外只公布带分母的数字 |
| RBAC + FGAC + ABAC | 发布区 / 工作区角色、服务端脱敏、权限与脱敏双层（采集侧只记分布不记明文；渲染侧按人群分级）、网关 KeycloakADR-0046 / 0048 / 0052；OBR 05 §3.3 | 同构 | 保持；补 Owner / Steward 角色与签字（Q4） |
| Databricks Genie 式数据侧本体（文章提到的竞对） | GTM 关键假设："客户有数据、大概率无源代码 → 数据侧反向生成语义层"；Q1"客户无源代码、只用 SaaS 怎么办"本轮无技术答案白板「客户诉求」；平台设计 v0.2 Q1；思维导图 ⑥ | Snowflake 给了技术草图 | 新增 OBR"无源码模式"试验（B7）：只用 dms-comment / data-rule / 数据神谕 / 字段语义卡四个数据侧证据族跑一遍管线，给 Q1 一个可证伪的技术假设 |
超越 Snowflake 的 6 处（对外差异化，对内不要退回）
- 五元信任包络：Evidence / Provenance / Confidence / Conflict / Gap，边级 MUST / MAY 三色可视化；Snowflake 的 KG_EDGE 与语义视图没有置信与证据字段。54 厂商调研：7 家代码本体厂商在边级置信度上全空白。
- 描述性 / 规范性双地位：纯代码反推 = 系统行为描述；经校正层 endorse 或 why 文档佐证才升业务规范；"现状 ≠ 规范"是一等发现。Snowflake 的语义视图默认把定义当规范。
- 候选 → 人审 → 留出集实测精确率：Autopilot 是建议即发布；你的裁决是传播仅驳回、双层留出集、精确率必须实测（TACO 的教训）。
- 三臂消融 + 三色盲评 + VNV：本体的价值 = VNV(本体) − max[VNV(SQL / 规则), VNV(过程图), VNV(RAG)]，B 臂赢就采用 B；Snowflake 只给自报的 47→83。
- 代码反解的行为语义边：调用线索、MQ 闭合、配置真值、错误签名、业务枚举——"代码 + 运行环境 + 配置 + 数据结构 + 领域系统的联合视角"是 Snowflake 没有的原料。
- "执行时强制关口"的定位：本体不是提示素材，是受治理的决策空间（证据路由 / 规则版本 / 权限 / 审计回放）。
该向 Snowflake 借的 4 处（设计了没落地的）
- 本体是湖仓里的一等对象：OBR 七表已经在仓里，但研发本体的 43 实体 / 79 关系还在 Python 注册表、术语在 nav.py 与 CONTEXT.md。Snowflake 的语义视图是 schema 级对象——我们要做的是同一件事：契约包 +
ontoschema。 - 统一节点边表 + 递归 CTE：RelationAssertion 契约写得比 KG_EDGE 细得多，但三本体关系模型的审计结论是"当前研发关系多为专用事实表或查询时 DWS JOIN；0 条完整跨本体闭环"。先把图物化出来，契约才有载体。
- 使用痕迹是本体的输入：Sense 吃查询历史与 BI 看板来排序实体与关系；我们的拒答日志、T5 真实问题、MCP 审计三条回流都设计了，没有一条接到推荐边与同义词的生产。
- 度量与同义词是语义层的一等字段，并且一个界面完成起草—评审—发布：词表工厂、校正层、候选审核今天分散在 git / overlay / 审核队列三处；Studio 的价值在于把它们放进一个"提交 → 评审 → publish"的闭环。
这条分歧决定了 Share 怎么做。Cortex Sense 的 Share 是把全局本体压成基底注入 CoWork / CoCo——本质是更好的提示素材。沿你的定位，OntoOS 的 Share 应分两面：只读上下文面（Manifest：实体 / 关系 / 术语 / 命名查询目录 / 判读铁律，给 Agent 开地图）与受治理决策面（命名查询、影响面预检、严格引用制、拒答契约，给 Agent 划边界）。前者学 Snowflake，后者是我们卖的东西。
顺手拉直 OKR 草稿里的三个问号
"DWD 层 · 本体元模型层？？DWS · 元模型放这里？？"
Snowflake 的答案很干脆：语义视图与 KG 表是和物理表并列的仓内对象，不是某一层视图的子集。对 OntoOS：本体层 = 湖仓里独立的第六套 schema（onto 放归一后的实体 / 关系断言与 spec，obr 放业务语义），消费 DWD / DWS，随 ADR-0017 的发布机制一起原子切换；ADS 只放面向应用的投影视图。元模型不进 DWD，也不进 DWS。
"产品元模型 / 业务元模型如何抽取数据"
Snowflake 的 Autopilot 只用仓内元数据 + 查询历史就能起草语义视图；你的 OBR 管线多了代码侧四个证据族。所以"如何抽取"的答案是同一条管线、两种模式：有源码时跑全部 15 个证据族；无源码时只跑数据侧四族（dms-comment / data-rule / 数据神谕 / 字段语义卡）——后者就是 B7 的试验，也是 Q1 的候选答案。
"三个数字员工对本体 / 湖仓的需求"
小胡（CTO 助手）≈ CoWork：业务用户对话——需要 Manifest + 度量 + 命名查询 + 严格引用。小休（缺陷修复）≈ CoCo：开发者智能体——需要影响面三件套、call-thread、变更意图预检、测试验证契约。小微（研发运维）：Snowflake 没有的角色——需要业务词 → 技术坐标翻译（BO.physical_anchors / BB.technical_anchors / BR.enforcement_point）、neighborhood 多跳、runbook（结论绑运行态 commit）。三者共用同一基底，各取一面。
OntoOS 今天站在哪一层（发布区快照 2026-10-01）
以下数字全部来自发布区快照（publish_20260930_130033，2026-10-01 05:17 发布，最近三次发布均为黄灯）、控制台注册表与 ontoos_extract 仓库，不引用技能文档里的历史数字。行数为 pg_class 估算或直连 count，口径在附录。按你的表述纪律，这些规模只披露、不当成绩。
层名对照：Snowflake 四件套 ↔ OntoOS 四层
你在 7 月把 OntoOS 底座定为 L0 事实层（已建成）/ L1 归一层（未启动）/ L2 语义层（试点中）/ L3 意图层（无排期），信任机制横切各层，工具链与接口面在上。Snowflake 的四件套投到这张图上是：Horizon Catalog ≈ L0 + Maintain；Knowledge Graph ≈ L1 归一层的物化形态（身份 + 关系断言）；Semantic Views / Studio ≈ L2；Cortex Sense ≈ L3 + 接口面。下文的四层对位与第 5 节的路线图都按 OntoOS 的层名写，表述按层限定。
catalog / freshness 工具；服务端脱敏 + 审计。领先 九域抽取 + 镜像反解 + 活体内省，2,205 提交 / 52 ADR / 9,317 测试函数。缺 北极星三指标没有常态看板；开放表格式与跨引擎读为期权。registry/*.py；36 个视图各自物化一条链（入口链 7 跳、MQ 闭合、FE→BE→DB）；drill 沿一条登记关系走一跳。RelationAssertion 契约、跨本体三谓词已定稿。缺 统一节点 / 边表、多跳遍历、canonical 身份（JPA 一名平均对 9.3 个库，必须叠 db_id）；7 个视图在 ADB 上实测 OOM / 超时；"服务"是合成实体、无表无主键；0 条完整跨本体闭环。obr.* 七表落湖仓；词表工厂、校正层、严格引用制、完备性披露已设计。缺 度量、同义词一等化、可被 Agent 读取的统一 spec；探针 263 派生 0 执行（7 月底）；DMS 表注释 35.6% / 字段 45.5% 是语义天花板，需"人工校正 + why 文档证据"双通道、每域语义 Owner 落人头。/mcp（ADR-0050），经公司 agentgateway、Keycloak 令牌（ADR-0052）；search → describe → query/drill 三步工作法；找票语义路由器 8/8。缺 全局本体的预加载形态（Manifest）；评测基线仅 8 用例；运维 Agent 闭卷考 1,235 话题 → 31 准入（72.1%）→ 2 通过（6.5%），严格准确率 ≈22% 停滞——"考场已建好，语义资产不足"。13 条跨域桥：登记时实测命中率
命中率是关系登记时的基线值，不是当前值（v2.0 评审 CC-06 已裁定要拆成 RelationDefinition 与 RelationObservation）。斜纹 = weak（推断关系，不能当等值连接）。命中率偏低多半是业务覆盖缺口（如镜像未抽取、库未纳管），不是关系错误。
读法：前六条是"身份桥"（标签 / 名字 / 资源 id 直接对上），后七条是"推断桥"（解析连接串、文本匹配表名、Feign 名对 Service 名）。Snowflake 的 KG_EDGE 不区分这两种；OntoOS 把置信度与命中率做成一等属性，是对的——下一步要让它们随发布每天重测而不是停留在登记时的基线。
以 Snowflake 为镜：OntoOS 的五个结构性缺口
G1 语义层不是一等公民
本体知识今天住在三处：技能仓 Markdown（relationships.md + 24 个 references，952 KB，SKILL.md 内 245 处会漂移的数字）、控制台 Python 注册表（43 实体 / 79 关系，ADR-0045 定为唯一真源）、以及 36 个派生视图的 SQL 体内；OBR 的 obr.* 七表是唯一已经"入仓"的语义，但它与研发本体注册表不是同一套 spec 语法。Semantic View 的另外两个要素——度量（服务的端点数、依赖数、爆炸半径、配置漂移数的口径）与同义词（报障名词、拼音、英文名、门户菜单名、枚举中文）——完全缺席；门户微应用解析 exact 3,070 / unresolved 388 / ambiguous 112，报障名词落点靠 search 的 ILIKE。上游语义供给也薄：DMS 表注释覆盖 35.6%、字段注释 45.5%，与你 7 月测的 35% / 45% 一致——"人工校正 + why 文档证据"双通道、每域语义 Owner 落人头，是唯一的出路。
G2 图没有统一抽象（契约写了，图没建）
79 条关系散落在注册表，36 个视图各自物化一条链，Agent 要跨三跳只能串 drill。三本体关系模型（2026-07-23）的审计结论是："当前研发关系多为专用事实表或查询时 DWS JOIN；核心边缺统一 relation ID、有效期、环境、provenance 与 confidence；0 条完整 R / P / B 实例闭环"。RelationAssertion 契约（13 项包络）与跨本体三谓词已经定稿，缺的是载体。ADB 的现实约束也在这里：v_ingress_chain、v_scheduler_outbound、workload_active_gitlab 等 7 个视图实测段级 OOM 或超 60 s——"用视图现算多跳"已到天花板，Snowflake 的做法（物化节点边表 + 递归 CTE + 跳数上限）才是出路。"服务"是合成实体（工作负载名 / spring.application.name / feign_name / 仓 / Apollo app_id 的等价类），无表无主键，闭包有损（64.7% 调用方天花板）——它恰恰应该成为 kg_node 里的第一等节点；Entity Resolution 要单独立项（MyBatis table_refs → dms_tables 命中仅 22%）。
G3 Agent 的 context 是按需拉取，不是全局基底
MCP 的三步工作法（search → describe → query）要求 Agent 每次从零摸索；8 个工具的描述与 7 条命名查询的 notes 是它能拿到的全部"全局知识"。Cortex Sense 的 Share 做的是反过来的事：把全局本体压成基底，一次性进 Agent 的上下文。OntoOS 这边的证据已经很清楚——运维 Agent 闭卷考 1,235 话题 → 31 准入 → 2 通过（6.5%），覆盖率 93% 但严格准确率 ≈22% 停滞，根因是知识供给断层（Agent 字典滞后本体 4.7–9.7 倍：边表 178 vs 844、MQ 565 vs 5,454）；两次实战误入错误路径，runbook 化后同类问题 AI 自行走对。评测只有 8 条用例，没有"有 / 无本体"的对照实验，所以说不出 OntoOS 对 Agent 准确率的贡献是多少。
G4 开放性：一套专有仓、两套湖仓、零开放格式——但要按红线处理
Horizon 的 Extend 让其他引擎直接读目录；OntoOS 的消费方只有控制台、MCP 与四个技能，发布区锁在 ADB-PG 里。公司同时在建业务湖仓（Hologres + DataWorks，核心库 110 张表同步），研发本体与业务数据分处两套仓、零桥——而 Snowflake 路线的终点恰恰是"业务对象 ↔ 物理表 ↔ 使用它的应用"连成一张图。但你的红线是明确的：90 天不做 OSI / OWL / dbt 导出、不做接口预留、平台化门槛 ≥3 个消费者——所以开放性在本计划里只是期权，由第二消费者的承诺触发。另一个开放性债务是安全：发布区约 1,961 个明文凭据（2026-09 台账 SEC P0），不收口就不能把 KG / Manifest 开给全员。
G5 Action 层缺位——但缺得对，要补的是它的只读半身
Palantir 把每一次对本体的修改包成 Action（validate + 权限 + 副作用）；Snowflake 没有，OntoOS 也没有，而且 OntoOS 的只读边界是明确的产品决策（自治分级 A0→A4，核销 / 红冲 / 付款 / 过账默认不入 A4；P0 动作等级 suggest-only）。该补的不是写操作，而是"变更意图"的建模：改表 / 改接口 / 改配置 / 下线服务 四类意图各有一条可预检的影响面查询（v2.0 设计的 ontoos_impact 是雏形），输出结构化的交接单到发布流程与 Apollo，并把预检结果写回审计。这正是立项报告说的"受治理的决策空间"的第一个执行面——本体对变更的价值从"事后排障"前移到"事前预检"，又不越过只读红线。
不盲从清单
✗ 不把事实表灌进 KG
2,800 万调用边、3,268 万方法、404 万 SQL 字段引用是"发生"不是"东西"；进 kg_edge 会直接把 ADB 递归 CTE 压垮，也违背 Snowflake "百万边以下"的前提。KG 只装本体级边，事实级以物化线索（code_call_threads）摘要挂接。灯塔的十个最小对象全是业务交易对象，用不到 703 万调用边——同一个道理。
✗ 不采购独立图数据库
两家都证明"图在仓里 + 递归 CTE"对本体级规模够用；多一套引擎就多一套治理边界与一份凭据分发，正是 v2.0 要消灭的东西。你的红线里本来就有"图数据库提前上"。
✗ 不把 NL→SQL 自由问答做成全员面
Snowflake 有 Cortex Analyst 的 85–90% 是因为语义层先行。OntoOS 的全员面坚持命名查询 + 受限 DSL（v2.0 D3），自由 SQL 挡不住派生表达式推断秘密列。找票语义路由器之所以能 8/8，靠的是字段语义卡 + 校验器，不是自由 SQL。
✗ 不让"自动推荐边"绕过策展
ADR-0045 否决纯自动推导的三条实测理由（零外键、同名列不可信、跨域桥皆推断）依然成立；TACO 的结论是"置信度选样的价值被高估，反馈传播的价值被低估"。可以借鉴 Autopilot 做候选提案，但入库必须经 PR 评审、命中率守卫与留出集实测——真源不变，传播仅驳回。
规划：四层 × 三阶段（按你的原则与红线重排）
原则直接沿用 2026H2 规划的八条——用途拉动物化、反向抽取优先、按需分层、90 天可证伪、证据纪律、只读起步、投入纪律、表述纪律——外加本页新增的一条：本体是湖仓里的一等对象（可查询、可版本、可评测）。每条交付物都写明"被谁拉动"；每阶段有失败即停的闸门；规模数字只披露不考核。全部内容属于底座 / 轨道 B，不占灯塔 90 天窗口，单独预算、单独 KPI、单独归因（自反陷阱：平台人时不得计入 C 臂成本）。
阶段 A · 本体入仓 · 归一层立项 2026-10 → 2026-12
目标：本体从 Python 与 Markdown 搬进湖仓与契约包，L1 归一层以"影响面三件套"为首个用途立项，Agent 第一次拿到"全局本体"，并有一个可复现的准确率对照数。对应 2026H2 规划的"L1 归一层 P1 立项""北极星看板挂牌"与 v2.0 的 P0 契约。
ontology.yaml：研发本体注册表（registry/entities.py + relations.py）、schema.py 列注释、nav.py 词汇表与 OBR 元模型（BO / BB / BR / 12 种关系 / 四件套）用同一套 spec 语法导出，含 contract hash；注册表与 obr 表仍是真源，YAML 是生成物，CI 门禁"生成物与真源一致"。拉动用途：v2.0 服务端只消费契约包；Manifest 由它生成。验收：契约包随 release tag 发布；extract 仓不再被服务端 import。onto.kg_node / onto.kg_edge（独立 schema，进 ADR-0017 发布层集）：节点 = 42 类表实体的实例 + 合成实体"服务"的等价类（canonical id）；边 = 79 条登记关系的实例化，列按 RelationAssertion 包络（relation_key / cardinality / confidence / evidence / valid_from / observed_at / env / conflict_ref），首批覆盖影响面三件套（Microservice / ApiEndpoint / Table）与 13 条跨域桥；6 张事实表与子表属性不进图。拉动用途：影响面分析（L1 首个用途）、小微的坐标翻译。验收：全量生成 ≤30 min；每条关系的当日命中率入 kg_relation_observation，与登记基线偏差 >10 pp 自动开 issue。节点 / 边规模只披露。neighborhood / path_between 进命名查询：实体 k 跳邻域（k ≤ 3，按边类型过滤，递归 CTE）与两实体最短路（≤ 4 跳）。它们是 GraphRAG 的最小接口，也让"共享库故障传播""2 跳 Feign 上游"不再各写一张视图。验收：在 kg 表上 p95 ≤ 5 s；替换 ≥3 个 heavy 视图的用途。闸门：p95 不达 → 退回按用途物化视图，不建图。instructions 与 Resource ontoos://manifest 下发（对应 Sense 的 Share，只做只读上下文）。验收：零运行时数字（CI 门禁）；Claude Code / Codex 两类客户端加载后 tools/list 不膨胀。ontoos_ro 真正授权。这是 kg / Manifest 能开给全员的前提。验收：发布区可打码列之外的明文凭据值 = 0；安全测试集通过。阶段 B · 语义层成为一等公民 · 语义工厂轨道 2027-01 → 2027-06
目标：补齐 Semantic View 的另外两件事（度量、同义词），把 Build 的半自动化与 Studio 的编辑体验做成控制台的一页，让使用痕迹开始喂本体，并给 Q1（无源码客户）一个可证伪的技术假设。对应平台设计 v0.2 的轨道 B（B1 传播仅驳回 / B2 双层留出集 / B3 探针执行器 / B4 候选审核）与 OBR 落地方案的 M1。
v_service_iface_summary（1,833 服务）升级为"服务度量面"。拉动用途：小胡（CTO 助手）的经营问数。验收：≥20 个度量入 spec 并可经命名查询取值；口径由架构评审会裁定（Q4）。search 先走词表再 ILIKE 兜底；把 MCP 审计（ADR-0051）与拒答日志当"查询历史"：高频搜索词 → 同义词候选，高频 drill 路径 → 推荐边候选，拒答 → 下一批抽取靶点。词表工厂流程不变（LLM 溯源化起草 → 域架构师审定 → git）。验收：43 个实体全部有 ≥1 组同义词；报障名词首跳落点率 +10 pp；incident 分诊 100 条真实工单路由仍全对。闸门：域语义 Owner 工时无书面确认 → 不启动。service_context / impact（v2.0）落地；Manifest v1 带度量与同义词。验收：MCP 调用中命名查询占比 ≥70%；黄金集回归 0 失败；bench 第二轮对照。阶段 C · 企业上下文基底 · 从研发本体到业务本体 2027-07 → 2027-12
目标：把本体从"研发资产"延伸到"业务对象 ↔ 物理表 ↔ 服务 ↔ 页面"的一张图，并给变更以事前预检。是否进入本阶段取决于灯塔的 GO / NO-GO 与平台化门槛，不预设结论。
与 2026H2 规划、OKR 草稿的衔接
| 本页条目 | 2026H2 规划 / 平台设计 / OBR 方案里的对应项 | wiki「H2 重点工作」里的对应项 |
|---|---|---|
| A1 契约包 · A2 kg 两表 · A3 多跳 | 思维导图 ④ "L1 归一层 P1 立项，首个用途影响面分析（Microservice / ApiEndpoint / Table）"；三本体关系模型 §5 RelationAssertion 契约；v2.0 P0 契约包 | "构建 DWD 层 / 本体元模型层？？"→ 拉直为独立 onto schema |
| A4 Manifest · A5 对照 | 思维导图 ④ "LLM 友好本体表示四件套 = 未来 PaaS 化核心交付物"；② 准确率纪律；⑨ 三色盲评 | "Agent 能力规划，以及对本体、湖仓的需求"（小胡 / 小微 / 小休） |
| A7 北极星看板 | 思维导图 Quick Win #4；④ L1 "本质是治理工程" | "ODS 数据完整性和正确性校验" |
| B1 度量 · B2 同义词 · B4 本体页 | OBR 05 §3.4 词表工厂、§3.1 人工校正层；平台设计 v0.2 轨道 B B4 候选审核（改造） | "产品元模型 / 业务元模型如何抽取数据" |
| B3 推荐边（候选 + 人审 + 留出集） | 平台设计 v0.2 裁决 2（传播仅驳回）、裁决 3（双层留出集）、裁决 7（精确率必须实测）；白板 TACO 节点 | "本体的自改进 / OntoOS 本体资产的自改进" |
| B6 验证查询库 | OBR 05 §3.2 xval 三件套（真值卡回归 / 盲评 / 数据神谕）；行业研究 §4.3 VQR | — |
| B7 无源码模式 | 平台设计 v0.2 Q1；思维导图 ⑥ "客户有数据无源码 → 数据侧反向生成语义层" | 白板"客户无源代码，使用 SaaS，怎么办？" |
| C1 业务本体试点 | 立项报告 §四 二维地图"由一个 CQ 只点亮必要单元格"；思维导图 ⑤ 轨道分离 | "业务本体（票税）："（空白待填） |
| C2 变更意图预检 | 立项报告 §二.2 "受治理的决策空间"；思维导图 ② 自治分级 A0→A4；v2.0 ontoos_impact | 小休 "两头把控 / 如何验收 / 如何保证代码质量" |
红线对照（本页如何遵守你的"明确不做"）
遵守
- 不做全企业大本体：每条交付物由一个用途拉动，C1 只点亮一个 CQ。
- 不做图数据库：kg 两表在 ADB 里，递归 CTE + 跳数上限。
- 不做 OSI / OWL / dbt / SHACL 导出：B5 只是数据快照 Parquet，且由第二消费者触发；OSI 只跟踪。
- 不做 Agent 工厂 / 编排画布 / 逐层推导台 / 演示工厂：本体页只做 spec 浏览、候选、校正；无拖拽建模。
- 不做多租户、不做接口预留：契约包与 kg 表只服务当前消费者。
- 不拿节点规模当成绩：§6 把规模全部划入"披露"。
- LLM 只产候选、人做裁决、传播仅驳回：B3 / B4。
- AI 默认只读：C2 维持 suggest-only。
有意调整的两处（请确认）
- L3 意图层从"无排期"提前到阶段 A 的接口面：只做 Manifest 与对照实验，不做意图识别产品；理由是 A5 的对照数决定后续 L3 投入要不要加码，越早拿到越省钱。
- 把 Hologres 业务湖仓的库表桥列为期权而非承诺：你 9 月台账里 Hologres + DataWorks 已采购、110 张表同步中；但按"用途拉动物化"，桥要等第二消费者（灯塔或 BI）点名才建。
验收：判据与披露严格分开
按你的度量纪律——"把披露指标当 KPI 是强制停止条件"——本节把 v1 的验收表拆成两张：判据决定 GO / NO-GO，披露只报告不考核。
判据（决定阶段出口）
| 阶段 | 判据 | 现值（2026-10-01） | 出口要求 | 失败动作 |
|---|---|---|---|---|
| A | 契约包随 release tag 发布，v2.0 服务端只消费契约包 | 无（Python 注册表） | 达成 | B 全部顺延 |
| A | neighborhood p95（k ≤ 3）且替换 heavy 视图用途数 | 不可用；heavy 视图 7 | ≤5 s；≥3 | 退回按用途物化视图，不建图 |
| A | 有 / 无 Manifest 三色盲评：绿差值；红 | 无对照（严格准确率 ≈22%，闭卷考通过 6.5%） | 绿差值 ≥5 pp；红 = 0 | L3 投入降级，转投语义供给 |
| A | 发布区明文凭据值 | ≈1,961 | 0 | kg / Manifest 不开放全员 |
| B | 推荐边留出集精确率（预注册阈值） | 无 | ≥ 阈值 | 关闭传播，候选只进人审 |
| B | 报障名词首跳落点率（incident 100 条） | 路由全对；首跳未量化 | 基线 +10 pp | 同义词层回炉 |
| B | 验证查询库黄金集回归 | 8 用例 | Top-30 全部有黄金样例，0 失败 | 不切 serving，旧 run 继续服务 |
| B | 候选从提出到合入中位时长 | — | ≤10 工作日 | 本体页流程回炉 |
| C | 一条跨仓 CQ 在 MCP 上端到端跑通 | 0 | 1 | 业务本体试点停 |
| C | 变更意图预检接入发布流程，误报率有数 | 无 | ≥1 条产品线 | C2 退回协议定稿 |
| C | 平台化门槛：独立生产消费者 / 贡献毛利 | 1 / — | ≥3 / 为正 | 不谈 PaaS |
披露（只报告，不考核）
kg_node / kg_edge 规模 · 跨域桥数（13）与 weak 桥数（3）· 命名查询数（7）· 度量数 · 同义词覆盖（0 / 43）· Manifest 字节数 · heavy 视图数（7）· 注释覆盖率（35.6% / 45.5%）· 北极星三指标 · 探针派生 / 执行数 · 对象目录与行数。这些数字每次发布重算并附 as-of；出现在汇报里时必须带"披露"字样。
风险与需要拍板的问题
风险 ADB 递归 CTE 的性能
段级 OOM 已有 7 个视图的先例。对策：kg 两表物化 + 跳数上限（≤3）+ 预算（statement_timeout）+ 边类型过滤；超出的走离线 job。A3 的验收就是这条风险的试金石，且有退路。
风险 策展人力是瓶颈，Owner 不签字
13 条桥是 4 个月人工实测的结果；平台设计 v0.2 的头号风险"Owner 不签字"仍未解。对策：每域语义 Owner 落人头、工时需业务方书面确认（Q4）；本体页把评审成本降到"看命中率 + 点合入"；使用痕迹回流让候选排序不靠人。
风险 两套湖仓、两套真源
研发本体在 ADB，业务数据在 Hologres。若业务本体试点另起一套 spec 语法与注册表，就会复刻"技能仓 vs 注册表"的双真源问题（也是三本体 rev6 与 ADR-0001 冲突的翻版）。对策：同一套 spec 语法、同一个契约包、不同的存储。
风险 Manifest 吃掉 Agent 的提示预算
全局本体一旦超过几十 KB 就会挤掉任务上下文。对策：≤32 KB 硬上限、按角色 / 场景裁剪（Sense 也是按用户角色注入；小胡 / 小微 / 小休各取一面）、深层内容留在 Resources 按需拉取。
风险 评测可信度与自反陷阱
LLM-Judge 与人工评价相关系数仅 0.11，A5 必须保留人工校准环；本页所有人时若被计入灯塔 C 臂成本，会把 Day 90 的结论推向"C 输"——双轨分离不是组织偏好，是实验有效性的前提。
风险 描述性本体被当规范性消费
反向抽取的上限是"系统实现的业务"，不是"业务"；现状可能是历史 bug 固化。对策：Manifest 与问答措辞一律标"系统行为语义"；endorse 是升规范地位的唯一通道；"现状 ≠ 规范"作为一等发现上报。
需要拍板
onto / obr 作为独立 schema 进 ADR-0017 的发布层集（同实例、同原子切换），而不是挂在 DWD / DWS 下。附录：事实口径与来源
A · 湖仓与仓库事实（本文引用的数字从哪来）
| 事实 | 值 | 口径 / 来源 |
|---|---|---|
| 发布区快照 | publish_20260930_130033，2026-10-01 05:17 发布，4,157 源 / 4,113 活跃批次，最近三次发布黄灯 | MCP freshness（发布区） |
| 对象目录 | 148 = 112 ODS 当前视图（契约 112/112）+ 36 关联模型域视图；7 个视图标 heavy | MCP catalog；heavy 为实测 OOM / 超时标注 |
| 注册表 | 43 实体（1 合成）、79 关系（76 confirmed / 3 weak；57 1:N、10 N:1、7 N:M、5 1:1）、13 跨域桥、6 事实表 | ontoos_extract/console/registry 直接计数（2026-09-30 代码） |
| 桥命中率 | 见第 3 节条图 | 注册表 hit_rate（登记时基线，非当前值） |
| MCP 面 | 8 只读工具、7 命名查询、≤200 行 / 64 KB、并发 4、逐次审计、网关 Keycloak 令牌 | ADR-0050 / ADR-0052、docs/console.md §7、MCP queries |
| 资产规模 | GitLab 2,000 仓；K8s 14 集群 5,589 工作负载；DMS 604 实例 / 17,027 库 / 104,098 表 / 1,904,709 列；代码归档 4,134；Apollo 113 应用；服务接口汇总 1,833 | 直连 ods_current / dws count（2026-10-01 21:00） |
| 语义覆盖 | DMS 表注释 37,095 / 104,098 = 35.6%；字段注释 866,417 / 1,904,709 = 45.5%；门户微应用 exact 3,070 / unresolved 388 / ambiguous 112 / assets-path 3 | 直连 count；与 2026H2 规划所记 35% / 45% 一致 |
| 事实表量级 | 调用边 ≈2,807 万；方法 ≈3,268 万；调用线索 ≈501 万；SQL 字段引用 ≈404 万；端点 ≈30.7 万；错误签名 ≈73.1 万；枚举 ≈55.6 万 | pg_class 估算（含历史批次，对当前视图偏高） |
| 工程规模 | 2,205 提交（2026-05-13 → 09-30）、52 ADR、112 张 ODS DDL + 45 视图、9,317 测试函数、86,557 行 Python、issue / PR 至 #525 | git 与源码统计 |
| Agent 现状 | 运维 Agent 覆盖 93% / 严格准确率 ≈22%；闭卷考 1,235 话题 → 31 准入（72.1%）→ 2 通过（6.5%）；Agent 字典滞后本体 4.7–9.7 倍；bench 85 题；LLM-Judge 相关性 0.11；发布区明文凭据 ≈1,961 | 半月台账 2026-09-01 / 09-15；思维导图 2026-07-30 |
| OBR 现状 | 四个服务靶；ant-coop-service 76 BO / 287 BB / 143 BR / 1,240 边，验收 87/87，A 级 10；OWL 落地 95 实体 / 414 关系；探针 263 派生 0 执行；找票 POC 1,159 万张票池 8 场景 | ontoos-product-onto README（2026-07-22）；思维导图 ④ |
| 北极星与归一缺口 | 部署溯源 none 68.6%；call-thread 对齐 15.9%；MQ 孤儿 3,425（闭合 565）；MyBatis table_refs → dms_tables 命中 22%；JPA 一名平均对 9.3 个库 | 思维导图 ④ L1（2026-07-30 口径） |
B · 内部输入（v2 新增）
- wiki《关于从事实逐层构建业务本体》— xforceplus.feishu.cn/wiki/Wdl1wrTURilb4ZkTkd2csIR5nDf，2026-10-08 以用户身份拉取，rev 995（7 月 23 日本地留存为 rev 91）；内嵌白板《OntoOS 产品化构建》（75 节点）同日导出，节点大纲存
inputs/。 - 《本体工作规划 2026H2 · 思维导图》v1.0（2026-07-30，草稿供评审）— 四层底座、四个价值场景、原则与红线、度量纪律、Quick Win。
- 《本体构建与管理平台（Ontology Builder）产品设计文档》v0.2（2026-07-28）— 双轨裁决、九项裁决、集体盲区、明确不做 17 条、开放问题 Q1–Q7。
- 《OBR 元模型与推导管线》终稿 v1.0、《业务语义层（OBR）落地方案》v1.0（2026-07-12）、《未知的未知》、ontoos-product-onto README（第四靶 2026-07-22）。
- 《OntoOS 继续推进立项报告》（董事会）— "受治理的决策空间"、二维地图、四种状态、三臂消融、VNV。
- 《企业 AI 时代的 Ontology》研究 2026 — 五层能力模型 L0–L4、Snowflake = L1 分析语义基线 / Palantir = 能力上界、双速语义架构、VQR。
- 《OntoOS 三本体关系完整模型（Synthesis）》（2026-07-23）— RelationAssertion 契约、四个真值平面、rev6 与 ADR-0001 冲突、0 条跨本体闭环。
- 《OntoOS 查询服务架构设计 v2.0》（2026-09-20）— 执行与事实上收服务端、13 工具、RelationDefinition / Observation 拆分、P0–P3。
- ADR-0017 快照发布、ADR-0045 策展关系注册表、ADR-0049 发布快照保留、ADR-0050 控制台 MCP 端点、ADR-0051 使用观测、ADR-0052 网关 Keycloak 令牌；CONTEXT.md「本体控制台」与「Relationships」段。
C · 外部来源
- 线索文章：《Snowflake 怎么把本体论塞进数仓：四款产品对比 Palantir Ontology》（公众号，作者 hyj）— mp.weixin.qq.com/s/z8F_4wxJLQj1CIhwwfbfMg
- Snowflake 工程博客《Ontology in Snowflake: Building Cortex Agents》— snowflake.com/…/ontology-grounded-cortex-agents；参考实现 Snowflake-Labs/knowledge-graph-snowflake
- Snowflake 发布说明：2026-08-26 Semantic Studio（Preview）；2026-06-26 语义视图逻辑表 GA；Verified Query Repository
- Apache Polaris 顶级项目公告（2026-02-19）— polaris.apache.org；Snowflake《Apache Polaris: The End of Data Vendor Lock-In》— snowflake.com
- Summit 2026 报道：SiliconANGLE、Constellation Research、Atlan：Cortex Sense、typedef：What Is Cortex Sense
- Semantic Views 时间线：Atlan 2026 指南；Capital One《Scaling Agent Context with Knowledge Graphs on Snowflake》— capitalonesoftware.com
- TACO（arXiv:2606.21685，2026-06）：置信度选样与随机选样效果相当，增益来自反馈回灌——白板「群星技术路线调研」节点转述，未独立核验。
本页为内部规划稿，noindex；数字以发布区当日快照为准，复查请重跑附录 A 的口径。v1（2026-10-01）保留为 index.v1-20261001.html.bak。