01
接收：事实携带业务键
02
占位：创建未知待补成员
03
加载：事实关联占位键
04
回填：主数据到达后更新
05
审计：记录影响与重算范围
结论：先保留事实，再补齐维度上下文
流式交易、接口重试和批次延迟会让订单早于客户或商品主数据到达。拒绝事实会造成漏数，关联统一未知成员又会失去后续匹配线索。
使用携带来源业务键的占位维度成员承接事实。
占位成员必须可区分
为每个未解析业务键创建占位记录，标记来源、首次出现时间和待补状态，而不是所有事实都指向同一个未知键。
真正缺失业务键的事实仍使用通用未知成员，两种质量问题应分开统计。
主数据到达后选择更新策略
若占位对应的实体确定，可补齐同一代理键，事实无需重写；若匹配错误或出现多个候选，需要合并、拆分或重新关联。
慢变维度还要判断新属性从事实发生时还是主数据到达时生效。
下游结果要知道完整度
报告显示待补维度事实数量和金额，避免用户把“未知客户”误解为真实业务分类。回填后识别需要重算的聚合、缓存和导出。
已发布结果若变化，应保留版本和影响说明。
用乱序数据验收
模拟事实先到、维度先到、重复到达、错误业务键、实体合并和跨日回填，检查幂等、唯一性、历史与重算。
BuildTable 可作为数据模型治理候选；占位生成、实体匹配、影响分析和回填编排能力需逐项确认。