研究事件去重：合并同一事项，保留不同原文
事件去重应合并事项，不应删掉证据路线。多份文件可能描述同一事件，一份申报也可能包含多个事件。分别建立文件ID和事件ID，才能避免重复发布被误解为多次进展。
W3C来源追踪提供对象和活动关系的背景；披露易则是需要保留文件身份的发布入口之一。下面的事件键设计是手工约定，不是通用标准编号。
合并前先比较含义
用法律主体、事项主题、事件阶段和相关日期匹配。单靠标题很弱：“项目进展”可能在每个阶段反复出现，网站日期变化也可能只是旧稿转载，不是新进展。
应问两份材料是否描述同一次发生和同一状态。签约与完成是同一交易的不同阶段；签约通知的译文是同一事件的另一文件；更正则应建立版本关系，明确哪些事件字段变化。
假设案例：一项交易的多份材料
假设虚构的溪线仓储通过多个渠道发布交易信息。以下完全为假设。
| 新材料 | 处理方式 | 原因 |
|---|---|---|
| 原始签约公告 | 新事件及来源 | 首次检查的签约证据 |
| 官方另一语言版 | 同事件，新来源对象 | 文件不同，发生相同 |
| 新闻转载 | 同事件，辅助来源 | 分发不等于新进展 |
| 签约日期更正 | 关联更正并检查影响 | 版本改变一个字段 |
| 后续完成公告 | 新阶段，连接原交易 | 发生与状态不同 |
结果可以是一项交易下的签约和完成两个阶段，各连接相应来源，而不是五个无关事件。也不能只留一行不断覆盖，否则更正与披露历史会丢失。
不确定匹配继续保留
两份文件可能属于同一项目，但身份还不明确时，把关系标为暂定，分别保留来源并写下缺少什么匹配证据。不能仅为界面整洁或减少数量，就删除疑似重复。
手工合并时留一条记录，写合并对象、理由、日期和撤销方式。后来发现匹配错误，可以拆分事件并保留来源关系。项目名称在不同阶段或子公司间重复时，这种可逆处理尤其有用。
用重建测试核对计数
选一个合并事件，列出所有来源，解释每个为什么属于它，以及有没有引入新阶段。再选一个文件，列出支持哪些事件。双向检查能同时发现重复计数和误删事项。
独立观察与分发副本应分别计数。两个官方语言版本有助语言核对，却不因此成为两次独立确认。单独监管决定可能增加独立证据，但也只支持它实际确定的内容。
边界与常见错误
事件分组是资料组织决定，不能证明因果关系、法律等价或底层陈述准确。主体关系不清时，应保留范围疑点，不要强行合并。
常见错误包括只按标题去重、删除译文、每份申报只允许一个事件，以及把签约与完成混合。还有用文件哈希作为事件键：相同字节能识别副本，不同文件却仍可能描述同一事项。文件层和含义层关系要同时存在。
再做一次记录检查
事件数量有用途时，应留下可撤销的合并说明，列来源ID及共享阶段。后来段落显示某文件属于另一设施或子公司，就拆分并保留理由。数字整齐不如分类可查、可改重要。还应区分新增文件和新增事实：译文到来会增加文件行，却不一定增加事件；完成公告可能增加阶段，即使沿用原项目名称。把这种计数规则写在清单说明中，避免不同人用相同数字表示不同含义。
常见问题
重复文件应该直接删除吗？
若对证据路线重要，应先保存身份和关系。去重的目标是减少重复工作，而不是隐藏材料从哪里来。
一份文件能属于多个事件吗？
可以。申报可能谈多个无关发展，应把具体段落连接到事件，而不是强迫整份文件只有一个类别。