SEO / GEO 数据治理与规范标准细则（六）：Data Provenance——为什么“这条数据从哪里来”必须能够被机器追溯？

系列专题：SEO / GEO 数据治理与规范标准细则

本篇主题：Data Provenance / 数据来源与生成过程追溯

发布日期：2026年10月13日

关键词：W3C PROV、Entity、Activity、Agent、Data Lineage、Evidence、Claim、Version、RAG、AI Citation

一家工业设备企业更新了某款产品的技术资料。

工程部门批准的新版本规定，设备在标准配置下的额定功率为82 kW。

PIM系统更新为82 kW，官网产品页面也更新为82 kW。但一份旧PDF仍然写着75 kW，销售人员保存的Excel是80 kW，AI知识库里同时存在三个版本。

客户询问AI：“这款设备需要多大的电力供应？”

AI给出了75 kW。

企业检查后发现，AI检索到的是两年前的PDF。更麻烦的是，没人知道那份PDF是谁生成的、从哪个工程版本导出、什么时候进入知识库，以及哪些网页还在引用它。

工程部门拥有正确数据，网站也已经更新。但企业仍然无法回答：

为什么旧数据会继续被使用？

这不是简单的内容更新问题。问题出在数据经过多个系统以后，已经失去了来源与变更记录。

第三篇讨论Source of Truth，确定哪个数据具有最终解释权；第四篇建立Data Owner与Data Steward，明确谁承担责任；第五篇制定Source Admission Gate，决定什么信息可以进入知识体系。

到了第六篇，必须进一步解决：

即使一条数据最初来自可信来源，经过采集、转换、复制、AI加工与多渠道发布以后，怎样保证它仍然可以追溯到最初的事实和证据？

这就是Data Provenance。

一、为什么“注明来源”仍然不够？

很多企业认为，只要在文章末尾写上“数据来源：工程部”，就已经完成来源治理。

但这只能回答一个很有限的问题：信息大概来自哪里。

它无法回答：

工程部的哪份文件？使用了哪个版本？原始数值是什么？是否经过单位换算？谁进行了转换？是否有人审核？哪一次操作把它同步到了WordPress？PDF是否来自同一版本？AI使用的是原始文件还是加工摘要？当原始文件被替换时，哪些下游内容需要重建？

这些信息没有被记录，企业实际上只有一个Source Label，而没有完整的Provenance Record。

二者的区别可以概括为：

Source回答“来源是谁”；Provenance进一步回答“这份信息是怎样形成、变化与传播的”。

W3C在2013年发布的PROV系列规范，已经为描述这种来源及生成过程提供了通用数据模型。

W3C在《PROV-Overview》中将Provenance理解为有关实体、活动及参与者的信息；这些信息能够用于评估数据或其他对象的质量、可靠性与可信程度。

这个定义的重点不只是来源名称，还包括信息形成过程。

参考：W3C — PROV-Overview

对SEO/GEO而言，这意味着：一篇文章即使列出了五个参考链接，也未必拥有合格的数据来源链。

因为读者看到的是参考资料，而企业内部需要管理的是具体事实与具体证据之间的关系。

二、必须先区分五个不同概念

在实际项目中，Source、Evidence、Provenance、Lineage与Citation经常被混用。

它们有关联，但作用并不相同。

概念	主要回答的问题	示例
Source	信息来自哪里？	工程规范V4.2
Evidence	什么依据支持这个事实？	已批准规格表第18页
Provenance	信息如何产生、处理和变化？	提取、校验、审批、同步记录
Data Lineage	数据经过哪些系统与处理节点？	PLM → PIM → CMS
Citation	在内容或回答中引用了什么？	产品技术规格链接

Source是起点。Evidence负责支持特定事实。Provenance描述事实及信息资产的形成历史。Lineage强调上下游依赖与传播路径，通常是Provenance体系中重要的一部分。Citation则是人或系统在表达结论时，对所用信息提供的引用指向。

这些概念不能互相替代。

一条信息可能拥有准确的Citation，却引用了一份过期文件。它可能拥有完整的Lineage，却没有经过业务事实核验。它也可能拥有经过签名的来源记录，却仍然包含不正确的技术参数。

因此，本系列确立一条基本原则：

Provenance提供可追溯性，不自动保证真实性；Evidence支持事实判断，也不因为被引用就自动有效。

三、W3C PROV：理解可追溯数据的基础模型

W3C PROV系列中，最值得SEO/GEO数据治理团队掌握的，是三个基础概念：Entity、Activity、Agent。

它们共同回答信息治理中最核心的三个问题：什么对象？经过什么过程？由谁或什么系统参与？

Entity：被追溯的对象

