事实归属与语义边界
状态：working-draft；本轮建议矩阵，不是完整字段或聚合目录。
上游：候选上下文；日期：2026-09-18。
1. 唯一事实 Owner
“唯一 Owner”指业务含义及合法写入责任，不表示只能有一个表、一个副本或一个调用者。允许受控快照和可重建投影，不能用投影改源事实。
| 事实族 | 唯一责任建议 | 其他参与方如何使用 | 必须防止的混淆 |
|---|---|---|---|
| 主体、组织、服务区域版本、岗位、授权策略 | Identity | 引用稳定标识与版本，获取授权决定 | Account 不等于 Customer；区域不等于配送时段 |
| 客户档案、地址簿、同意、偏好、个人计划 | Customer | 提取最小化引用或冻结快照 | 更新地址簿不改成交地址；同意不等于所有操作权限 |
| 团长资格及活动关系 | Customer，增长边界待核对 | Commerce 引用有效关系及来源依据 | 不建团长专属订单中心；不默认包括佣金核算 |
| SKU、规格、推荐菜谱、内容发布 | Catalog | 使用明确版本与发布状态 | 已发布不等于有供给或可成交 |
| 物料来源、批次、质量、账本及追溯边 | Supply | Demand 消费能力；Fulfillment 调用物料命令 | 实体余额不等于预约容量；包裹绑定边不等于包裹生命周期 |
| 履约能力原始版本 | Fulfillment | Demand 将其作为承诺输入 | 不由 Demand 或任务完成事件随意改写 |
| 时段、Hold、Commitment、预约 | Demand | Commerce 经命令申请/确认/释放 | Hold 不等于物料预扣，不等于已确认订单 |
| 订阅合同、周期、权益 | Demand 候选内部责任区 | 向 Commerce 请求标准周期订单 | 未来暂停不改既有成交或已执行任务 |
| 每日配送安排、明确确认记录、到期决定 | Demand | Commerce按确认超时取消订单；Fulfillment校验本次授权及版本 | 可提前确认且不每日重确认；默认16:00只取消未确认。付款和通知不代表同意 |
| 购买批次、关联新单与替换请求 | Commerce | Customer 沿餐次展示订单谱系；Demand/Fulfillment 返回各自回执 | 周视图不是交易聚合；终态订单不能恢复 |
| 原收款分配、消费依据、可退额度及结算调整 | Commerce 资金责任区 | Finance 解释经济事实；后台只执行受控命令 | 退款未知不释放占用，结清后更正另建关联记录 |
| 执行范围、代际 fence、停止回执及数量谱系守卫 | Fulfillment | Commerce 据永久停止证据关闭旧单；Demand 据证据撤销授权 | 单个任务锁不能防止不同版本重复切同一份肉 |
| Cart、PriceQuote、价格与优惠决定 | Commerce 定价责任区 | 顾客确认，Order 冻结依据 | 预览价格不自动成为成交价格 |
| Order、成交快照及商业状态 | Commerce 订单责任区 | 各端查询同一标识及受控视图 | 后台订单、小程序订单不是两个事实源 |
| Payment、Refund、已验证交易结算 | Commerce 资金责任区 | 确认流程、Finance、售后消费结果 | 收到回调、发起退款不等于资金终态 |
| 售后裁决及执行协调 | Commerce 售后责任区 | 调用各 Owner 的退款/退回/质量动作 | CustomerCase、AfterSaleCase、RecallCase 不通用合并 |
| 作业、测量、包裹、交接与交付 | Fulfillment | 顾客看摘要；Channel 回传；Supply 接受相关物料观察 | FulfillmentOrder 不等于第二个商业 Order |
| 科目、规则、期间、分录与核算结果 | Finance | Analytics 派生展示；财务受控查询调整 | 收款不等于收入；分录不由 Analytics 生成 |
| 外部观察、对象映射与同步结果 | Channel | 对应内部 Owner 校验后执行命令 | 原始外部订单不是内部订单；账单观察不是已验证结算 |
| 分析指标、派生事实、质量问题 | Analytics | 带口径、来源和新鲜度只读使用 | 指标不能修改或替代即时业务事实 |
| 推荐决策、规则实验、获客归因 | 尚未完整收敛，见 Q-03/Q-04 | 仅将已明确内容、偏好和交易事实留在各原 Owner | 不能因无归属就交给前端、Platform 或 Analytics |
以上是有限事实族盘点，不是所有字段与对象的覆盖证明。下一层模型设计须继续展开；不得据表中没有列出某对象就默认归属。
2. 四类数据必须区别
| 类别 | 责任 | 例子 | 演进要求 |
|---|---|---|---|
| 源事实 | Owner 定义和变更 | Customer 地址簿 | 版本化合法更新 |
| 不可变业务快照 | 接受该承诺的 Owner 保存 | Order 成交地址、规格 | 保存来源与版本，不跟随主数据回写 |
| 投影/组合视图 | 明确派生维护者 | 订单旅程、Customer 360 | 标明来源、新鲜度、授权及重建方式 |
| 外部/现场观察 | 接收方保留，事实 Owner 判断 | 支付回调、称重观察 | 验证、接受后才形成相应业务事实 |
订单详情可以组合 Commerce、Fulfillment、Supply 等查询，但不得输出一个未经解释的全局 status 抹平差异。聚合视图需明确组合失败与过期字段，不得将缺少结果当作“未发生”。
3. 技术底座的职责
Platform 提供文件、幂等、消息、回执、作业调度、审计和异常工作台等机制。它有技术资源的生命周期，但不拥有“允许取消订单”“退款成功”“质量放行”等业务语义。
本轮把 Platform 登记为横向技术边界；旧文档称其 Generic BC，此术语差异不改变实际职责。是否进一步拆成若干技术上下文留给公共基线设计，不把它算作第十一个业务子域。
- 业务 Outbox 内容与业务变更需要在该 Owner 的本地事务一致；平台负责机制，不能先写业务成功再侥幸补发事件。
- 技术去重不替代业务唯一性：不同请求键仍可能对应同一周期订单或同一退款目标。
- 异常工作台可以分派、记录和调用已登记恢复命令；最终是否恢复由业务 Owner 的事实与下游证据证明。
- 业务异常的监控入口按已设监控项产生告警，自动创建处置工单并按值班路由分派。Platform拥有监控事件、工单和分派记录；监控条件及恢复证据的业务语义仍由源Owner定义。重复检测应归并同一事件，告警恢复、工单关闭与业务完成分别记录；无值班人、建单/通知失败不能吞掉告警。真实排班、升级和等待预算见D-07；客户检索不要求创建工单。
- 上述业务告警由通用监控平台承载，不是另一个专用告警系统。平台拥有接入登记、规范策略、编译发布、技术事件与处置执行；业务/技术接入方拥有源语义和合法动作。通用响应可组合通知、工单与自动化；鼎味场景按要求自动建单。Analytics仅提供分析信号与口径，不另建通知/工单/自愈生命周期。接入绑定见鼎味场景包，平台合同与运行缺口归D-15。
- 文件是否可用归技术文件能力；证据是否足以支持退款或质量放行归相应业务 Owner。
- 通知投递失败不抹去已成立的订单或退款事实；关闭流程是否需要通知证据由具体业务规则定义。
4. 受控共享语言
本轮对象身份和基数的主讲为交易级严谨性。上述新增项仍是候选边界，但不是无 Owner 的平台功能；政策与长期实际负责人未定，不得据表格自动冻结合同。
公共 ID、单位、金额、时间、版本、消息信封、错误及权限标识后续需单一定义。本层规定归属与含义，不提前冻结字段。
特别检查同名词：登录 Account 与会计 Account、商业订单与履约接收件、资金 Settlement 与会计过账、业务 Case 与异常工作台 Case、SupplyPosition 与 Capacity。这些应当用有上下文的名称映射，禁止为了“全局统一”错误合并。