cross-document-verification

name	cross-document-verification
tier	meta
description	建立"跨文档核查的 rule-skill / workflow"——即判定依赖于多份文档中事实的规则。在编写或蒸馏一条需要跨文档比对实体/数值的规则时使用（主合同 + 附件、贷款申请 + 收入证明 + 银行流水 + 征信报告等）。涵盖：规则定义里必须明确的几个锚点（源文档 → 实体 → 目标文档 → 实体 → 一致性等级）、由此生成的 check.py / workflow 怎么遍历一个 case、要处理的矛盾类型、严重性分级。和 `compliance-judgment`（单文档规则）区分——KC 是 builder，不是 executor。

Cross-Document Verification —— 构建跨文档规则

KC 在这个阶段的工作是构建跨文档核查规则，不是在运行时执行跨文档检查。最终交付物是一条 rule-skill / workflow，将来可以被 KC 或下游系统应用到任何 case。

如果一条规则的判定依赖多份文档中的事实，这一事实就必须显式编码到规则本身。你不能写一个单文档 check.py，然后期望跨文档核查在生产时凭空发生。

规则定义里必须写清楚什么

对一条跨文档规则来说，目录条目仅有 description + falsifiability_statement 不够。它需要一条显式的跨文档路径：

1. 起始文档类型：从哪类文档开始？怎么把一份文档判定为这类？（比如"贷款申请表"、"主合同"、"年度信息披露报告"）
2. 起始文档中的锚点实体：先抽什么？（申请人 ID、借款人姓名、合同编号、申报总金额等）
3. 目标文档类型：要跨核到哪类文档？在同一个 case 里怎么定位目标文档？（共享 anchor、命名模式、起始文档里的显式引用）
4. 每个目标文档中的目标实体：从目标文档里抽什么来比？字段名不一定相同 —— "月收入"在申请表上、"月均存款"在银行流水上。
5. PASS 的一致性等级：在什么条件下我们判定为一致？精确相等？容差内相等？合理性检查（在另一个值的某个倍数范围内）？互引存在？
6. FAIL 是什么样：硬冲突、软矛盾、还是缺失互引 —— 各自带什么严重性。

少了这五个锚点，规则就只是个愿望。有了这些，生成的 check.py 才能确定性地遍历 case。

与 compliance-judgment 的分工

compliance-judgment 处理单文档规则：读一份文档，应用规则，给出 verdict。判定可以是正则、确定性 Python、或 LLM 增强 —— 但输入是 一份文档。

本 skill 处理输入是一个 case（一组相关文档）的规则。这类规则的 check.py：

• 接收 case 级结构（文档列表 + 元数据），不是单份文档。
• 在相关文档上跑实体抽取。
• 为这条规则构建必要的对比矩阵（只包含这条规则关心的字段，不是 "所有实体 × 所有文档"的通用矩阵）。
• 应用规则定义里写明的一致性检查。
• 返回 verdict 加上驱动结论的矩阵单元（证据）。

KC 是构建者，构建这个 check.py / workflow，不是运行时执行者。下面的内容讲的是要设计什么，不是运行时要做什么。

要面向的 case 模式

两种模式覆盖了大多数跨文档规则：

1. 主合同 + 附件。同一签发方，正式互相引用。主合同写总额，附件列明分项。要预期的问题：总额和分项加总不一致、引用的附件缺失或过期、主文与附件版本不匹配。

2. 多源捆绑。贷款申请 + 收入证明 + 银行流水 + 征信报告 + 评估报告。不同签发方、不同格式、同一借款人/case。要预期的问题：身份信息在多份文档间漂移（姓名拼写、雇主名变体）、数值矛盾（申报收入 vs 实际收入）、可疑的一致性（多份文档版式 / 用语一致 → 可能是伪造）。

编写规则时点明它针对的是哪种模式。两种模式下 check.py 的形状不同 —— 主合同 + 附件这种期望正式引用和互引；多源捆绑这种期望做归一化（跨格式的实体协调）。

矛盾分类（规则可能需要检测的）

跨文档规则可能需要标记其中一类或多类：

硬冲突

应跨文档完全一致的字段出现精确不匹配。