W3C PROV中的Entity，可以是数字文件、数据集、网页、信息记录或其他具有可描述特征的对象。

例如：工程规范V4.2、某个产品参数版本、一份批准后的PDF、一个知识库Chunk、一篇网站文章。

它们都可以被建模为需要追溯的Entity。

这里需要避免一种混淆。

SEO领域同样经常讨论Product Entity、Organization Entity，它们通常指现实世界中的产品、组织等业务对象。

而在Provenance模型中，我们更需要跟踪的，可能是描述该产品的某一份数据快照或文件版本。

例如，PRODUCT-FW30是产品业务实体ID，FACT-FW30-POWER-V42则是描述该产品功率的一个事实版本记录。两个ID分别承担不同职责。

Activity：信息经历了什么处理

Activity代表一个发生在特定时间范围内的过程。

例如：从PDF提取参数、把82.0标准化为82、审核技术规范、将产品数据同步到PIM、生成产品网页、执行RAG文档切分、AI生成技术问答。

Activity的核心价值，是把原本隐藏在系统中的处理过程显式记录下来。

Agent：谁参与或负责

Agent可以是工程师、工程部门、编辑人员、企业组织、运行数据同步的程序，或执行内容生成的AI Agent。

需要注意，技术上的执行者和第四篇中的Data Owner不一定是同一个角色。

例如，一个自动化程序可能负责生成网页，但工程部门仍然对技术参数的业务准确性承担责任。

因此：

Execution Identity不能替代Business Accountability。

参考：W3C — PROV-O: The PROV Ontology

四、真正关键的，是把三个对象连接起来

只记录Entity、Activity、Agent还不够。必须表达它们之间的关系。

W3C PROV-O提供了若干非常重要的标准属性。

PROV-O属性	含义	SEO/GEO应用
prov:wasDerivedFrom	一个实体派生自另一个实体	网页参数来自批准的数据记录
prov:wasGeneratedBy	一个实体由某项活动生成	文章由发布流程生成
prov:used	某项活动使用了某个实体	转换任务使用工程规范
prov:wasAssociatedWith	活动与Agent相关	同步任务由特定程序执行
prov:wasAttributedTo	实体归属于某个Agent	数据版本归属于指定组织
prov:wasRevisionOf	一个实体是另一个实体的修订版本	规格V4.2修订自V4.1
prov:startedAtTime	活动开始时间	数据处理任务开始时间
prov:endedAtTime	活动结束时间	数据处理任务完成时间

这些属性并不是本系列创造的术语，而是W3C PROV-O中的标准表达。

它们可以让系统回答：一份新的技术文件从哪份旧文件修订而来？一次AI摘要生成使用了哪些原始材料？一个网页参数是否经过了未授权的中间修改？某次数据导入使用了哪个时间点的快照？

因此，Provenance不是给文件再增加几列备注，而是在建立可计算的数据关系。

五、回到82 kW：一条事实到底应该如何被追溯？

我们继续使用前五篇的工业设备案例。

以下型号、日期、人员和编号均为演示数据，不代表真实企业产品规格。

企业有一款设备PRODUCT-FW30，工程部门在2026年9月20日批准新版技术规范V4.2，该规范确认标准50Hz配置的额定功率为82 kW。

原始事实可以表示为：

entity_id:
PRODUCT-FW30

attribute:
rated_power

context:
standard_50hz

value:
82

unit:
kW

source_document:
ENGINEERING-SPEC-V4.2

source_location:
Page 18 / Rated Power

effective_from:
2026-09-20

这是一个具备基础业务上下文的数据记录，但还没有完整描述它是如何被加工和发布的。

因此，还需要记录它的传播过程。

工程规范 V4.2
      ↓ 技术审批
Approved Fact V4.2
      ↓ 字段提取
Structured Attribute
      ↓ 数据验证与标准化
Canonical Product Data
      ↓ PIM同步
Product Master Record
      ↓ CMS发布
Product Web Page
      ├── 页面参数
      ├── 结构化数据
      └── PDF技术资料
      ↓ 知识库同步
Verified Knowledge Document
      ↓ Chunking / Embedding
Retrievable Knowledge Unit
      ↓ 检索及生成
AI Answer

其中每一个箭头，都可能代表一次独立的Activity。

每一个节点，都应该具有可识别的对象ID或版本ID。

这就是一条基础的：Fact Provenance Chain。

六、如果某个环节没有记录，问题会怎样发生？

假设工程规范V4.2已批准，PIM也已更新。

但营销部门曾在两年前单独导出一份PDF，旧PDF从未连接PIM的更新机制。

AI团队建设RAG时，把整个企业共享文件夹导入知识库。

于是，系统同时保存：

FACT-FW30-POWER-V38:
75 kW

