十阶段管线：证据 → 推导 → 验证

POC代码做确定性的事，LLM 只产候选，人做裁决；每个结论回链证据并继承 / 降级置信

本体浏览器

POC

        关系小图

        POC点节点：高亮 1 跳邻域并同步上方浏览器；实线 high / 虚线 medium

        人审台

        原型对应规划条目：B3 推荐边（候选 + 人审 + 留出集）· B4 本体页（校正层 overlay）。状态只在浏览器内，刷新即复位。

          接受 ≠ 规范。反向抽取得到的是"系统实现的业务"，不是"业务规范"——现状可能是历史 bug 固化。接受只表示"证据与推导成立"；背书（endorse）是升规范地位的唯一通道，且要留下记录。传播只在驳回方向：接受与背书不会自动扩散到任何其它条目。

          数据神谕与驳回样例

          POCxval：拿生产数据的取值分布去核 BO 的枚举轴；S7 装配阶段机检驳回

          驳回样例（ / 52）

            驳回原因分布（全量 52 条）

            化石 = 表在、注释在、生产 0 行。预制发票主表族生产 0 行，说明主流程已外移或换库——这是"描述性本体"最重要的一类发现：它告诉你文档和代码里的业务与真实运行的业务已经分叉。必须作为一等发现上报，而不是悄悄把对象删掉或改成"正常"。

            无源码模式试验（B7）

            规划回答 Q1「客户无源代码、用 SaaS，怎么办」的技术假设

            本轮 16 个证据族按"要不要源码"分成两侧；右侧数字是第四靶实际用到的证据条数。试验设计：屏蔽代码侧证据族，只用数据侧重跑十阶段管线，与全模式结果做 diff——BO 召回还剩多少、BB 几乎为零时规则还能从数据态提炼多少、A 级能否出现。结论进 Q1 的董事会议题，而不是在产品设计里假装已解决。

            Snowflake 对位与缺口

            Snowflake做法OntoOS · OBR 管线
            Semantic Studio人在界面上建语义视图：选表、定维度与度量、写同义词语义不是人从零建，而是从代码 + 数据证据反向抽取：表簇 → 对象、端点 + 数据足迹 → 行为、守卫 / SQL 条件 / 配置 → 规则
            Autopilot按表结构与查询历史建议度量、同义词，人确认LLM 只产候选（S2 / S4 / S6），S7 机检驳回 52 条（无证据、反幻觉、孤儿规则），人审入手册
            Cortex Sense · Build扫描使用痕迹与元数据自动建上下文证据来自湖仓的 16 个证据族，每条结论带 evidence_refs；使用痕迹回流是 B2 的规划项
            超越 EvidenceRef / Confidence / VerificationProbe / Gap 四件套 + 校正层 overlay = 五元信任包络；置信度两维（证据硬度逐跳取短板、推导硬度只降不升）；数据神谕用生产数据反证；A / B / C / X 四级决定条目去向（正文 / 待核实 / 仅 JSON / 勘误）。Snowflake 的语义视图没有这些字段。
            缺口 人审台未产品化（B4 本体页）；探针 259 条派生、0 条执行（B3 探针执行器与回填闭环）；A 级仅 10 条且全在 BR（BO / BB 最高 B 级）；驳回传播尚未自动化（本页原型演示的就是这一跳）。