| name | rule-graph |
| tier | meta-meta |
| description | Build and maintain a graph of relationships between verification rules — shared entities, logical dependencies, and conflicts. Use when analyzing the impact of a regulation change, when optimizing extraction to avoid duplicate work, when checking rule catalog completeness, or when rolling up document-level results into a summary. Critical constraint — the graph is an overlay for analysis, NOT a prerequisite for execution. Every rule must remain independently runnable. |
规则关系图谱
规则不是孤立存在的。它们共享提取实体、彼此之间存在逻辑依赖、有时甚至相互矛盾。规则关系图谱把这些关系显式化，让你能把规则目录作为一个体系来分析，而不只是一个扁平的清单。
但图谱也可能变成陷阱。如果规则脱离了图谱就跑不了，那你就建了一个单体系统。图谱是分析的透镜——永远不能成为执行的闸门。
独立性优先——铁律
每条规则必须独立可执行。 这不是建议，这是规则图谱设计中最重要的约束，没有之一。
企业系统多数是基于规则的。银行的现有合规平台会单独调用规则 R001 检查资本充足率，完全不涉及其他规则。如果 R001 要求先跑 R003 才能执行，集成就断了。如果 R001 要求加载整张图谱，集成也断了。
这个约束来自实际的企业集成场景：
- 信贷审批系统可能只调用与当前业务类型相关的 3-5 条规则，而不是全部 50 条
- 监管报送系统可能只关心资本充足率相关的规则，不需要尽调类规则
- 不同部门可能使用不同的规则子集——风控部用风险类规则，合规部用披露类规则
- 规则可能被嵌入到现有的 BPM（业务流程管理）系统中，作为一个节点被调用
在所有这些场景中，规则必须是自包含的。它的工作流收到输入（文档或提取结果），产出判定结果，不依赖任何其他规则的运行状态。
图谱是叠加层（overlay）。 它为编程智能体的分析和优化服务，不在规则之间创建硬依赖。任何一条规则，从图谱中取出来、放到一个独立系统中，必须能仅凭自身输入产出正确结果。
当你发现真正的依赖关系（规则 B 只在规则 A 判定通过后才有意义），把它编码为图谱中的元数据。规则 B 的工作流必须处理规则 A 结果不可用的情况——要么自行内联计算，要么将 A 的结果作为可选输入接受，要么标记自身结果为 incomplete。
图谱捕获的四类关系
共享实体（Shared Entity）
多条规则从同一文档区域提取同一实体。
示例： R001（资本充足率核查）和 R004（核心一级资本充足率核查）都需要从资产负债表中提取资本数据。图谱记录这个共享关系，优化器可以提取一次、多处复用。
银行监管规则中常见的共享实体：
- 资本数据（资本充足率、核心一级资本充足率、杠杆率都需要）
- 不良贷款数据（不良贷款率、拨备覆盖率、拨贷比都需要）
- 资产负债表数据（多个流动性指标共享）
- 贷款基础信息（金额、期限、利率被多条审查规则引用）
但共享提取是优化手段，不是必要条件。每条规则的工作流必须包含自己的提取逻辑作为默认路径。共享提取是规则批量运行时可以走的快速路径。
逻辑依赖（Logical Dependency）
规则 B 只在规则 A 的结果满足某个条件时才适用。
示例：
- 「如果借款人被评定为高风险客户（R012），则需要增强尽调文件（R013）」
- 「如果贷款金额超过 1000 万（R020），则需要经分行审批（R021）」
- 「如果抵押物为住宅房产（R030），则按住宅 LTV 上限核查（R031）；如果为商业地产（R032），则按商业 LTV 上限核查（R033）」
图谱捕获这些依赖，用途是：
- 展示结果时，R013 在 R012 的上下文中呈现
- R012 的逻辑变更时，你知道 R013 可能受影响
- 完整性检查时，确保条件分支的所有路径都有对应规则
但 R013 的工作流必须在 R012 结果不可用时仍能运行——要么自行判断高风险分类，要么标记为「无法确定适用性」。
规则冲突（Conflict）
两条规则可能产生矛盾的指导。
示例：
- 监管要求 A 要求披露所有关联交易明细；监管要求 B 的隐私条款限制某些交易细节的披露
- 总行风控政策要求 LTV 不超过 70%；地方分行的灵活政策允许特定园区项目 LTV 放宽至 80%
- 旧版监管文件要求拨备覆盖率 ≥ 150%；新版过渡期政策暂时放宽至 ≥ 120%
图谱标记冲突，让编程智能体上报给开发者用户决策，而不是默默选择其中一条。冲突不是 bug——它是现实监管环境中的常态，需要人来裁决优先级。
冲突处理原则：
- 时间优先：新规优先于旧规，但要注意过渡期安排
- 层级优先：上位法优先于下位法（银保监会 > 地方银监局 > 行内制度）
- 特别法优先：专门规定优先于一般规定
- 无法确定时：上报开发者用户，附上两条规则的原文和矛盾点
共享角落案例（Shared Corner Case）
影响多条规则的边缘情况。
示例：
- 文档中的合并单元格导致多条规则的表格提取失败
- 非标准日期格式（如「二〇二四年元月」）影响所有涉及日期的规则
- 某类特殊业务（如银团贷款）的文档结构与常规贷款不同，影响多条审查规则
图谱关联这些规则到共享的角落案例，一处修复、多处感知。
项目术语表（Glossary）
术语表由 rule-extraction 构建并维护，存放于 rules/glossary.json。它是规范化标签的注册中心——shares_entity（共享实体）边能否成立，全靠它。没有术语表，两条规则可能针对同一个实体却用不同名字，它们之间的边就永远画不出来。
涉及实体的边应该引用术语表中的规范化标签，而不是从规则描述中复制粘贴的自由文本：
{"from": "R001", "to": "R004", "type": "shares_entity", "entity": "registered_capital"}
其中 registered_capital 是 glossary.json 里的规范化名称，注册资本、paid-in capital、实收资本 作为别名记录在该条目下。
术语表更新时——发现新别名、合并两条目、修订定义——回过头检查受影响的 shares_entity 边。新别名可能让原本隐藏的跨规则关联浮现；合并的条目会把平行的边收敛为一条。
术语表由 rule-extraction 构建和持有，rule-graph 只是消费方。
四个用途
1. 影响分析（Impact Analysis）
监管规则变更时，哪些核查规则受影响？从变更规则出发遍历图谱：
- 一度关联：与变更规则共享实体或有依赖关系的规则
- 二度关联：依赖于受影响规则的规则
- 冲突关联：冲突解决方案可能需要重新审视的规则
实际场景： 银保监会修订了资本充足率的计算口径。从 R001（资本充足率）出发：
R001（资本充足率）
├── shares_entity → R004（核心一级资本充足率）—— 共享资本数据，可能受影响
├── shares_entity → R007（杠杆率）—— 共享资本数据，可能受影响
├── depends_on ← R015（综合评级）—— 使用 R001 结果，需要重新测试
└── conflicts_with → R050（过渡期政策）—— 冲突解决规则可能需要更新
没有图谱，影响分析需要逐条阅读所有规则查找关联。有了图谱，它是一次遍历。
2. 优化（Optimization）
批量处理文档时，图谱帮助识别优化机会：
- 共享提取：实体 X 只需提取一次，供 R001、R004、R007 使用
- 执行排序：如果 R012 先于 R013 运行，R013 可以复用 R012 的结果作为快捷路径（但绝不能依赖它）
- 并行分组：没有边连接的规则可以并行运行
示例： 50 条规则中，通过共享实体分析发现：
- 资本相关实体被 8 条规则共享 → 提取一次，节省 7 次重复提取
- 贷款基础信息被 15 条规则共享 → 提取一次，节省 14 次
- 无关联的 20 条规则可以完全并行
优化是投机性的（opportunistic）。它让批处理更快，但绝不能让单条规则依赖于批处理上下文。一条规则被单独拉出来运行，必须照样能工作。
3. 完整性检查（Completeness Checking）
将法规条文段落映射到规则。图谱帮助识别：
- 未覆盖段落：法规中有实质性要求但没有对应规则的段落
- 过度覆盖段落：被多条重叠规则覆盖的段落（潜在冗余）
- 覆盖率目标：实质性法规段落中至少 95% 映射到至少一条规则
完整性检查是规则目录的健康指标。覆盖率低说明提取不充分；重叠高说明规则粒度可能需要调整。
4. 文档级结果汇总（Document-Level Rollup）
展示一份文档的多规则核查结果时，用图谱实现：
- 分组展示：资本充足率相关规则放在一起，信息披露规则放在一起
- 依赖排序：R012（风险分类）展示在 R013（增强尽调）之前
- 冲突高亮：两条规则产出矛盾结果时，突出冲突关系而非淹没在平铺列表中
- 严重度聚合：5 条相关规则全部失败，这个集群的严重性可能高于 5 条不相关的失败
图谱表示方式
图谱存储为规则目录中的 JSON 邻接表。
{
"nodes": {
"R001": {"name": "资本充足率", "category": "资本监管"},
"R004": {"name": "核心一级资本充足率", "category": "资本监管"},
"R007": {"name": "杠杆率", "category": "资本监管"},
"R012": {"name": "借款人风险分类", "category": "风险评估"},
"R013": {"name": "增强尽调要求", "category"
边类型说明：
| 边类型 | 含义 | 用途 |
|---|
shares_entity | 两条规则提取相同实体 | 优化提取，减少重复工作 |
depends_on | 目标规则的适用性取决于源规则的结果 | 仅为元数据，不是硬执行依赖 |
conflicts_with | 规则可能产出矛盾指导 | 需要上报机制 |
shares_corner_case | 两条规则受同一边缘情况影响 | 一处修复、多处感知 |
图谱在规则目录发生变更时更新——新增规则、修改规则、废止规则。通过 dashboard-reporting 可视化为节点-链接图。
集成方式
输入： rule-extraction 产出的规则目录。图谱在规则提取完成后构建，随规则演化而更新。
赋能：
skill-authoring：编写新规则技能时，查图谱了解相关规则，在 SKILL.md 中注明共享实体和依赖关系。quality-control：某条规则准确率下降时，查图谱定位可能连带受影响的下游规则。
输出到：
dashboard-reporting：图谱可视化、影响分析结果、覆盖率指标。
注意事项
- 图谱的维护成本应该低于它带来的收益。如果规则数量少于 10 条，手动追踪关联关系可能比维护图谱更高效。
- 图谱不替代人的判断。它帮你发现关联，但关联的业务含义需要开发者用户确认。
- 新增规则时先查图谱——看它与哪些现有规则有关联，避免重复建设。
- 废止规则时也查图谱——确保没有下游规则依赖它的结果（即使是软依赖）。