FACT-FW30-POWER-V40:
80 kW

FACT-FW30-POWER-V42:
82 kW

如果RAG只保存文本和Embedding：

chunk_text
embedding

就无法直接识别这三个值分别属于哪个批准版本。

检索系统可能因为文本相似度、上下文相关性或其他检索因素，选择旧Chunk。

一旦旧内容进入回答，就可能出现：业务真相已经更新，但AI依然传播历史参数。

这不是说RAG无法处理版本，而是说明：

如果企业没有把版本和来源作为检索时可用的元数据，系统就无法可靠执行版本过滤。

所以，数据治理不能止于Document Ingestion，还必须延伸到Retrieval Eligibility。

七、Provenance的最小粒度，应该从Document走向Claim

很多企业会为文章保存作者、发布时间、原始URL、修改时间，这些属于Document-level Metadata。

但一篇采购指南可能有多个不同的事实，例如：设备高度30 m、额定功率82 kW、单次载客量96人、交货周期45—60天、某地区的合规要求。

每一项信息可能来自不同系统，拥有不同的Owner、有效期与证据。

因此，仅仅将整篇文章关联到一个Source，并不足以支持关键商业事实的审计。

本系列建议采用三个层次：

Document-level Provenance：这篇文章或文件整体从哪里来？

Claim-level Provenance：其中每一项重要事实依据什么？

Field-level Provenance：某个结构化属性值从哪个字段、哪个版本转换而来？

例如：

Document:
PROCUREMENT-GUIDE-008

Claim:
CLAIM-FW30-POWER-001

Field:
PRODUCT-FW30.rated_power

Evidence:
ENGINEERING-SPEC-V4.2 / Page 18

这样，即使文章重新排版、AI改写了句子，核心事实仍然可以绑定独立的Claim ID。

这对SEO内容审计、GEO知识组织和B2B产品信息同步尤其有价值。

八、建立SEO / GEO Provenance Record

企业不必一开始就建设大型知识图谱。更现实的起点，是为Critical Data Element建立统一的Provenance Record。

建议至少包含以下字段。

字段	作用
record_id	追溯记录唯一ID
entity_id	业务实体ID
claim_id	相关事实或主张ID
attribute	属性名称
value、unit	标准值与单位
context	配置、市场等成立条件
source_id	注册的数据源
source_version	原始版本
evidence_id	对应证据
source_locator	页码、字段路径或定位信息
activity_id	生成或转换活动
derived_from	上游记录ID
agent_id	处理活动参与者
owner_id	业务责任角色
approved_at	审批时间
effective_from	业务生效时间
generated_at	记录生成时间
status	当前治理状态
downstream_refs	下游使用位置

这里必须强调：approved_at、effective_from和generated_at不应该混为一谈。

例如，工程文件9月18日审批，9月20日生效，网站9月21日发布。这三个时间分别具有不同的治理意义。

如果全部写成updated_at，未来就很难判断为什么某个历史页面在特定日期仍然使用旧参数。

九、一份可以直接实施的数据记录示例

下面是本系列提出的内部JSON数据格式示例。

它不是W3C官方规定的JSON模板，也不是可以直接复制到网页用于Google Rich Results的Schema标记。

{
  "record_id": "PROV-FW30-POWER-0042",
  "entity_id": "PRODUCT-FW30",
  "claim_id": "CLAIM-FW30-POWER-001",
  "attribute": "rated_power",
  "value": 82,
  "unit": "kW",
  "context": "standard_50hz",
  "source": {
    "source_id": "SOURCE-PLM-008",
    "document_id": "ENGINEERING-SPEC-V4.2",
    "version": "4.2",
    "locator": "page:18;field:rated_power"
  },
  "evidence_id": "EVIDENCE-4201",
  "provenance": {
    "derived_from": "FACT-FW30-POWER-V42",
    "activity_id": "ACT-EXTRACT-208",
    "agent_id": "SERVICE-PIM-SYNC",
    "transformation": "unit_normalization"
  },
  "governance": {
    "owner_role": "Engineering",
    "status": "APPROVED",
    "approved_at": "2026-09-18",
    "effective_from": "2026-09-20"
  },
  "generated_at": "2026-09-21T08:30:00Z",
  "downstream_refs": [
    "PIM:FW30",
    "CMS:PRODUCT-FW30"
  ]
}

这份记录虽然不复杂，但与过去只保存rated_power = 82相比，已经发生了本质变化。

它可以帮助系统追问：这是什么值？属于哪个产品？适用于什么配置？来自哪份文件？使用哪个版本？经过哪项转换？谁拥有业务责任？何时审批和生效？发布到哪里？

如果这些字段能够伴随数据向下游传递，后续审计的成本就可以明显降低。