• 身份字段不匹配（姓名、ID、出生日期）。
• 容差以外的金额不匹配（总额、分项、申报收入）。
• 应一致的日期不匹配（生效日期、签署日期）。

硬冲突是二元的：要么匹配（在定义的容差内），要么不匹配。

软矛盾

没有直接冲突，但放在一起看不合理的数值。

• 申报月收入是某水平，但银行流水月均存款显著低于此。
• 评估价接近贷款金额（高 LTV —— 技术上可行，但是信号）。
• 不同文档间出现多月的就业起始日差距。

软矛盾需要阈值和判断。它们是发现，不是判定 —— 规则需要明确：触发 FAIL，还是 WARNING，还是仅作为证据收集供下游复核。

互引失败

正式联结文档内部的结构完整性问题。

• 主合同引用"附件 B —— 还款计划"，但附件 B 缺失或标题不同。
• 附件引用主合同某个不存在的条款。
• 缺失互引：附件引用了主合同，但主合同里没列附件。
• 版本不匹配：主合同某日期签署，附件晚得多的日期签署且条款不同。

字段级分类（带容差和严重性模板）见 references/contradiction-taxonomy.md，规则设计者可以借用。

严重性分级（由规则决定）

不是所有矛盾权重相同。规则必须说明它的发现如何映射到严重性：

严重性	典型例子
Critical	身份字段不匹配（多份文档间 ID 不同）
High	显著的金额数值差异
Medium	日期或就业细节不匹配
Low	格式 / 缩写差异（"ABC Corp" vs "ABC Corporation"）

具体阈值取决于业务领域。开发者用户按字段配置；规则设计应给配置留出空间，而不是把百分比写死在规则里。

规则可以揭示的欺诈信号

有些模式只有在 case 层面才能看到：

• 跨文档的一致小幅差异：每份文档都"夸大约 5%"、每个日期都精确平移一个月。这种一致性错误暗示有协调的伪造，不是诚实的笔误。
• 可疑的文档一致性：声称来自不同签发方的多份文档，使用相同版式、相同措辞、甚至相同的错别字。
• 数值卡在监管阈值上：LTV 正好压着上限，DTI 正好压着上限。一次是巧合；case 上的模式就是信号。
• 时间上的不可能：收入证明早于就业起始日；银行流水覆盖账户开立之前的期间；评估报告日期晚于贷款发放。

如果规则的工作包含这些之一，就编码进去。这些是升级信号，不是结论 —— 规则应输出"已标记"加证据，由开发者用户或下游复核流程做最终判定。

在 check.py 里怎么"走" case

一条跨文档规则的 check.py 通常这样工作：

1. 接收 case（文档路径/句柄列表 + 分类元数据）。
2. 选出规则声明的起始文档类型对应的文档。
3. 用 entity-extraction 抽出锚点实体。
4. 通过锚点或正式引用在 case 中定位目标文档。
5. 从每份目标文档抽出目标实体。
6. 应用规则写明的一致性检查。
7. 返回：
   • verdict（PASS / FAIL / WARNING / NOT_APPLICABLE）
   • 证据（驱动结论的对比矩阵单元，带来源文档 + 页码引用）
   • confidence（按 confidence-system）

对比矩阵是规则专属的 —— 只放这条规则需要的字段。建一个通用的 "所有实体 × 所有文档"矩阵又贵又会污染证据。

集成

规则 check.py 的运行时输入：

• case 结构（一组相关文档 + 标识）。
• 单文档实体抽取结果（skill：entity-extraction）。
• 单文档判定结果可能已经由 compliance-judgment 产出，可作为本规则输入的一部分。

输出：

• case 级 verdict + 对应的对比矩阵切片作为证据。

对接：

• confidence-system：跨文档矛盾是强信号，通常降低相关字段的置信度。
• evolution-loop：规则没预见到的矛盾模式反复出现时，触发工作流改进。
• dashboard-reporting：case 级视图与单文档结果并列展示。

Ground-truth 原则

当开发者用户或终端用户反馈本规则漏掉的跨文档不一致时，那条反馈优先于 agent 判定。把它记下来，作为 corner case （corner-case-management）或规则改进的触发点，并相应调整检测阈值。规则的工作是抓住人能抓住的 —— 然后再走远一步。