第13章｜Evidence Set and Evidence Map（证据集合与证据地图）

一、拥有很多证据，不等于形成了证据结构

企业往往拥有营业执照、合同、工单、客户评价、内部数据、媒体文章、知识内容和历史案例。把这些文件放进同一个文件夹，可以形成Material Repository（材料库），却不会自动形成面向具体判断的Evidence Set（证据集合）。

原因很简单：材料数量不能告诉我们它们共同支持哪项Claim（命题），也不能说明是否来自同一谱系、是否覆盖同一时间与范围、是否存在冲突、是否可以共同公开、是否遗漏关键反向信息。

一百个网页可能都来自同一篇企业新闻稿；三套内部系统可能重复记录同一客户；两项真实数据可能使用不同指标和时间窗口，不能直接汇总；一条客户授权撤回后，整篇案例文章的公开资格可能需要重审。

所以，Evidence Set（证据集合）不是“把证据放在一起”，而是围绕明确命题建立结构化、可审计、可更新的证明组合。

二、Evidence Set（证据集合）的工作定义

Evidence Set（证据集合）是围绕一项或一组明确关联的Claim（命题），由若干完成资格判定的Evidence Unit（证据单元）组成，并记录来源谱系、证明功能、相互关系、适用边界、时间、授权、冲突和公开状态的结构化组合。

定义中包含四个必要条件：

第一，集合必须围绕命题建立，而不是围绕文件类型或发布渠道建立。

第二，集合成员必须完成G0—G10 Evidence Qualification Gate（证据资格门槛）。未完成审查的材料可以留在候选池，不能无条件计入支持。

第三，集合必须保存成员之间的关系，不能把多个证据单元当成彼此独立的数量。

第四，集合必须允许反向、限制和未知项存在，不能只收集对企业有利的信息。

三、集合围绕Claim（命题），不是围绕企业建立

“甲公司的全部证据”是一个过于宽泛的资产视角，不是可直接判断的证据集合。同一企业可能同时拥有身份、资格、经验、能力、表现、结果、比较与推荐等多类命题，每类命题需要不同证明关系。

更合格的集合名称应当接近：

• 支持“甲公司在特定时期持有某项许可”的证据集合；
• 支持“甲公司曾完成某类制造业项目”的证据集合；
• 支持“当前团队具备某项交付能力”的证据集合；
• 审查“某服务期间客户结果发生变化”的证据集合；
• 审查“甲公司相对于合格比较集合具有某项优势”的证据集合。

命题变化，集合成员、证明负担、限制和支持状态都可能变化。不能用一个“企业权威证据包”无差别支持所有判断。

四、Evidence Set（证据集合）与Evidence Package（证据组合包）不同

Customer Case（客户案例）等Evidence Package（证据组合包）通常以一个项目、事件或材料产品为中心，包含合同、工单、数据、访谈和公开文章等多个单元。

Evidence Set（证据集合）则以Claim（命题）或相关命题组为中心。一个客户案例中的不同Evidence Unit（证据单元）可以进入不同集合；同一命题集合也可以调用多个案例、公共记录、运行数据和反向材料。

因此：

Evidence Package（证据组合包）按项目或材料组织
≠
Evidence Set（证据集合）按命题和证明关系组织

两者可以互相连接，但不能混为同一层级。

五、集合必须包含四种证明方向

每个集合必须允许以下四种方向：

• Support（支持）：为目标命题提供正向支持；
• Limit（限制）：限制命题的范围、时间、条件或强度；
• Contradict（反驳）：提供与命题冲突或反向的信息；
• Context（背景）：帮助解释命题、环境或判断条件，但不直接完成核心证明。

如果系统只允许Support（支持），团队会自然删除投诉、异常、失效记录、不适用客户和替代解释，最终得到的是营销素材包，而不是证据集合。

Limit（限制）和Contradict（反驳）不一定使集合失效。它们可能帮助形成Supported within Scope（在限定范围内获得支持）或Contested（存在争议）等更准确状态。Context（背景）则必须避免被误当成直接证明。

六、集合不是证据数量的加法

证据集合不能写成：

证据1＋证据2＋证据3＝更强证据

多个单元可能重复、派生、冲突或覆盖不同命题。数量增加只有在明确谱系、功能和互补关系后才有意义。