十、怎样进一步映射到W3C PROV-O？

对于具备RDF、知识图谱或语义数据能力的企业，可以在内部治理模型的基础上建立PROV-O映射。

例如：

@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix ex: <https://example.org/data/> .

ex:spec-v42 a prov:Entity .

ex:power-v42 a prov:Entity ;
    prov:wasDerivedFrom ex:spec-v42 ;
    prov:wasGeneratedBy ex:extraction-208 .

ex:extraction-208 a prov:Activity ;
    prov:used ex:spec-v42 ;
    prov:wasAssociatedWith ex:pim-sync-service .

ex:pim-sync-service a prov:SoftwareAgent .

这个示例表达了四件事：一份工程规范是Entity；一个提取后的参数记录也是Entity；提取活动使用了工程规范，并生成了参数记录；执行该活动的软件服务作为Agent参与其中。

这些关系可以被程序解析，而不是依赖工作人员阅读说明文字后自行理解。

其中example.org是演示地址，正式实施时应使用企业自己的稳定标识空间。

需要特别注意：

这段Turtle代码用于说明Provenance语义建模，并不等于Google要求网站增加这种标记，也不意味着添加PROV-O就会获得额外排名或AI引用。

W3C PROV-O解决的是互操作与来源关系表达。

Google Search的页面结构化数据另有规则和支持范围。

两者可以协作，但不能混同。

十一、AI改写以后，Provenance应该如何保留？

这是生成式AI内容流水线里最容易发生来源断裂的位置。

假设企业把一份工程规范交给AI，让它完成英文产品说明。

传统做法可能是：工程PDF进入AI，AI生成英文文章，编辑审核，WordPress发布。

但系统没有记录：AI使用了哪个输入版本、采用哪个提示词版本、是否调用其他工具、编辑修改了什么、哪项技术主张经过人工核验、最终发布的是第几版。

结果就是，企业虽然保留了最终文章，却丢失了文章生成过程。

更成熟的方案，应当把一次AI生成任务记录为独立Activity。

例如：

generation_id:
GEN-FW30-20260921-01

input_sources:
ENGINEERING-SPEC-V4.2
PRODUCT-MASTER-V12

prompt_version:
PROMPT-PRODUCT-07

model_identifier:
MODEL-CONFIG-03

output_document:
DRAFT-FW30-EN-01

review_status:
APPROVED

reviewer_role:
Technical Reviewer

这里的model_identifier应对应实际运行时的模型及配置记录，而不只是人为起一个模型名字。

如有必要，还可以保存模型供应方、版本、参数设置、工具调用、知识库快照和执行日志，但不应该把这些全部无差别公开。

内部生成过程与对外展示的信息需要分层管理。

更重要的是：AI完成文本改写，不应该导致原始Claim的证据关系被删除。

即使AI把“Rated power is 82 kW.”改写为“The standard 50Hz configuration has a rated power of 82 kilowatts.”，系统仍应知道它们引用的是同一份批准后的技术记录。

如果AI新增了未经来源支持的事实，则应该产生新的待验证Claim，而不是自动继承原Claim的可信状态。

十二、RAG系统必须能够回答“引用的是哪个版本”

RAG数据治理通常会经历：

Document Ingestion、Parsing、Chunking、Embedding、Indexing、Retrieval、Generation。

企业如果只保留最终的Chunk和向量，就无法完整重建这些环节。

建议每个知识库Chunk至少绑定：

chunk_id
document_id
source_id
source_version
section_locator
extraction_activity_id
chunking_version
embedding_model_version
knowledge_status
valid_from
valid_to

其中，Chunk和Embedding也需要区分。

原始文件没有变化，并不意味着Chunk没有变化。例如更换PDF解析程序后，章节边界可能发生改变。

修改Chunking Strategy后，同一份文件可能被分成完全不同的知识单元。更换Embedding Model以后，向量表达与检索行为也可能发生变化。

因此一个更完整的追溯关系应该是：

Source Document
    ↓
Parsed Document
    ↓
Knowledge Chunk
    ↓
Embedding Version
    ↓
Index Snapshot
    ↓
Retrieved Context
    ↓
Generated Answer

对于正式企业知识系统，建议在适当的日志保留期限内记录检索所使用的Chunk ID、版本、权限与知识库快照标识。

否则，某次AI回答出现争议以后，即使拿到了完整的回答文本，也未必能重现当时使用的证据集合。

还需要保留一个技术边界：LLM输出可能具有非确定性。

即使保存输入、模型配置和检索结果，也不一定能够逐字重现历史回答。

因此，Provenance的目标应当是可审计与尽可能可复现，而不是承诺任何生成式回答都能百分之百重演。

