Litigation Chronology Builder

---
name: litigation-chronology-builder
title: 案件事实时间线构建
description: 当需要从诉讼文档（举证材料/调查/卷宗/邮件/合同）抽取带日期事件、构建或更新案件事实时间线（chronology/timeline）时使用；做按案件理论抽取、去重、标注重要性与特权状态的时间线及事实陈述骨架；不适用于无源臆造事件、替律师裁断特权或矛盾、保证完整性；触发词：时间线、事实时间线、chronology、timeline、案件年表、统计事实、事实陈述、statement of facts、举证时间线、证人时间线。
domain: 领域/legal
triggers: [时间线, 事实时间线, chronology, timeline, 案件年表, 梳理事实, 事实陈述, statement of facts, 举证时间线, 证人时间线, 什么时候发生了什么, what happened when]
tags: [legal, litigation, chronology, timeline, ediscovery, privilege, fact-extraction]
level: 进阶
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: [markdown]
requires: []
related: [deposition-outline-prep, legal-hold-manager, diligence-issue-extractor, privilege-log-reviewer]
combines_with: [deposition-outline-prep, legal-hold-manager]
license: Apache-2.0
source: anthropics/claude-for-legal
source_license: Apache-2.0
---
## 何时使用

当用户要从一批诉讼文档（举证材料、调查/披露产出、卷宗、邮件、合同、备忘录）抽取**带日期的事件**、构建或增量更新**案件事实时间线**，或需要一份用于书状事实部分的**事实陈述（SoF）骨架**、**证人专属时间线**时使用。典型说法：「从举证材料里整理时间线」「什么时候发生了什么」「梳理一下案件事实年表」。

**不该用的边界（直接拒绝或转交）：**
- 不臆造文档里没有的事件。源里没有、且未由用户在会话中提供为事实的，一律不进时间线（但可在「缺口」里点名为缺失）。
- 不替律师裁断**特权状态**或解决**事实矛盾**——这些只做首轮标注并打 `[SME VERIFY]`，最终判断归律师。
- 不保证完整性——产出只反映已获取的源；披露未完成就如实说明。
- 不静默补源：覆盖偏薄时停下来问，不得用网搜/模型记忆填补而不声明。

## 步骤

固定 6 步，**第 0 步特权门必须最先执行、每次都执行**：

- **Step 0 特权门（强制）**：抽取前先问源的特权筛查状态，三选一并记入产出头部 `特权状态`：A=已全部清核（无特权标记、按可披露姿态产出，仍标工作成果）；B=混合/未筛查（逐条打 `priv` 标记并默认在 SoF 变体中过滤掉特权条目）；C=中止先筛查。门而非警告——把姿态决定固化进文件，使每份时间线自带来源凭证。
- **Step 1 识别文档源**：按优先级——本次会话用户提供的路径/链接 → 默认卷宗目录 → 已声明的文档存储源（云盘、邮箱、eDiscovery 平台）/ Bates 举证集 / 按保管人+日期区间拉取。源偏薄就追问关键邮件、合同、内部备忘、举证函。
- **Step 2 读取**：PDF/.eml/.docx/.txt 直接读；邮件归档与 eDiscovery 平台（Everlaw、Relativity、DISCO、Aurora）有连接器则按日期区间+对手方/保管人查询，否则让用户导出。**读不到的源在「缺口」里点名，不得静默略过。**
- **Step 3 抽取事件**：每文档识别带日期事件（邮件/会议/决策/立案/外部事件，见下方格式）。通常一文档一事件，偶尔零或多。仅当 `特权状态==B` 时逐条打三态 `priv` 标记（见指令）。
- **Step 4 去重合并**：同一事件出现在多个文档（如一场会议在三份日历+一封纪要邮件里）= **一个事件、多个来源**，合并后引用全部来源，不拆成多条。
- **Step 5 按案件理论标重要性**：读枢轴事实与关键事实，逐条标 🔴关键 / 🟡相关 / ⚪背景。
- **Step 6 写出**：默认写**工作时间线**；按需出 SoF 变体、证人变体。已有旧版则做增量 diff、版本号 +1。

收尾向用户确认：「这是我构建的结果。请扫一遍 🔴 条目——有没有我标错的？」

## 指令

**来源归属（每条必带）**：文档抽取的事件在「来源」列写文件路径/Bates/连接器。无法溯源到已获取文档的，**行内打可溯源标签**：`[网搜——待核实]` / `[模型知识——待核实]` / `[用户提供]`。带 `待核实` 的伪造风险更高，应优先核。**绝不删除或合并这些标签。**

**标签覆盖一切法律结论**：缺口、关键事件、理论关联、以及任何时效/中止/立案期限/举证截止/特权判定，凡是「关于法律的断言」（而非「关于文档写了什么的断言」），都必须带与时间线条目同样的来源标签；无标签的时效窗口默认按 `[模型知识——待核实]` 处理。

**事件抽取格式**：
- 邮件：`[日期] [发件人] 告知 [收件人] [主题/内容]`
- 会议：`[日期] [参会人] 就 [议题] 会面`
- 决策：`[日期] [决策人] 决定 [内容]`
- 立案/诉状：`[日期] [当事方] 提交 [动议/起诉状/答辩]`
- 外部事件：`[日期] [发生的事]`（签约、产品上线、监管行动、跨过某阈值）