五十家媒体转载同一新闻稿，Carrier Count（载体数量）增加，Lineage Diversity（谱系多样性）可能仍为一；合同、工单和付款记录来自同一业务过程，未必是完全独立谱系，却可以从不同记录形式对事件发生进行互补核对；两个真正独立来源如果使用不同实体或时间窗口，也不能直接被视为收敛。

所以本体系不建立Evidence Count（证据数量）到Truth Support（真实性支持）的固定换算，也不建立统一Evidence Score（证据评分）。

七、成员进入集合之前的最低条件

每个候选Evidence Unit（证据单元）进入集合前，至少需要：

• 指向明确Atomic Claim（原子命题）；
• 声明Support（支持）、Limit（限制）、Contradict（反驳）或Context（背景）方向；
• 完成G0—G10（门槛0—10）逐项审查并保留Unknown（未知）；
• 记录Origin Actor（来源主体）、Record Form（记录形式）、Proof Function（证明功能）和Independence Profile（独立性画像）；
• 记录实体、范围、时间和连续性；
• 记录Original Material（原始材料）、Derived From（派生自）和Transformation（变换）；
• 记录授权、公开用途和撤回条件；
• 说明不能推出什么。

“完成资格判定”不表示所有单元都必须是正向通过。具有明确资格和边界的限制或反向证据也应进入集合。关键是它们的身份、功能和状态可审计。

八、集合审查的十四项属性

Evidence Set（证据集合）至少需要从十四个方面审查。这些属性用于描述集合结构，不应加权为统一分数。

十四项属性是并列审查维度，不是可以互相补偿的权重。它们的完整填写结构见附录C｜Method Templates（方法模板）。

九、Lineage Diversity（谱系多样性）不等于Carrier Diversity（载体多样性）

同一信息可以发布在官网、媒体网站、社交平台、视频和知识库中。它们形成不同Carrier（载体），却可能来自同一Original Material（原始材料）。

载体多样性可能改善传播覆盖与可访问性，但不会自动形成谱系多样性。判断Lineage Diversity（谱系多样性）需要回溯：谁生产原始信息、谁拥有数据、谁进行验证、转载或改写过程中是否增加了新的独立调查与事实。

因此，站内与站外发布属于执行渠道选择，不能被写成证据独立性的来源。

十、Complementarity（互补性）不等于Independence（独立性）

合同、工单、付款记录和客户关系系统数据可能都来自同一企业业务系统。它们的Producer Independence（生产者独立性）有限，也可能属于Distinct Record Same System（同系统不同记录），但仍能从不同记录形式提供有限互补。

互补性说明成员覆盖不同证明环节；独立性说明成员的生产与谱系关系。两者必须分开。

同样，两个结构性独立来源如果只是重复同一错误信息，独立性也不能替代Verification（可验证性）。集合审查不能用一个维度补偿另一个关键维度。

十一、Convergence（收敛性）必须先校准比较条件

不同证据给出相似结果，不一定构成真正收敛。需要确认：

• 是否指向同一主体与命题；
• 是否使用相同或可转换指标；
• 是否覆盖相容样本和时间窗口；
• 是否来自不同谱系；
• 是否存在共同上游数据或共同偏差；
• 是否遗漏与结论冲突的记录。

只有完成这些校准，才能描述“多个证据方向一致”。当前体系不据此推断人工智能一定会采用该判断，也不为收敛性设置固定权重。

十二、Coverage（覆盖度）必须相对于Proof Burden（证明负担）判断

覆盖度不是材料数量，而是集合是否覆盖命题所需的证明结构。

B1 Direct Descriptive（直接描述类）命题可能只需直接记录、正确主体、范围和时间；B2 Composite Capability（复合能力类）需要知识、人员、经验、流程和运行记录的合理组合；B3 Performance and Outcome（表现与结果类）需要指标、样本、窗口、来源和异常处理；B4 Causal, Predictive and Comparative（因果、预测与比较类）还需要对照或反事实、替代解释、比较集合与不确定性。

十篇知识文章可能增加知识表达覆盖，却不能补足项目发生、流程执行或因果识别。Coverage（覆盖度）必须引用Claim-Evidence Requirement Matrix（命题—证据要求矩阵），不能以内容数量代替。