十三、Provenance进入SEO：网页、Schema和PDF必须共享事实来源

传统SEO常常在三个位置分别维护产品参数：WordPress正文、JSON-LD、下载PDF。

问题在于，这三个地方很可能拥有独立的编辑流程。

如果有人修改网页，没有同步Schema，就会出现机器可读数据与页面内容不一致。

Google Search Central的结构化数据指南要求标记真实反映页面内容，避免误导，也不应标记用户无法在页面看到的相关信息。

参考：Google — General Structured Data Guidelines

从数据治理角度，更理想的方式是：

Approved Product Fact
        ↓
Canonical Data
        ├── WordPress正文
        ├── JSON-LD
        ├── 技术参数表
        └── PDF生成任务

重点不是四份内容写得完全一样，而是它们涉及同一项商业事实时，应共享一致的Canonical Value，并且能够追溯到同一份批准记录。

不同发布媒介可以采用不同的表达形式。例如网页使用完整描述，表格使用简写，PDF提供技术条件和补充说明，但不能未经授权改变事实含义。

这也是为什么Provenance最终会影响内容一致性、数据变更管理和发布质量。

十四、Provenance必须连接Version与Effective Time

第三篇讨论过一个问题：最新版本不一定是当前有效版本。

Provenance必须保留这种区别。

版本	额定功率	审批日期	生效日期	状态
V3.8	75 kW	2025-01-08	2025-02-01	Superseded
V4.0	80 kW	2026-06-20	2026-07-01	Superseded
V4.2	82 kW	2026-09-18	2026-09-20	Active

这三个版本不是必须立即删除其中两个。

历史规范可能仍然具有售后维护价值、历史订单价值、设备配置追溯价值和争议处理价值。

但在回答当前标准配置的功率问题时，应选择当前有效版本。

所以企业最好分别管理：

Historical Validity：过去什么时间这个值曾经有效？

Current Validity：当前哪个值有效？

Publication Status：是否仍允许对外作为现行事实发布？

Retrieval Eligibility：AI知识系统是否允许用它回答当前问题？

这四个状态不能仅用一个ACTIVE字段覆盖全部含义。

十五、Source被撤回以后，应该发生什么？

假设工程部门发现V4.2存在错误，需要撤回。

如果系统只删除原始PDF，那么问题不会自动解决。

因为PIM可能已经保存了提取后的参数，WordPress已经发布产品页面，静态PDF可能已经分发给经销商，AI知识库也可能保存了多个派生Chunk。

因此，Provenance必须支持反向查询：

哪些下游资产依赖这份已经撤回的来源？

这就是影响分析。

成熟的处理流程应该是：

Source Withdrawn
       ↓
Identify Derived Records
       ↓
Identify Affected Claims
       ↓
Identify Published Assets
       ↓
Assign Responsible Owners
       ↓
Suspend / Correct / Replace
       ↓
Rebuild Knowledge Index
       ↓
Verify Downstream State

其中，暂停使用、纠正和替换应依据风险等级决定。

一般文字描述可能允许正常排期修订；涉及安全、合规或严重技术错误的Claim，则可能需要立即停止对外使用。

这连接了第四篇提出的Data Owner、Data Steward和Data Incident治理机制。

W3C DCAT 3提供了版本相关描述能力，例如dcat:previousVersion，帮助数据目录表达不同版本之间的关系。

参考：W3C — DCAT Version 3

不过，DCAT的版本表达不等于自动实现企业下游撤回流程，影响分析与失效传播仍然需要企业自行设计。

十六、如何判断Provenance是否可靠？

假设某份文档记录“来源：官方技术规范”，但实际上这份文件是员工自行生成的。

系统即使保存了Source ID、Version、Timestamp、Creator，也不能直接证明其内容可信。

因为Provenance Record本身可能是错误或伪造的。

因此需要把三个不同层次分开。

第一层：Declared Provenance

系统声明这条数据来自哪里。

第二层：Verified Provenance

通过文件校验、身份认证、审计日志、来源核对等机制，验证声明与相关对象之间的关系。

第三层：Verified Claim

由有Authority的业务人员或系统，根据有效证据确认具体事实。

三者的意义不同。

一份文件即使拥有有效数字签名，也不能自动证明里面的技术参数正确。

例如，C2PA关于Content Credentials的解释明确区分了来源信息的可验证性与内容本身是否真实的价值判断。该技术并不直接保证被签名内容中的陈述都是真实的。

因此：

可追溯性不能代替事实核验，数字签名也不能代替业务审批。

十七、Hash、Signature与Audit Log应当怎样使用？

企业可以根据数据风险采用不同保障措施。

对于普通内容，保存稳定的Document ID、版本与修改记录可能已经足够。

