OntoOS 下一程：对照 Snowflake 的本体路线，补齐语义层、图谱层与 Agent 上下文基底

五项决策（建议）

1. 本体入仓：研发本体注册表 + OBR 元模型用同一套 spec 语法导出为版本化契约包 ontology.yaml；发布后物化 onto.kg_node / onto.kg_edge——边用你的 RelationAssertion 包络（证据 / 置信 / 时间 / 环境 / 冲突），不是裸 KG_EDGE。这就是 L1 归一层的首个交付物，用途 = 影响面三件套。
2. 语义层成为一等公民：OBR 已有对象 / 行为 / 规则 / 关系 / 证据，补上 Semantic View 另外两件事——度量与同义词；词表工厂、人工校正层、候选审核收成控制台"本体页"一个界面（Semantic Studio 的穷人版），不做拖拽建模。
3. 给 Agent 一份全局基底，但只做"只读上下文"：Manifest（"LLM 友好本体表示四件套"的压缩版，≤32 KB、零数字）作为 MCP instructions 下发；决策面仍走受治理的命名查询与预检。准确率按三色盲评 + 判对规则 + 分母报，不自报 47→83。
4. 图在仓里、事实表不进图、不上图数据库：2,800 万调用边留在事实表与物化线索；节点 / 边数只披露不考核（禁止规模 KPI）。
5. 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 末表）。

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 之上的智能体接口——两者是不同抽象层。

① 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 的 6 处（对外差异化，对内不要退回）

1. 五元信任包络：Evidence / Provenance / Confidence / Conflict / Gap，边级 MUST / MAY 三色可视化；Snowflake 的 KG_EDGE 与语义视图没有置信与证据字段。54 厂商调研：7 家代码本体厂商在边级置信度上全空白。
2. 描述性 / 规范性双地位：纯代码反推 = 系统行为描述；经校正层 endorse 或 why 文档佐证才升业务规范；"现状 ≠ 规范"是一等发现。Snowflake 的语义视图默认把定义当规范。
3. 候选 → 人审 → 留出集实测精确率：Autopilot 是建议即发布；你的裁决是传播仅驳回、双层留出集、精确率必须实测（TACO 的教训）。
4. 三臂消融 + 三色盲评 + VNV：本体的价值 = VNV(本体) − max[VNV(SQL / 规则), VNV(过程图), VNV(RAG)]，B 臂赢就采用 B；Snowflake 只给自报的 47→83。
5. 代码反解的行为语义边：调用线索、MQ 闭合、配置真值、错误签名、业务枚举——"代码 + 运行环境 + 配置 + 数据结构 + 领域系统的联合视角"是 Snowflake 没有的原料。
6. "执行时强制关口"的定位：本体不是提示素材，是受治理的决策空间（证据路由 / 规则版本 / 权限 / 审计回放）。

该向 Snowflake 借的 4 处（设计了没落地的）

1. 本体是湖仓里的一等对象：OBR 七表已经在仓里，但研发本体的 43 实体 / 79 关系还在 Python 注册表、术语在 nav.py 与 CONTEXT.md。Snowflake 的语义视图是 schema 级对象——我们要做的是同一件事：契约包 + onto schema。
2. 统一节点边表 + 递归 CTE：RelationAssertion 契约写得比 KG_EDGE 细得多，但三本体关系模型的审计结论是"当前研发关系多为专用事实表或查询时 DWS JOIN；0 条完整跨本体闭环"。先把图物化出来，契约才有载体。
3. 使用痕迹是本体的输入：Sense 吃查询历史与 BI 看板来排序实体与关系；我们的拒答日志、T5 真实问题、MCP 审计三条回流都设计了，没有一条接到推荐边与同义词的生产。
4. 度量与同义词是语义层的一等字段，并且一个界面完成起草—评审—发布：词表工厂、校正层、候选审核今天分散在 git / overlay / 审核队列三处；Studio 的价值在于把它们放进一个"提交 → 评审 → publish"的闭环。

"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）。三者共用同一基底，各取一面。

✗ 不把事实表灌进 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 评审、命中率守卫与留出集实测——真源不变，传播仅驳回。

遵守

• 不做全企业大本体：每条交付物由一个用途拉动，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）点名才建。

不同 1 我们有产品源码

Snowflake 的客户只能从数据与使用痕迹建语义；我们可以从代码反向抽取（OBR：端点、守卫条件、SQL 条件、配置真值 → 业务对象 / 行为 / 规则），每条结论回链证据。抽取更深，但上限是"系统实现的业务"而不是"业务"——描述性本体必须与规范性来源对账，这是第 3 条。

不同 2 一套产品服务多个租户

产品本体（BO / BB / BR）来自同一份代码，一次抽取、全部租户共享，成本被摊薄；租户差异只是配置项、枚举值与自定义字段的一层薄 overlay。真正租户特异的是业务本体（客户自己的票税业务：发票、税号、申报、对账），它必须由客户的 CQ 拉动、在业务湖仓上建。这不是要做多租户平台（红线），而是说清三本体各自的"谁出钱、谁共享"。

不同 3 领域有外部规范源

发票类型与状态、税收分类编码、税率表、申报表式、全电发票数据规范——这些不用抽取，是给定的规范性锚点。Snowflake 的路线里没有这一层。有了它，"系统实现的业务"（描述性）与"税法要求的业务"（规范性）可以逐条对账，差异本身就是一等发现（历史 bug 固化、灰色实现、化石流程）。这是票税本体相对通用本体的差异化能力。本节新增建议

演示的数据口径与安全

• 真实快照：每页页脚写快照 id 与 as_of；****** 是服务端打码不是空值。
• 二次脱敏：主机名 / IP / 邮箱 / 手机号 / 人名字段在打包时替换为 <host> 等占位；OBR 与找票子集不含发票号、税号、企业名与金额，结果行一律丢弃只留计数。
• 与本页同级发布（noindex、无口令）。若要对客户或董事会演示，建议切到口令壳（既有的 AES-GCM 构建模式）。
• 复现：scripts/mcp_pull.py（经网关原样拉取）→ build_graph.py / build_manifest.py → build_demo_data.py（脱敏打包）。

从演示到产品：三件顺手的事

• M2 + M4 就是本体页（B4）的雏形：把实体浏览器、关系图与 kg_edge 行搬进控制台，再加候选与校正层操作。
• M5 的 Manifest 草案可以直接进 A4：生成脚本已零运行时数字，缺的是 CI 门禁与按角色裁剪。
• M6 的人审台原型定义了 B3 / B4 的交互契约：接受 / 背书 / 驳回 / 批注四动作、驳回传播、每 5 条进留出集——先按这个口径写验收，再做界面。

风险 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 是升规范地位的唯一通道；"现状 ≠ 规范"作为一等发现上报。