十三、时间一致性与连续性必须同时成立

多个成员各自真实，不代表它们能够共同支持当前命题。旧许可证、历史案例、现有团队介绍和近期客户评价可能分别指向不同时间状态。

Temporal Coherence（时间一致性）检查各记录的时间是否能够共同解释同一命题；Continuity（连续性）检查历史能力是否通过组织、人员、流程、技术和服务延续到当前。

发布时间较新不能刷新事实有效时间。把旧案例重新发布成新文章，也不能自动恢复当前能力支持。

十四、授权必须在集合层重新计算

每个证据单元有自己的Authorization Lifecycle（授权生命周期），集合输出还需要检查Authorization Compatibility（授权兼容性）。

一个客户可能允许匿名案例，另一个允许实名但不允许公开数据，内部业务记录可能只允许内部审查，公共登记可以公开引用。即使所有单元分别有某种授权，也未必能够在同一个公开页面中以同一种方式组合。

如果关键成员授权被Revoked（已撤回）、Expired（已过期）或Restricted（有限授权），系统需要：

1. 重新判断集合的Publishability（可公开性）；
2. 检查依赖该成员的Claim（命题）是否仍获得足够支持；
3. 追踪所有Derived Material（派生材料）和Carrier（载体）；
4. 根据授权条款执行下线、匿名化、替换或保留；
5. 分别维护内部真实性状态与公开使用状态。

授权变化不自动抹除现实与历史真实性，但可能改变整个集合的允许用途。

十五、谱系去重需要五个核心字段

每项证据记录至少保存：

• Original Material（原始材料）：最初可识别的记录或信息；
• Derived From（派生自）：当前单元来自哪个上游节点；
• Transformation（变换）：转载、摘要、翻译、改写、计算或人工智能生成；
• System of Record（主记录系统）：哪一系统被视为该事实关系的主要记录；
• Stable Entity Key（稳定实体标识）：主体、客户、项目或交易的稳定匹配键。

这些字段共同回答两个问题：哪些页面其实是同一信息的传播副本，哪些跨系统记录其实对应同一客户和事件。

如果谱系或实体关系无法确认，应保留Unknown（未知），而不是为了展示丰富度把它们默认视为独立。

十六、跨系统记录如何既去重又保留互补性

合同系统、客户关系系统、财务系统和工单系统可能记录同一个客户项目。粗暴合并会把一个项目算成多个，粗暴去重又可能丢失不同记录对签约、付款、执行和交付的互补作用。

正确方式是建立关系层：

同一Stable Entity Key（稳定实体标识）
＋ 同一Project or Transaction Key（项目或交易标识）
→ 标记为同一业务事件族
→ 各记录保留独立Record Form（记录形式）与Proof Function（证明功能）
→ 不自动增加独立客户或项目计数

这样既能防止虚假规模，也能保留跨记录核对价值。

十七、集合结论必须保留Unknown（未知）和禁止推论

Evidence Set（证据集合）的输出不能只有“充分”或“不充分”。至少应说明：

• 当前支持状态；
• 支持到什么命题强度；
• 哪些范围和时间有效；
• 哪些成员具有关键作用；
• 哪些限制、冲突和偏差仍然存在；
• 哪些状态保持Unknown（未知）；
• 当前允许哪些内部或公开用途；
• 哪些更强命题不能推出；
• 什么变化会触发重审。

集合无法支持原命题时，仍然只允许Narrow（缩小）、Decompose（拆解）、Qualify（增加限定）、Downgrade（降低强度）或Withhold（暂不表达）。

十八、Evidence Set Version（证据集合版本）

集合会随证据新增、过期、撤回、冲突解决、实体变化和命题版本更新而改变。因此必须记录集合版本、目标命题版本、生效区间、成员与状态变化、重审触发条件和替代关系。更新时不能静默覆盖历史，否则无法解释过去为什么允许发布、人工智能引用的是哪个版本，以及某项结论为何发生变化。完整版本字段由附录B｜Core Object Dictionary（核心对象字典）和附录C｜Method Templates（方法模板）承接。

十九、示例：能力命题的集合不是“案例越多越好”

假设目标命题是：