对于关键合同、认证、工程批准记录，可以进一步保存文件哈希值、审批人身份、审批时间、数字签名、不可随意覆盖的审计日志。

例如：

evidence_id:
EVIDENCE-4201

document_id:
ENGINEERING-SPEC-V4.2

hash_algorithm:
SHA-256

document_hash:
<computed_sha256>

approved_by:
ENGINEERING-DIRECTOR

approval_event:
APPROVAL-8821

其中真实Hash必须由系统计算，不能人工填写一个看似合理的值。

Hash的作用是帮助识别文件字节内容是否变化，并不是证明事实正确。

数字签名的安全性也依赖密钥管理、身份确认以及签名验证流程。

因此本系列不建议简单使用hash_exists = true就把数据标记为可信。

更合理的做法是：

Integrity Verification + Authority Verification + Evidence Validation。

三者结合，而不是互相替代。

十八、Provenance也有权限与隐私边界

并不是所有来源信息都适合直接公开。

例如：内部工程规范、客户合同、员工姓名、商业价格、未公开的设计文件、受授权限制的第三方数据。

它们的Provenance可以在内部保留，但外部内容不应该无条件公开这些信息。

因此建议将Provenance分成两层：

Internal Provenance：保存完整的系统关系、处理记录、审批链和审计信息。

Public Attribution：只向公众呈现允许公开的作者、来源、日期、证据链接及必要说明。

这也避免把“提高透明度”误解成“公开全部底层业务数据”。

真正成熟的Provenance Governance，同时需要满足可追溯、最小必要披露、访问控制与授权合规。

十九、一个适合WordPress、PIM与AI知识库的最小落地方案

对于多数中小型B2B企业，不需要第一天就建设RDF数据库或独立的Provenance Graph Platform。

可以先从四张基础表开始。

第一张：Source Registry

记录原始文件和来源：

source_id、source_type、source_location、publisher、version、license、status。

第二张：Claim Registry

记录企业正式使用的事实：

claim_id、entity_id、attribute、value、context、evidence_id、owner、status。

第三张：Activity Log

记录转换与审批：

activity_id、activity_type、input_refs、output_refs、actor_id、executed_at、rule_version。

第四张：Distribution Registry

记录事实被发布到了哪里：

claim_id、destination_type、destination_id、published_version、sync_status、verified_at。

这四张表通过稳定ID连接，企业就已经拥有基本的端到端追溯能力。

实际使用WordPress时，可以把claim_id、source_id、evidence_id等字段作为内部自定义字段保存；技术实现可以使用ACF、WordPress Meta或专门的外部数据服务。

关键技术参数应当尽可能由受控数据层提供，而不是由编辑人员在正文和Schema中分别手工输入。

对于RAG系统，Document与Chunk元数据则应继续保留上游Source与Claim关系。

这套方案的目标并不是把每一个普通句子都做成复杂数据库对象，而是首先覆盖：

关键产品数据、关键商业主张、合规信息、AI回答所依赖的核心知识。

二十、建立Provenance Quality Gate

建议在关键数据进入正式知识层或对外发布前，增加一组明确的验证条件。

Gate	验证问题	失败后的动作
Identity Gate	Source和Claim是否有稳定ID？	补充登记
Source Gate	是否可以定位上游来源？	暂停准入
Version Gate	是否明确来源版本？	版本核对
Evidence Gate	是否存在足够依据？	请求补证
Transformation Gate	是否记录关键转换规则？	重新处理
Authority Gate	是否经过有权角色确认？	提交审批
Freshness Gate	是否仍在有效期内？	触发更新
Distribution Gate	下游是否使用批准版本？	阻止或纠正发布

对于关键事实，Hard Gate失败不应简单依靠其他指标的高分来抵消。

例如，来源完全未知的工程参数，不应该因为文字描述完整、格式规范、向量相似度很高，就被自动批准发布。

本系列建议：

Provenance Gate必须在Publication Gate之前执行，并在知识库索引更新时再次核查。

二十一、让Provenance成为可观测的运营指标

如果Provenance最终只是一个登记表，很容易变成形式主义。

企业应该衡量它是否真正覆盖了关键数据链路。

可以从以下指标开始。

Critical Claim Traceability Rate

具有有效上游来源、证据和记录关系的关键Claim数量，占关键Claim总量的比例。

Provenance Completeness Rate

满足必填Provenance字段要求的记录，占应治理记录的比例。

Lineage Coverage

已经建立上游与下游依赖关系的关键资产，占应建立关系资产的比例。

Stale Dependency Count

仍然依赖已撤回或失效来源的有效下游资产数量。

Provenance Incident Resolution Time

