食味里“川香鸡腿饭套餐”试点上线当天，市场部在企微群里宣布：“新品已经上架。”供应链部却回复：“新规格鸡腿肉对应的供应商SKU还不能采购。”一家门店的店长又发来截图：“POS里已经看得见，为什么顾客下单时仍显示不可售？”
数字化部门把材料摊开，发现每个人都有证据。
流程图的最后一个节点写着“POS启用产品与套餐，BOH开放门店可售”；规则要求菜单、价格、培训、设备和关键物料全部就绪；状态表又分别出现“已启用”“可采购”和“可售”。数据字典里却没有独立的“渠道展示关系”和“渠道可见状态”。
四份模型单独看似乎都合理，拼在一起却出现了四种“已上架”：总部启用了新品、供应链允许采购、POS渠道已经可见、具体门店能够销售。团队真正缺的不是第五张更大的图，而是一套能让不同模型对准同一业务世界的语义参照。
业务本体不替代这些模型，而是提供共同的对象、关系、状态和边界，让冲突可以被系统定位、由专家裁决，再回写到各自正确的位置。
【案例边界】 食味里是虚构企业。本文中的新品、配方、物料和质量规则用于说明分析方法，不代表现实餐饮法规或食品安全结论。正式项目仍应由企业质量、研发及合规责任人核对届时有效要求。
一、“已上架”不是一个状态，而是一组被压扁的业务事实
先把争论中的词放回它所属的对象。
现场说法 | 真正描述的对象 | 更准确的业务含义 | 主要承载模型 |
新品已上架 | 新品上线项目或发布批次 | 已满足总部定义的上线条件 | 流程、决策规则 |
产品已启用 | 产品或套餐 | 总部允许其进入有效经营范围 | 对象状态模型 |
采购可用 | 供应商SKU及其供应关系 | 在范围和有效期内允许采购某食材物料 | 规则、关系、数据模型 |
渠道可见 | 渠道展示关系 | 某产品或套餐已发布到指定POS渠道 | 关系状态、接口模型 |
门店可售 | 门店可售关系 | 某门店在当前条件下允许销售该产品或套餐 | 规则、状态模型 |
“新品已上架”是综合结果，不宜成为产品的万能状态。总部“已启用”不代表供应商SKU可采购；“渠道可见”不代表具体门店已准备好；门店临时停售也不应改变总部产品状态。
案例底稿2.0把“POS启用”和“BOH开放可售”写在一起，掩盖了两个不同关系的变化。数据字典又无法回答“在哪个渠道、什么时间、哪个版本已经可见”。问题不只是名称，而是模型粒度和业务边界没有对齐。
二、本体不是“超级模型”，而是跨模型的语义坐标系
BABOK 3.0把过程、状态、数据、决策和业务规则等视为从不同角度说明需求与设计的模型。它在“审核需求”中明确提出：不仅要检查每个模型内部是否完整，还要把相关模型相互比较，寻找一个模型出现、另一个模型缺失的元素，并检查称呼是否一致。
它在“定义需求架构”中又进一步说明，需求架构要把各种模型和说明组织成能够共同支持业务目标的整体。追踪可以证明每项需求连接到某个目标，却不能单独证明解决方案是一个可运行的内聚整体。
《PMI商业分析指南》也把范围、过程、规则、数据和界面模型作为互补视图，并将建模、核实确认、关系与依赖管理连成分析链路。“每张图都画对了”只是局部质量；它们是否描述同一业务世界，才是整体质量。
业务本体可以担当语义坐标系，因为它稳定表达：什么对象值得识别，如何区分对象身份，对象之间有什么业务关系，状态属于谁，事件改变了什么，规则判断依赖哪些事实。
本体不能吞并其他模型。流程回答“谁在何时做什么”，状态模型回答“对象怎样变化”，规则或DMN回答“如何判断”，数据模型回答“事实怎样记录”，接口模型回答“事实怎样跨系统传递”。它们引用相同事实时，应落到相同语义锚点。
我们要知道，本体没有脱离应用的唯一正确方案，要用能力问题、实例和专家评审迭代验证。食味里公司只需建立足以回答以下问题的最小参照：
某产品在总部是否已启用？
某供应商SKU在当前区域和时间是否可采购，映射到哪个食材物料？
某产品或套餐是否已发布到指定渠道？
某门店对该产品是否可售，依据和例外是什么？
所谓“新品已上线”究竟由哪些事实共同判定？
三、第一步不是比较图形，而是给模型元素挂上语义锚点
流程节点、状态名称、规则条件和数据字段使用的表示法不同，不能直接逐字比较。应先把每个模型元素登记成统一的“语义映射记录”。
一条记录至少包含：模型及版本、元素编号、原始名称、元素类型、本体概念、语义角色、范围、有效时间、权威来源、负责人和映射状态。
例如：
模型元素 | 局部含义 | 本体锚点 | 语义角色 |
流程节点“新品上架” | 完成发布动作 | 新品上线判定 | 决策结果，不是产品状态 |
BR-007“可采购” | 采购条件满足 | 供应商SKU采购资格 | 带范围和时间的业务判断 |
状态“已启用” | 总部对象有效 | 产品/套餐经营状态 | 对象状态 |
POS字段 | 系统记录的启用标记 | 需进一步确认 | 证据字段，不能仅凭名称定语义 |
BOH字段 | 门店是否可售 | 门店可售关系状态 | 关系状态的事实来源 |
看见字段叫enabled，不能自动映射成“产品已启用”。它也可能指接口记录、渠道配置甚至页面按钮。AI应把候选映射连同字段位置、取值、样例和使用规则交给BA确认。
《企业本体建模方法与实战指南》要求对象具备身份、事实来源、关系、状态和治理信息；关系还要说明方向、基数、时间有效性及来源。这个要求能防止“门店可售”被误建成产品的布尔属性。它实际上是一条连接门店与产品或套餐、带有时间和原因的关系，同一产品可以在A店可售、在B店准备中。
“渠道可见”也应建成渠道展示关系，而非产品的永久属性。渠道、区域、版本和时间变化时，产品身份不必改变。
四、从名称一致，检查到判断链路一致
完成映射后，检查应由浅入深，而不是让AI笼统评价“这些模型是否一致”。
1. 同名检查：同一个名称是不是同一个概念
先查同名异义。流程里的“已上架”、BI报表里的“已上架”和POS字段里的“已上架”，如果分别指上线里程碑、总部启用和渠道可见，就必须拆名或增加限定语。
再查异名同义。“开放销售”“可售”“允许接单”若在相同对象、范围和时间上表达同一状态，应映射为共同概念并保留系统别名。语义一致不等于界面字段必须同名。
2. 对象检查：状态和规则到底属于谁
“采购可用”不能挂在产品或食材物料整体上。食味里规定，规格变化会建立新物料编码；供应商SKU映射食材物料，并受供应商资质、质量批准、合同和规格有效性共同约束。因此，可采购的是特定供应商SKU或供应关系，而非抽象的“鸡腿肉”永远可采购。
Ontology Development 101关于定义域、值域和基数的原则很实用：若“供应”关系的起点、终点或数量约束不清，系统就无法判断采购规则约束谁。关系方向和对象边界比名称更重要。
3. 状态—流程检查：每次变化是否有事件和责任动作
状态模型说“门店可售关系从准备中进入可售”，流程中就应存在触发或确认这一变化的业务事件，并明确谁执行、依据什么结果。反过来，流程节点若声称“开放门店可售”，状态模型必须允许这次转换，还要定义失败、撤回和临时停售路径。
案例流程把POS启用和BOH可售合并后，无法说明前者成功、后者失败时对象处于什么状态。修正方式不是再画一条连线，而是拆成两个事件：渠道发布完成，使渠道展示关系进入“可见”；门店就绪确认通过，使门店可售关系进入“可售”。两者可以相邻发生，但不能被视为同一次状态转换。
4. 规则—流程—状态检查：条件是否有采集点，结论是否有落点
BR-012规定，菜单、价格、培训、设备和关键物料就绪后，门店才可进入可售。跨模型检查至少提出四个问题：流程中谁确认这些条件？状态转换是否以该判断为守卫条件？任一条件失效后是否有退出路径？判断结果及证据是否被记录？
如果规则写了条件，流程却从未采集；状态表允许直接跳转；或异常发生后没有回退路径，规则就只存在于文档里。AI应指出具体缺口，例如“状态转换T-07引用BR-012，但流程无设备就绪确认活动”，而不是泛泛地报“一致性不足”。
五、数据字段能否支持规则判断和状态转换
模型语义对齐后，还要追问一个更现实的问题：系统里有没有足够事实作出这个判断？
现有数据字典包含training_status、库存状态和可用量，POS—BOH接口可提供产品、套餐、价格和门店范围。但设备就绪事实、渠道展示关系及可见状态仍然缺失。
这不能都归为“少字段”。设备由谁确认、什么算就绪尚未定义，属于业务缺口；渠道发布动作已经存在，却没有模型承载，更接近结构缺口。若不区分，团队可能增加两个布尔字段，却仍不知道谁维护、何时生效。
采购可用也有类似问题。IF-04从采购SRM向ERP传递供应商SKU、资质、合同和物料映射，但数据字典只有supplier_sku_id，没有把资质状态、质量批准、合同有效期和规格有效性定义为可追溯的规则输入。接口“传过来”不等于业务上已经拥有权威、稳定、可复核的事实。
《本体驱动的 AI 数据管理》提出“事实—事理—行动”一体化。应用到一致性检查，就是为规则条件找到事实来源，为判断结果找到状态或决策落点，为改变找到受控动作和回写证据。任一环悬空，AI都不能可靠判断或行动。
六、把问题分成结构冲突、语义冲突和业务缺口
跨模型检查最忌讳把所有问题都叫“不一致”。不同问题需要不同的人处理。
结构冲突是业务含义相对清楚，但模型构件没有对上。例如规则引用“渠道可见”，数据模型没有承载关系；状态允许“准备中→可售”，流程没有触发事件；关系应为一对多，接口却只传一个值。这类问题多由BA、本体人员、数据或系统人员修复模型和映射。
语义冲突是不同模型对同一词或关系给出了不兼容的含义。例如流程把“上架”解释为POS发布，BI把它解释为总部启用；“可采购”一处属于物料，一处属于供应商SKU。它需要领域专家和语义裁决者确认定义、边界、范围及优先来源。
业务缺口是企业尚未作出决定，不能靠改模型解决。例如什么条件才算设备就绪，临时缺料时渠道是否保持可见，门店暂停销售是否触发顾客端隐藏。这类问题应升级给业务Owner，补充政策、例外、责任和评价标准。
分类的价值在于阻止AI“自作聪明”：结构冲突可以建议补关系或字段；语义冲突可以组织证据和候选解释；业务缺口只能生成待裁决问题，不能自动选择一个看似合理的答案。
七、AI一致性检查器应该怎样工作
一个现实可用的检查器，不是把四份文档塞给大模型问“有没有矛盾”，而是运行一条可追溯管道。
第一步，冻结流程、规则、状态、数据、接口和本体版本。
第二步，把模型解析成带来源位置的元素记录。
第三步，AI提出本体映射。
第四步，执行名称、关系、状态转换、规则输入、数据支持、范围和时间检查。
第五步，生成“冲突证据包”。
第六步，人工裁决、回写源模型并回归检查。
Palantir Model Studio在本系列中只能作为产品设计借鉴，而不是本体检查工具。它的训练运行会记录配置版本、输入与列映射、参数、状态、模型版本、实验和变更说明，并保留数据血缘。这个机制启发我们：一次一致性检查也必须记录自己比较了哪些版本。否则流程图周一更新、规则表周三更新、数据字典周五更新，AI拿“各自最新版本”比较，可能制造出并不存在的冲突，也无法复现历史结论。
每次运行至少保存检查批次、输入模型与本体版本、检查规则版本、命中问题、证据、人工决定和复测结果。
AI与人的边界也要明确：
自动完成：格式、标识、枚举、基数、字段覆盖、状态转移合法性等确定性检查。
AI建议、人工确认：同义词聚类、候选概念映射、规则条件拆解、疑似语义冲突和影响范围。
必须人工裁决：概念是否等价、哪个定义权威、业务政策如何取舍、例外是否接受、谁承担责任。
检查器不应只报“相似度87%”。它应输出可行动的问题记录：冲突类型、严重度、对象、源模型与版本、证据、影响、待回答问题、裁决人和状态。
评价检查器可观察语义映射覆盖率、规则事实支持率、状态转换证据覆盖率、人工接受率、误报率和高影响问题关闭周期。
八、食味里的最终调整：让五个概念各归其位
经过检查，食味里没有把所有模型改成一张“本体图”，而是作了五项语义裁决。
（1）“新品已上线”保留为项目或发布批次的综合判断，由总部启用、采购准备、渠道发布和门店试点就绪等证据支持；（2）“总部已启用”属于产品或套餐状态；（3）“采购可用”属于供应商SKU及其供应关系；（4）“渠道可见”新建为渠道与产品或套餐之间的展示关系状态；（5）“门店可售”继续属于门店与产品或套餐之间的可售关系。
随后，各模型各自修正：流程拆开渠道发布与门店可售确认；BR-005引用明确条件；状态表补充渠道展示关系；数据与接口补充渠道、发布版本、可见状态、有效时间和来源；BI分别统计总部启用、渠道可见、门店可售和全链路上线。
这样做并没有消除业务复杂性，而是把复杂性放回正确的对象、关系和模型中。以后有人再说“新品已经上架”，AI可以先追问：你指总部启用、渠道可见、门店可售，还是全链路上线？如果是后者，所需事实是否齐全、来自哪个版本、由谁确认？
结语：一致不是所有模型写成一样，而是它们能够彼此解释
流程、规则、状态和数据模型之所以不同，是因为它们承担不同任务。真正的一致性，不是统一画法、统一字段名，更不是让本体取代所有模型；而是任何一项业务判断，都能从规则追到所需事实，从事实追到权威数据，从状态变化追到流程事件，从局部名称追到稳定的业务含义。
业务本体提供锚点，需求架构组织多模型关系，AI批量比较并整理证据，BA与领域专家裁决含义、政策和责任。跨模型检查由此成为可重复运行、解释和治理的质量机制。
下一次评审流程图时，不妨选一个最容易被混用的词——已完成、有效、可用、上线或关闭——沿着流程、规则、状态和数据一路追问：它属于谁？由什么事件改变？依据哪些事实判断？系统是否真的记录了这些事实？很多真正昂贵的业务缺口，就藏在这四个问题之间。
