8.4 · 验证流程
已发生 ≠ 已确认。只有走完验证链，结果才进入 PoB 账本并成为长期价值输入。
链上共识确认的是交易顺序与状态转换；PoB 确认的是「这件事在商业世界中是否如声称那样发生」。验证流程把主观叙事压成可审计工作流：材料齐全度、时间一致性、归因自洽、与排除规则（8.3）的对照。
验证五步（工作流视图）
① 事件提交
为终态生成唯一事件编号，绑定 Deal、Task、相关节点与声明类型（融资/服务/增长等）。提交即承担举证责任：材料缺口由提交方在时限内补齐。
② 证据包上传
按模板提交合同、链上引用、银行/托管路径（合规脱敏）、邮件/纪要、验收单等。类比 GIPS：数据应足以让独立方在合理努力下复核结论，而非仅「信任申请人」。
③ 审核队列
审核方核查：真实性（与第三方或链上是否一致）、完整性（终态是否闭合）、时间序（是否倒签）、归因边界（是否与 8.5 冲突）、排除规则（是否落入 8.3）。可与多签、轮换或抽样审计结合。
④ 结论生成
通过 / 补件 / 驳回 / 争议升级。补件应有次数与时限，防止无限拖延；争议应保留异议记录，避免「沉默即通过」。
⑤ 归档入账
通过后写入 PoB 事件账本（含结论哈希、关键元数据与版本）。该记录类似经审计的业绩条目：可成为后续结算、声誉与再验证的锚点。
与 PoW 对比：矿工证明的是算力工作；PoB 审核证明的是材料与事实的一致。与 PoA 对比：PoA 信任验证者身份；PoB 仍要求证据包，审核者身份不替代材料。
Proof Desk：验证中台，不是网盘
收证据结构化字段 + 附件版本；避免聊天窗口丢文件导致不可审计。
管审核队列优先级、SLA、双人复核或抽检规则可治理化。
保留争议空间异议与裁决理由留痕，便于事后复盘与规则迭代。
输出结论明确终态：是否进入 PoB；未通过则不得进入长期价值分配语义。
反作弊在流程层的落点
- 交叉核验：链上时间、第三方邮件域名、合同编号与公开披露是否一致。
- 互斥事件：同一融资轮次、同一验收标的仅允许一条已归档主导链，除非裁决拆分。
- 冷却与频率：异常高频、模板化材料触发人工或算法辅助审查。
验证流程把 WCN 从「谁嗓门大」推到「谁材料硬」。没有这一步，PoB 与链下 Excel 记功劳无异，且更易被篡改。