发现来源错误或追溯链断裂后，到修复并完成验证的时间。

这些指标是本系列建议建立的内部DataOps指标，并不是Google Search Console或任何生成式搜索平台提供的官方排名指标。

一个Provenance Completeness Rate达到100%的系统，也可能保存了错误事实。

所以Provenance指标必须与Data Accuracy、Evidence Validity、Source Authority、Content Consistency共同分析。

二十二、企业可以按照三个阶段推进实施

第一阶段：让关键事实有来源

优先治理20—50个高风险字段，例如产品规格、认证状态、保修、价格与交货条件。

为它们建立Source ID、Evidence ID、Owner与Version。

这一阶段的核心成果，是能够回答：

这个值从哪里来？

第二阶段：让处理与分发过程可追溯

增加Activity Log和Distribution Registry。

记录字段提取、数据标准化、审批、网站发布和PDF生成活动。

确保一项关键数据修改以后，可以找到主要下游资产。

这一阶段的核心成果，是能够回答：

这个值是怎样变成当前展示内容的？

第三阶段：让知识检索具备治理能力

把Source、Version、Claim和Evidence元数据传递到RAG文档与Chunk。

建立有效期过滤、来源准入、撤回重建和回答证据审计。

这一阶段的核心成果，是能够回答：

为什么系统使用了这份知识，而没有使用另一个版本？

三个阶段应根据数据风险和资源能力逐步实施。

没有必要为了引入PROV-O，就在初期重建企业全部数据库。

二十三、SEO / GEO Data Provenance的MUST、SHOULD、MAY规范

以下规则属于本系列提出的企业实施规范，并非W3C或Google针对SEO/GEO发布的强制标准。

MUST｜必须

1. 关键业务事实必须能够追溯到明确Source及对应Evidence。
2. 关键数据必须保留稳定ID及来源版本。
3. 涉及关键事实含义变化的转换必须记录处理规则或活动。
4. AI生成的关键事实不得因为经过模型加工而丢失原始来源关系。
5. 发布内容涉及关键产品参数时，不得未经审批自行改变Canonical Value。
6. Source被撤回、失效或纠正后，必须能够识别重要的下游依赖。
7. 涉及安全、合规及重大商业承诺的Provenance异常，必须具备升级和处置机制。
8. 关键数据的Provenance状态不得直接等同于真实性状态。
9. 对外提供Provenance信息时必须遵守访问控制、隐私和使用授权要求。

SHOULD｜建议

企业应该建立统一的Source Registry、Claim Registry、Activity Log和Distribution Registry。

关键数据应采用稳定ID连接来源、证据、活动与发布结果。

AI知识库应保存Document-level及必要的Chunk-level Provenance。

数据处理流程应记录版本、时间、执行主体和关键转换规则。

重要证据文件宜保存可校验的完整性信息。

应建立Provenance Completeness、Lineage Coverage及Stale Dependency等监测指标。

MAY｜可选

当规模和风险达到相应程度，企业可以进一步采用：

• PROV-O / RDF知识图谱
• 自动化Data Lineage平台
• 事件驱动的Provenance采集
• 数字签名与内容凭证
• 不可随意篡改的审计存储
• RAG检索级来源策略
• 自动化影响分析
• Provenance Policy as Code

这些技术是治理的实现方式，不是治理目标本身。

二十四、Data Provenance Checklist：发布前必须回答的问题

对于每一条关键事实，发布前至少检查：

• 能否找到原始Source？
• 能否定位具体Evidence？
• 是否清楚属于哪个产品、配置及生效时间？
• 是否知道使用了哪个来源版本？
• 是否记录重要转换过程？
• 是否明确Data Owner及审批状态？
• 内容改写后是否仍然指向原Claim？
• 网页、PDF与结构化数据是否使用一致的事实版本？
• RAG Chunk是否继承来源与版本信息？
• Source撤回后能否找到受影响的下游资产？
• 是否存在需要人工处理的来源冲突？
• 公开展示的引用是否符合许可、隐私及商业保密要求？

如果这些问题大部分无法回答，企业可能已经实现了数据存储和内容生产，却仍然没有真正建立数据追溯能力。

二十五、Provenance最终改变的是企业对知识的管理方式

回顾前五篇，我们建立了：

Data → Knowledge → Source of Truth → Ownership → Source Admission。

第六篇补上的，是这些治理对象之间持续存在的关系记录。

因此，完整链路应该从：

Source
↓
Data
↓
Content

升级为：

Source Identity
↓
Evidence
↓
Provenance
↓
Validated Fact
↓
Canonical Knowledge
↓
Controlled Transformation
↓
Published Content
↓
Search / AI Retrieval
↓
Citation
↓
Outcome & Feedback