甲公司当前具备处理某类制造业成本核算任务的能力。

一个合理集合可能需要连接：相关人员知识与经历、真实项目发生记录、流程定义、实际运行记录、质量检查、异常与投诉、当前团队和系统连续性。若只有一篇知识文章，它可能支持Knowledge（知识）表达；若只有一个历史项目，它可以支持Experience（经验）或Occurrence（事件发生）；二者都不能单独完成当前Composite Capability（复合能力）证明。

如果五篇媒体文章都转载同一案例，它们不会把一个历史项目变成五项独立能力证据。增加案例数量也需要检查行业范围、参与深度、实体归属、时间连续性和样本选择，而不是只做页面计数。

二十、示例：结果集合不能自动升级为因果集合

假设合同、工单和客户数据共同支持某服务期间错误率下降，同时记录显示客户更换了负责人并上线新系统。

集合可以对Outcome Claim（结果命题）形成限定支持，却需要把负责人变化和系统上线作为Context（背景）或替代解释节点。若没有对照、反事实或其他因果识别结构，就不能把集合升级为Causal Claim（因果命题）的充分支持。

这里反向和背景信息不是要删除的噪音，而是决定命题能够说到多强的关键成员。

二十一、Evidence Map（证据地图）的正式基线

本项目必须保持Freeze 01（冻结01）的正式定义：

Evidence Map（证据地图）是客户事实或资产、可支持判断、Query Cluster（查询簇）、来源状态和缺口的结构化记录。

这一定义是当前正式基线。本章不能因为已经发展出更细的命题—证据系统，就静默把Evidence Map（证据地图）改写成另一种对象。

Evidence Set（证据集合）是本章定义的命题中心证明组合；Evidence Map（证据地图）仍然是正式基线中的结构化记录。二者可以建立接口，但不能未经新决策便宣布同一或互相替代。

二十二、Evidence Map Extension Draft（证据地图扩展草案）

为了连接当前研究，本章提出一个扩展草案：

Decision Situation（决策情境）
→ Decision Variable（决策变量）
→ Target Claim（目标命题）
→ Atomic Claim（原子命题）
→ Required Evidence（所需证据）
→ Qualified Evidence（合格证据）
→ Evidence Set（证据集合）
→ Public Expression（公开表达）
→ Carrier and Distribution（载体与分发）
→ AI Behavior Observation（人工智能行为观测）

扩展图同时记录Time（时间）、Authorization（授权）、Lineage（谱系）、Conflict（冲突）、Bias（偏差）和Derivation（派生关系）。

它的作用是展示从用户决策研究到公开信息和人工智能行为观测的工程接口，不是关于人工智能内部处理过程的真实因果链，也不是当前正式Evidence Map（证据地图）定义的替代版本。

二十三、扩展草案的认识状态必须显式保留

Evidence Map Extension Draft（证据地图扩展草案）当前只是对现有章节接口的结构化提案。它不能被描述为Accepted（已接受）的正式定义，更不能因为被写入白皮书就自动修改Freeze 01（冻结01）。

若未来需要正式更新Evidence Map（证据地图），必须：

1. 明确提出定义变更；
2. 说明旧定义解决什么问题、新定义增加什么对象；
3. 检查与Gap Map（缺口地图）、服务系统和既有交付物的兼容性；
4. 通过反例与漂移检查；
5. 由用户作出正式决策；
6. 生成新的Chapter Freeze（章节冻结）或正式Freeze（冻结）记录。

在此之前，工程实现可以引用扩展草案进行试验，但必须标记版本和状态，不能反向覆盖SSOT（单一事实来源）。

二十四、证据结构与Gap（缺口）之间的边界

证据集合能够显示某项命题的支持、限制、冲突和未知，却不能仅凭“材料不够”直接判定企业能力不足，也不能仅凭“证据充分”判断人工智能为何没有使用。

至少需要保持以下边界：

• 能力或证据存在，但人工智能信息链未有效获得、使用或关联，可能进入Information Gap（信息缺口）；
• 目标决策变量重要、能力可能存在，但缺少真实、具体、可验证材料，可能进入Evidence Gap（证据缺口）；
• 用户重视某项能力，但企业真实能力不足，可能进入Business Gap（业务缺口）；
• 缺少记录且能力真实状态不明，应先标记Indeterminate（无法判断），不得直接断言Evidence Gap（证据缺口）或Business Gap（业务缺口）。

