ODS · 订单业务闭环 · 虚构数据沙箱
一笔订单，怎样安全地走到出库？
先看业务对象与记录，再看规则怎样判断，最后看哪些前提允许模拟处置。
人工定义结构＋明确规则计算，非AI自动理解。本体提供对象、属性、关系与含义；规则和状态机计算判断、检查前提、改变模拟状态。
1. 业务挑战与目标
目标：避免超卖，让采购支出、交期例外、动作责任和证据都能说清；本例不计算利润或ROI。
同一订单的独立假设情景，各自库存；不是两笔并行订单，也不共用库存。
2. 实体、属性和关系是同一份业务记录
点击清单或关系图中的实体，查看相同记录的属性、出处、关系及相关动作。客户、供应商本轮只保留引用ID。
实体清单
实体关系图
关系图较宽，可在图内左右滑动查看。
下方属性表较宽，可在表格内左右滑动查看字段与来源。
3. 改具体记录，建立新的独立情景
这里只改四项业务输入。提交后建立新草稿，旧计划、确认和动作留在历史；政策仍固定，不会改写已发生的采购或出库。
4. 对照情景：建议、实际模拟支出、库存与出库
初始计划与当前评估分列。采购发生后支出保留；采购本身不增加库存。空值表示尚未评估，不伪装为0。
可在表格内左右滑动查看两情景与业务含义；指标列保持在左侧。
当前情景的判断与因果链
5. 动作前提、效果与实际模拟推进
自动判断、人的决定与模拟执行分开。下面的岗位是公开预设的模拟身份，点执行代表要求程序模拟该岗位；不是已认证真人审批。真实写入始终关闭。
本次显式模拟参数（可修改）
上述凭证与时间预填可见教学值，执行以表单中明确值为准。收货、同意、批准、时间推进都须单独操作。
受限自动化：按模型模拟推进，遇人审即停
跟随核心下一步，最多8步，仅推进校验、评估、模拟采购、预留、出库。客户同意/批准/拒绝、模拟时间、收货均不自动代办。
完整动作目录：前提不满足时说明原因
目录可用性来自Controller对公开样例参数的核心预检；实际执行仍重新检查当前版本、状态、表单凭证及时间。目录模板不是已经执行。
本次处置产生的记录
6. 从字段映射到规则与出处
本run初始输入的字段映射
这张表保留本次情景的初始记录；动作后的实时库存在实体“仓位库存”的runtime属性中。两者不能混作同一时点。
映射表较宽，可在表格内左右滑动查看完整字段与来源。
公开规则
本情景的来源版本与具体记录
7. 旧运行留证，不改写事实
旧运行表出现后，可在表格内左右滑动查看各列。