这不是要求企业公开一张巨大的知识图谱，而是要求任何一项关键事实，在经历加工与传播之后，仍然拥有返回原始依据的路径。

真正的Provenance应该支持双向追溯。

Forward Traceability：一份原始文件最终影响了哪些系统、页面和回答？

Backward Traceability：一项网页事实或AI回答，究竟使用了哪些来源和转换过程？

二者同时存在，数据治理才不再是一个单向的数据处理管道，而开始成为可审计、可纠错、可持续运行的知识系统。

写在最后：企业不应该只知道答案，还要知道答案怎样形成

如果一个客户问：“这款设备的额定功率是多少？”

企业能够回答：“82 kW。”

这只是拥有一个答案。

如果企业还能说明：

这个值来自工程规范V4.2，适用于标准50Hz配置，已经获得工程部门批准，2026年9月20日开始生效，官网和技术资料使用同一Canonical Value，AI知识库中的相关回答可以追溯到对应证据，旧版本已经被排除在当前参数检索范围之外。

那么它拥有的就不再只是一个数字，而是一项：

可追溯、可验证、可管理的知识资产。

这也是第六篇最重要的结论：

Data Provenance真正要解决的，不是文章末尾应该放几个参考链接，而是让关键事实在经过系统、人员与AI多次加工以后，仍然能够解释自己的来源、形成过程与使用资格。

SEO页面是知识的公开表达。GEO研究的是企业信息如何更好地被生成式系统理解、检索与引用。

Provenance则为这些信息提供可追溯的内部治理基础。

它不直接保证排名，不保证AI引用，更不自动保证事实正确。

但没有可靠的Provenance，企业很难对大规模知识生产与传播承担持续的质量责任。

当内容生成越来越容易，能够解释内容为什么可信，将成为更加重要的企业能力。

下一篇

《SEO / GEO 数据治理与规范标准细则（七）：Data Quality——为什么准确的数据，仍然可能是不合格的数据？》

第六篇解决了数据从哪里来，以及怎样被加工和传播。

第七篇将继续回答：

即使来源完整、版本明确，企业怎样判断这条数据真正达到了可使用质量？

我们将以Accuracy、Completeness、Consistency、Timeliness、Uniqueness、Validity为基础，结合SEO/GEO场景中的Authority、Freshness、Traceability与Fitness for Purpose，建立企业可执行的数据质量标准。

同时进一步区分质量维度、质量规则、质量阈值、质量检测、异常修复，以及数据从Staging晋升为Knowledge的条件。

最终形成：

SEO / GEO Data Quality Standard。

参考依据与标准边界

1. W3C — PROV-Overview

2013年4月30日发布的W3C Working Group Note，介绍PROV系列规范的结构、适用范围，以及通过Entity、Activity、Agent表达Provenance的基本思想。

https://www.w3.org/TR/prov-overview/

2. W3C — PROV-DM: The PROV Data Model

W3C Recommendation，定义用于描述数据及其他对象来源与生成过程的通用模型。

https://www.w3.org/TR/prov-dm/

3. W3C — PROV-O: The PROV Ontology

W3C Recommendation，定义通过OWL 2表达PROV数据模型的本体，包含prov:Entity、prov:Activity、prov:Agent、prov:wasDerivedFrom等概念。

https://www.w3.org/TR/prov-o/

4. W3C — Data on the Web Best Practices

提出提供数据来源、质量、版本和许可信息的Web数据发布最佳实践，其中Best Practice 5专门讨论Data Provenance。

https://www.w3.org/TR/dwbp/

5. W3C — Data Catalog Vocabulary Version 3

提供数据集、数据服务及其版本关系等元数据表达能力，可与PROV-O等词汇协同使用。

https://www.w3.org/TR/vocab-dcat-3/

6. Google Search Central — General Structured Data Guidelines

规定Google Search中结构化数据的技术和质量要求，包括内容一致性、准确性及非误导性。

https://developers.google.com/search/docs/appearance/structured-data/sd-policies

7. C2PA — Content Credentials Specification and Explainer

帮助区分可验证的数字内容来源信息与内容陈述本身是否真实。

https://spec.c2pa.org/

本系列自定义框架说明

本文提出的 SEO / GEO Provenance Record、Fact Provenance Chain、Claim-level Provenance、Provenance Quality Gate、Provenance Completeness Rate、Stale Dependency Count、四表最小治理模型及MUST / SHOULD / MAY要求，属于本系列面向SEO、GEO、RAG、AI搜索和数字营销数据实践设计的工程实施规范。

其中使用了W3C PROV等成熟标准的概念和属性，但并不意味着W3C、Google或其他机构已发布一套统一的SEO/GEO Provenance行业标准。