正式Gap Diagnosis（缺口诊断）还需要结合Decision Situation（决策情境）、User-DVM（用户决策变量地图）、AI-DVM（人工智能决策变量地图）、客户事实、公开信息和竞争证据。第13章只提供证据结构输入，不提前完成第14章的正式分类。

二十五、证据集合不能证明人工智能一定会使用

一个集合可以真实、完整、公开、可访问，并与用户决策高度相关，但人工智能在特定条件下仍可能没有引用、吸收、正确归属或用于决策。

Evidence Validity（证据有效性）、Publishability（可公开性）、GEO Usability（GEO可用性）和Observed AI Use（已观测人工智能使用）仍然必须分开。

集合属性与人工智能行为之间的稳定因果关系当前保持Unknown（未知）。后续只能通过明确基线、干预、对照和重复观测逐步形成Operational Hypothesis（操作性假设）或Validated Pattern（已验证模式），不能把集合设计原则写成人工智能内部权重。

二十六、对GEO Service System（GEO服务体系）的要求

第一，系统必须区分Material Repository（材料库）、Evidence Package（证据组合包）、Evidence Set（证据集合）和Evidence Map（证据地图）。四者不得由一个“素材库”字段替代。

第二，每个Evidence Set（证据集合）必须指向目标Claim（命题）或命题组，并保存成员的资格状态、四轴画像、证明方向、范围、时间、授权和禁止推论。

第三，集合必须支持Support（支持）、Limit（限制）、Contradict（反驳）和Context（背景）四种成员方向，报告不得隐藏重大反向信息。

第四，系统必须同时执行谱系去重和实体消歧。Carrier Count（载体数量）、System Count（系统数量）和Independent Evidence Count（独立证据数量）分别记录。

第五，关键成员的授权撤回、到期、证据失效、主体变化或重大冲突均应触发集合重审，并追踪下游公开表达和载体。

第六，Evidence Map Extension Draft（证据地图扩展草案）只能作为带状态的候选工程结构使用，不得覆盖Freeze 01（冻结01）正式定义。

第七，集合审查输出必须向Gap Diagnosis（缺口诊断）提供结构化输入，但不能自行从单项失败生成正式Gap（缺口）或Intervention（干预）。

二十七、Minimum Evidence Set Record（最低证据集合记录）

最低记录必须覆盖集合身份、目标命题、成员关系、谱系与实体、范围与时间、十四项属性、冲突与偏差、授权传播、集合结论和变更控制。正文保留这些不可缺少的字段组，具体填写结构集中在附录C｜Method Templates（方法模板），避免把白皮书正文重复写成操作表单。

二十八、本章明确否定的观点

• 把所有企业文件放在一起就形成Evidence Set（证据集合）；
• Evidence Set（证据集合）可以脱离Claim（命题）建立；
• 材料、证据单元、证据组合包、证据集合和证据地图是同一对象；
• 只有正向支持材料才属于证据集合；
• 限制、反驳和背景信息应从营销输出中删除；
• 证据数量可以直接相加形成真实性或权威性；
• Carrier Diversity（载体多样性）等于Lineage Diversity（谱系多样性）；
• Complementarity（互补性）等于Independence（独立性）；
• 表面结论一致就构成Convergence（收敛性）；
• 多个内部系统记录等于多个独立客户、项目或谱系；
• 新发布时间可以刷新旧事实的有效时间；
• 每个成员可公开就意味着整个集合可以任意组合公开；
• 授权撤回会自动抹除全部历史真实性；
• 一个证据集合只需建立一次，无需版本和重审；
• 集合审查的十四项属性可以加权成统一Evidence Score（证据评分）；
• Evidence Map Extension Draft（证据地图扩展草案）已经替代正式基线；
• 证据不足自动等于Business Gap（业务缺口）；
• 证据充分自动等于人工智能会使用或推荐；
• 扩大发布和载体数量可以修复真实性、能力或因果缺口。

二十九、当前仍然不知道什么

以下问题保持Unknown（未知）：