**逐条特权三态（仅当 `特权状态==B`，绝不静默判定主观特权测试不成立）**：
- `priv: ok` —— **确信**非特权（公开文件、监管往来、不含我方律师的对手方通信）。仅在无任何可信特权理论时使用。
- `priv: flag` —— 确信或很可能特权（与律师的通信、工作成果备忘、特权草稿、联合抗辩材料）。**一切不确定的默认归此**。
- `priv: review` —— 表面不清且完全无法判断（缺收发件元数据、不可读等）。
- `flag`/`review` 时行内加 `[SME VERIFY: privilege status]`。漏标会弃权（单向门），多标由律师在审阅时纠正（双向门）——**宁可犯可恢复的错**。

**重要性纪律**：300 条全标 🔴 等于没标。🔴 只留给真能打动事实裁判者的事件，拿不准就降到 🟡。介于两档之间的标低档并行内加 `[SME VERIFY — borderline significance call]`。

**攻防视角**：原告（进攻视角）🔴 标确立请求权要件/堵防御缺口/起算对己有利时效的事件；被告（防御视角）🔴 标打断要件/开启时效或管辖抗辩/支撑积极抗辩的事件。底层时间线是中立的，仅重要性解读随视角变。在产出顶部注明：`重要性标签按 [原告/被告] 视角应用`。

**披露文档使用限制（开工前先问）**：「这些文档是否通过诉讼披露/证据开示取得？」若是——英格兰及威尔士 CPR 31.22 默示承诺：仅可用于披露所在的诉讼，他用可能构成藐视法庭；美国适用保护令与 Rule 26(c)，查阅相关命令。未确认则标 `⚠️ 披露文档可能有使用限制，确认本次使用获许可前勿继续`。

## 示例

工作时间线（默认产出）核心结构：

```markdown
[工作成果头 — 按角色]

> 特权继承提示：本时间线源自可能受特权保护的文档，继承其保护状态。
> 越出特权圈分发（业务方、对方律师、监管）可能对本表及底层来源造成弃权。

# 时间线 —— [案件名]

> 重要性标签（🔴/🟡/⚪）与特权标记（🔒）均为首轮判断，外部使用前需 `[SME VERIFY]`。

**案件:** [slug]  **构建:** [YYYY-MM-DD]
**来源:** [N] 份文档  **条目:** [N]（[N]🔴 / [N]🟡 / [N]⚪）
**枢轴事实:** [一句话]
**特权状态:** A-cleared | B-mixed | C-aborted

## 时间线
| 日期 | 事件 | 标签 | 🔒 | 来源 |
|---|---|---|---|---|
| YYYY-MM-DD | 一句话事件 | 🔴/🟡/⚪ | 空/🔒-flag/🔒-review | 路径或 Bates |

## 关键事件（仅 🔴）
### [日期] — [标题]
- 是什么: [一行]
- 理论关联: [为何重要]
- 来源: [列表]

## 缺口
**无事件的日期区间 / 应有却缺失 / 不可读的源**（逐项点名）

## 版本
- v[N] 于 [日期] 基于 [来源摘要] 构建
```

**SoF 变体**：仅保留 🔴 与相关 🟡，按时间顺序写成叙述性散文（书状事实部分骨架），每段一个事件并附记录引用。`特权状态==B` 时 🔒-flag / 🔒-review 条目**默认排除**；要强行纳入须显式 `--include-flagged` 确认，并把确认记入头部作永久记录。

**证人变体**：仅保留某具名证人作为发件人/收件人/参会人/主题的事件，用于证人准备、还原「证人当时知道什么」。

## 注意事项

- **特权门不可绕过**：任何抽取前必须先定姿态并记入头部；这是每份文件自带来源凭证的关键。
- **覆盖偏薄不静默补**：源返回事件数偏少时报出实况并停，给用户四选项（指更多源 / 换连接器 / 网搜公开记录并打 `[网搜——待核实]` / 就此停下记缺口），由律师决定是否接受低置信源。
- **不解决矛盾**：两文档对同一事件日期不一致时，两条都进并打标，留给律师裁断。
- **增量构建保留旧版**：已有 `chronology.md` 则读旧版、按当前源重建、做 diff（新增/修改/删除并注原因）、保留旧版本号、新版写 `v[N+1]` 并输出变更摘要。
- **与内部日志分离**：内部行动（如发出文档保全令、储备金备忘）归内部 `history.md`，不进事实时间线；只有作为争议事实的事件（如对方 3 月 14 日发出违约通知，🟡 确立其知情）才进时间线。
- **冲突门（matter 模式）**：若案件未在 `_log.yaml` 登记，拒绝构建并指引用户先跑案件立项流程（冲突检查是前置门）。

## 互见

- `fact-checking`：对带 `待核实` 标签的条目做事实核查与溯源验证。
- `markdown-to-docx`：把工作时间线或 SoF 骨架转为可交付的 Word 文档。
- `first-principles-thinking`：拟定案件理论、判定事件对要件的攻防意义时辅助推理。

---

本条采编自 anthropics/claude-for-legal（Apache-2.0）。