• 不同行业与命题风险下Evidence Set（证据集合）的最低成员结构；
• Lineage Diversity（谱系多样性）、Complementarity（互补性）和Convergence（收敛性）的任务级准入规则；
• Distinct Record Same System（同系统不同记录）在不同证明负担中的互补价值；
• 授权撤回后不同载体和派生内容的具体处置时限；
• Evidence Map Extension Draft（证据地图扩展草案）是否应在未来正式替代、合并或附着于现有基线；
• 证据集合属性与公开、可检索、被检索、被引用、被吸收、被归属和被用于决策之间的因果关系；
• 集合干预效果的持久性和跨Engine（引擎）迁移性；
• 哪些集合结构可在真实项目中升级为Validated Pattern（已验证模式）。

当前Validated Pattern（已验证模式）为空。

三十、本章结论

Evidence Set（证据集合）不是证据数量的堆叠，而是围绕明确Claim（命题），由完成资格判定的Evidence Unit（证据单元）构成，并保存支持方向、谱系、相互关系、范围、时间、授权、偏差和冲突的结构化组合。

集合必须同时允许Support（支持）、Limit（限制）、Contradict（反驳）和Context（背景）。Lineage Diversity（谱系多样性）、Complementarity（互补性）、Convergence（收敛性）和Coverage（覆盖度）不能互相替代，也不能加权成统一分数。

Evidence Map（证据地图）继续遵守Freeze 01（冻结01）正式定义。Evidence Map Extension Draft（证据地图扩展草案）只用于展示决策情境、命题、证据集合、公开表达与人工智能行为观测之间的候选工程接口，不构成正式定义更新。

第九至第十三章由此形成完整链路：Evidence（证据）对象定义—Evidence Qualification（证据资格判定）—Evidence Type Taxonomy（证据类型分类）—Claim Architecture（命题架构）—Evidence Set and Evidence Map（证据集合与证据地图）。下一章进入Gap Diagnosis（缺口诊断），将这些结构与User-DVM（用户决策变量地图）、AI-DVM（人工智能决策变量地图）、客户事实和竞争环境结合，判断真正需要改变的变量。

本章图表

图13-1｜Material Repository（材料库）、Evidence Package（证据组合包）、Evidence Set（证据集合）与Evidence Map（证据地图）

重绘说明：用四层对象对比图展示材料按存储组织、组合包按项目组织、证据集合按命题组织、证据地图按正式基线记录客户事实或资产、可支持判断、查询簇、来源状态和缺口。

图13-2｜Evidence Set（证据集合）的四方向结构

重绘说明：中央为目标Claim（命题），四周分别连接Support（支持）、Limit（限制）、Contradict（反驳）和Context（背景）证据单元，并显示各自谱系和资格状态。

图13-3｜集合的十四项审查属性

重绘说明：将十四项属性分为资格与匹配、谱系与组合、范围与时间、冲突与治理四组，注明“多维描述，不生成统一分数”。

图13-4｜载体、谱系与跨系统去重

重绘说明：左侧展示一个原始材料分发到多个载体；右侧展示同一客户项目在合同、财务、客户关系和工单系统中的不同记录。分别标出传播副本、同事件族和不同证明功能。

图13-5｜Authorization Propagation（授权传播）

重绘说明：一个关键证据单元连接命题、证据集合、公开表达和多个载体；授权撤回后沿派生关系触发重审、下线、匿名化或替换，同时保留内部真实性状态分支。

图13-6｜Evidence Map Extension Draft（证据地图扩展草案）

重绘说明：使用本章第二十二节的十节点链路，外围以横向治理带标记时间、授权、谱系、冲突、偏差和派生；醒目标注“扩展草案，不替代Freeze 01（冻结01）正式定义”。

图13-7｜从证据集合到Gap Diagnosis（缺口诊断）的边界

重绘说明：证据集合输出支持、限制、冲突、未知和允许用途，随后与决策情境、用户地图、人工智能地图、客户事实和竞争环境汇合，才进入正式缺口诊断；禁止从单一材料缺失直接跳到业务缺口。

表13-1｜Minimum Evidence Set Record（最低证据集合记录）

采用本章第二十七节的十组字段，为服务系统的集合记录、授权传播和变更追踪提供结构规范。