系列专题：SEO / GEO 数据治理与规范标准细则
本篇主题：Knowledge Versioning / Temporal Validity / Bitemporal Data / Knowledge Lifecycle Governance
核心关键词：Valid Time、Transaction Time、System Time、Bitemporal Model、Knowledge Version、Historical Truth、Claim Supersession、Temporal Knowledge Graph、Knowledge Revocation、Temporal RAG、Change Propagation、Knowledge Freshness、Temporal Quality Gate
一家工业设备企业已经完成了前十一篇讨论的基础数据治理工作。
产品具有稳定的Canonical Entity ID。技术参数拥有明确的Source of Truth。不同系统通过Data Contract交换数据。关键属性具备Evidence和Provenance。产品配置与技术声明之间的关系，也通过Knowledge Graph完成了语义建模与约束验证。
企业已经能够确认：哪个对象、在什么条件下、依据什么证据，具有某项技术属性。
但一次技术规范修订，仍然使企业的知识系统出现了错误。
企业长期使用的一份工程规范记载：某款工业设备在标准50Hz配置下，额定功率为82 kW。
这一数值经过正式审核，进入了PLM、PIM、WordPress产品页面及AI知识库。
随后，工程部门发现，自2026年7月1日生效的一次技术调整实际上已将该配置的额定功率改为79 kW。
这项变化直到2026年10月5日才完成跨系统核实和正式登记。
企业将最新数值修改为79 kW。从此，产品页面与AI知识库能够回答：“该配置的当前额定功率为79 kW。”
但新的问题随之出现。
客户询问：“2026年8月1日，这款设备的额定功率是多少？”
系统回答79 kW。
另一名客户询问：“我们在2026年8月1日收到报价时，企业提供的技术参数是多少？”
系统仍然回答79 kW。
这两个回答看起来一致，却忽略了一个关键事实：
2026年8月1日，企业当时掌握并对外提供的正式记录可能仍然是82 kW。
而在2026年10月5日完成追溯核实后，企业才确认：按照新的工程依据，2026年8月1日适用的值应该是79 kW。
因此，这里实际上存在两类不同的问题。
第一类：某项事实在指定业务时间究竟应当是什么？
第二类：在指定历史时点，企业当时知道并使用的事实是什么？
如果知识系统只保存最新的79 kW，就无法可靠回答第二类问题。
如果系统始终保留最初的82 kW，又无法正确回答第一类问题。
这不是普通的数据更新问题。它涉及知识的时间语义、版本关系、历史重建与纠错治理。
第十二篇将解决：
当事实发生变化、证据得到修订，或者系统后来才发现过去的错误时，企业应该怎样同时保留历史事实、历史认知和当前有效知识，并确保SEO内容、RAG与AI Agent使用正确的时间版本？
这正是Knowledge Versioning与Temporal Validity需要解决的问题。
一、为什么一条曾经正确的知识，今天可能不再适用？
企业数据治理经常将准确性视为重要质量目标。但准确性并不是脱离时间而独立存在的。
例如：某家公司曾经是设备经销商。某项技术参数曾经适用于旧版产品。某个销售价格只在特定期间有效。某个认证文件具有明确有效期。某套售后政策只适用于指定订单或购买时间。
这些信息即使真实，也不一定适用于当前业务。
因此，知识质量需要区分两个概念。
Factual Correctness：事实在其适用条件下是否正确。
Temporal Applicability：事实是否适用于当前问题指定的时间。
如果系统没有管理Temporal Applicability，就可能将历史上成立的关系作为当前事实使用。
例如2025年的有效经销关系在2026年已经终止，但AI仍然根据2025年的资料回答：“该企业目前是授权经销商。”
这类错误不一定来自模型生成能力不足。根本原因可能是知识系统没有表达或者执行关系的有效时间。
因此，第十二篇首先确立一项原则：
Knowledge Accuracy必须包含Temporal Validity。
一项历史上真实的事实，如果被错误用于当前场景，仍然可能形成错误答案。
二、Knowledge Versioning不等于保存文件历史版本
企业通常已经使用一些版本管理方式：WordPress文章修订版本、PLM工程文件版本、PIM产品资料版本、数据库历史记录、Git提交历史。
这些机制都有价值。但它们主要记录某项资源或系统对象如何发生变化。
Knowledge Versioning需要进一步回答：某个业务Claim在什么时间成立？企业在什么时间知道它成立？它何时被修订、撤销或者替代？
例如：技术规范由V4.1更新为V4.2，属于Document Version Change。
额定功率从82 kW调整到79 kW，属于Attribute Claim Change。
调整从7月1日开始适用，属于Valid Time Change。
企业在10月5日完成核实，属于Knowledge Recording或System Knowledge Change。
产品页面在10月6日完成更新，属于Publication Change。
这些变化之间存在关系，却不能混为同一个时间或版本。
因此：Document Version、Data Version、Claim Version与Publication Version需要分别管理。
三、企业知识到底存在多少种时间？
一个成熟的数据治理体系不应该只拥有一个updated_at字段。
实际业务至少可能涉及以下时间概念。
| 时间类型 | 核心含义 | 示例 |
|---|---|---|
| Event Time | 业务事件实际发生时间 | 技术调整发生于7月1日 |
| Valid Time | 事实在业务上成立的时间 | 新参数自7月1日起适用 |
| Source Recorded Time | 来源系统记录事实的时间 | PLM在7月3日记录 |
| Knowledge Recorded Time | 治理系统正式获知并登记的时间 | 10月5日完成登记 |
| Approved Time | 事实经过正式批准的时间 | 10月5日工程审批 |
| Published Time | 内容对外发布的时间 | 10月6日产品页更新 |
| Retrieved Time | AI或业务系统检索知识的时间 | 11月9日发生查询 |
| Observed Time | 监测系统观察到状态的时间 | 日志在11月9日记录 |
这些时间并非每个业务对象都必须全部保存。
但关键知识至少需要明确业务有效时间、系统认知时间，以及相应的来源、审批和发布记录。
最重要的区别是：事实何时有效，不一定等于系统何时记录，也不一定等于网站何时发布。
四、Valid Time：事实在业务上什么时候成立？
Valid Time，也称Business Valid Time，表示事实在业务世界中适用的时间范围。
例如某设备配置在2026年7月1日开始采用79 kW额定功率。
那么，在已经核实且具有适用依据的情况下，可以记录：
{
"claim_id": "CLAIM-FW30-079",
"entity_id": "CONFIG-FW30-50HZ",
"attribute": "rated_power_kw",
"value": 79,
"unit": "kW",
"valid_from": "2026-07-01T00:00:00Z",
"valid_to": null
}这里的valid_from表示业务生效时间。
valid_to: null在本示例中代表尚未确定结束时间。但这并不代表事实永远成立。如果未来出现新版本，还需要按照业务规则终止或调整其适用区间。
另外，Valid Time必须与Context共同使用。79 kW适用于Standard 50Hz配置，不能未经核实就将其推广到其他电压、频率或客户定制配置。
因此：Valid Time定义“何时成立”，Context定义“在什么条件下成立”。
二者都不可缺少。
五、Transaction Time与System Time：系统什么时候知道这件事？
在双时间轴模型中，另一条重要时间轴通常是Transaction Time或System Time。
它用于表达某项记录在数据库或知识治理系统中处于可见、被保存状态的时间范围。
为了避免概念混淆，本文使用：
Knowledge Recorded Time / System Knowledge Period
表示企业治理系统在什么时间拥有相应版本的正式记录。
例如：2026年8月1日，企业系统仍然认为额定功率为82 kW。
2026年10月5日，系统接收到并批准修订信息，开始认为7月1日之后适用79 kW。
这里的System Time并不改变7月1日的业务生效事实。
它记录的是：系统什么时候才正式掌握并保存这种认知。
需要注意，企业自己建立的recorded_at字段，不会自动获得数据库系统版本表的全部行为。
只有实际实施了受控的时间版本管理、审计和查询机制，才能构成可靠的系统时间模型。
六、Bitemporal Model：为什么企业需要两条时间轴？
Bitemporal Data Model，即双时间数据模型。
它同时管理：
Valid Time：业务事实在何时成立。
Transaction / System Time：某个事实版本在系统中何时被记录和认为有效。
可以表示为：
Business Valid Time
2026-01 2026-07 2026-11
│ │ │
├───────────┼───────────┤
│ │ │
System Knowledge │ │ │
Time │ │ │
│ │ │
2026-03 旧认知 82 kW 82 kW 82 kW
│ │ │
2026-10 完成纠正 82 kW 79 kW 79 kW这个示意表示：系统在3月建立的旧认知认为82 kW持续适用。
10月核实后，系统纠正为：7月1日以前82 kW，7月1日起79 kW。
因此，同一个业务日期的答案，可能因所选择的系统认知时点不同而发生变化。
这不是数据库存在矛盾，而是系统保留了：
当时的认知与后来完成核实的事实之间的差异。
七、一个完整的双时间轴案例
仍然使用前面的工业设备案例。
为了明确说明机制，假设企业拥有以下受治理记录。
| Assertion | 额定功率 | Business Valid Time | System Knowledge Time |
|---|---|---|---|
| A1 | 82 kW | 2026-01-01至未定 | 2026-03-01至2026-10-05 |
| A2 | 82 kW | 2026-01-01至2026-07-01 | 2026-10-05以后 |
| A3 | 79 kW | 2026-07-01以后 | 2026-10-05以后 |
这里采用左闭右开区间：[start, end)，即包含起始时间，不包含结束时间。
这能够避免两个连续版本在边界时间产生重叠。
所有日期与数值均为本文构造的技术示例，不代表真实企业或设备。
问题A：2026年8月1日，企业当时掌握的参数是什么？
业务时间：2026年8月1日。
系统认知时间：2026年8月1日。
答案：82 kW。 因为当时系统中仍然保存着旧认知。
问题B：现在重新核实，2026年8月1日真正适用的参数是什么？
业务时间：2026年8月1日。
系统认知时间：2026年11月9日。
答案：79 kW。 因为10月5日完成的追溯核实确认，79 kW从7月1日起适用。
问题C：现在重新核实，2026年6月1日适用的参数是什么？
业务时间：2026年6月1日。
系统认知时间：2026年11月9日。
答案：82 kW。 因为6月1日处于旧参数的有效时间范围。
这三个问题说明：回答历史事实，不只需要一个历史日期，还需要明确采用哪个认知版本。
八、Historical Truth与Historical Belief为什么不能混为一谈？
在企业数据系统中，可以区分：
Current Best-Known Historical Truth：目前根据最新核实结果，对某个历史时点的最佳事实判断。
Historical System Belief：企业在历史时点实际记录并使用的认知。
例如，现在认为2026年8月1日的正确参数是79 kW，但当时企业系统提供的是82 kW。
这两项信息可以同时成立。
前者用于技术事实重建，后者用于报价审计、历史决策复盘和责任分析。
因此，企业不能简单删除旧值，否则可能无法解释：
当时为什么按照82 kW进行报价？
客户为什么收到相应技术文件？
销售人员当时能够访问哪份资料？
后续纠正是什么时候开始传播的？
修正历史认知，不应抹去历史上确实发生过的认知与使用行为。
九、知识版本不应该等于文档版本
第十一篇已经建立Entity–Relation–Claim–Evidence结构。
第十二篇需要进一步区分各个对象的版本。
| 版本类型 | 主要描述 | 典型变更 |
|---|---|---|
| Entity Version | 实体状态与属性历史 | 产品型号退役 |
| Claim Version | 某项事实性声明的变化 | 额定功率修订 |
| Evidence Version | 证据材料变化 | 技术规范V4.2替代V4.1 |
| Relation Version | 实体关系变化 | 经销授权结束 |
| Ontology Version | 概念与关系定义变化 | 关系适用范围修订 |
| Contract Version | 数据交换约定变化 | 必填时间字段新增 |
| Publication Version | 对外内容变化 | WordPress页面更新 |
| Retrieval Index Version | AI检索索引状态变化 | Chunk重新索引 |
这些版本可能相互依赖，但不应该使用单一版本号代表全部状态。
例如某技术规范新增了维护说明，文档版本可能改变，但产品额定功率未必改变。
相反，如果一项技术Claim被追溯修订，即使文档标题和URL未变化，知识系统也需要记录独立的Claim Version。
因此：Knowledge Version应该围绕实际发生变化的知识对象管理，而不是只围绕文件管理。
十、Claim Version应该具备哪些核心字段？
第十一篇已经提出Claim–Evidence Registry。
现在需要为它增加时间版本能力。
一个基础Claim Version Record可以设计为：
{
"claim_version_id": "CLV-FW30-079-V2",
"claim_key": "CONFIG-FW30-50HZ/rated_power_kw",
"entity_id": "CONFIG-FW30-50HZ",
"predicate_id": "rated_power_kw",
"value": 79,
"unit": "kW",
"context_id": "standard_50hz",
"valid_from": "2026-07-01T00:00:00Z",
"valid_to": null,
"known_from": "2026-10-05T00:00:00Z",
"known_to": null,
"assertion_status": "APPROVED",
"evidence_id": "EV-TECH-079",
"supersedes": "CLV-FW30-082-V1",
"approved_by_role": "Engineering Data Owner"
}这是本系列自定义的企业实施格式，不是W3C、ISO或Google统一制定的Claim Version Schema。
关键是稳定的Claim身份与单个Claim Version身份需要区分。
同一知识主题可以拥有多个历史版本，每个版本都应拥有独立的业务有效区间和系统认知区间，同时保留Evidence、Context、审批与修订关系。
对于需要支持历史重建的系统：仅有created_at和updated_at通常不足以表达完整的知识时间语义。
十一、Claim Supersession：新版本替代旧版本意味着什么？
Supersession通常表示一个版本被后续版本取代。
但这里仍然有一个重要问题：取代的是全部历史，还是某个有效时间范围？
例如，新参数79 kW从7月1日开始生效，它不意味着1月至6月的82 kW也被否定。
因此，系统不应该简单执行：
DELETE old claim
INSERT new claim然后让所有历史查询都返回79 kW。
更合理的处理是保留旧Claim的历史认知记录，明确新Claim的业务生效范围，保留修订事件，根据新的时间边界生成当前最佳知识视图。
需要注意：supersedes只是说明版本替代关系。
它本身并不能自动表达替代从哪个业务时间开始生效。
时间范围仍然需要独立管理。
十二、Correction与Business Change不是同一件事
知识版本变化至少可以分为两类。
Business Change：业务事实本身发生变化。 例如一款设备于7月1日开始采用新配置。
Correction：系统发现过去记录的某项事实不正确。 例如实际参数从7月1日起已发生变化，但系统直到10月才发现。
二者的治理含义不同。
Business Change通常需要明确变更何时发生，哪些新事实开始有效，哪些旧事实结束适用。
Correction则还需要明确错误何时进入系统、错误影响了哪些时间段、哪些下游消费者曾经使用错误信息、是否需要追溯修复。
所以：数据被更新，不代表企业已经正确处理历史事实。
对于Correction，必须进一步执行Retroactive Impact Analysis。
十三、Retroactive Correction为什么不能简单覆盖旧记录？
Retroactive Correction，即追溯性更正。它是指企业后来确认某个事实在过去某段时间已经与原记录不同。
例如：10月5日发现7月1日起适用79 kW。
如果系统仅将82改成79，可能破坏两类能力。
首先，无法复原8月份的历史系统认知。
其次，可能错误地使79 kW适用于1月至6月。
因此，追溯更正需要至少处理：被更正的业务时间范围、更正被正式记录的系统时间、原始Assertion、新Assertion、支持证据、审批、受影响的消费者、更正发布状态。
本系列建议：Retroactive Correction必须形成独立的Correction Event，并保留与原始Claim Version的关系。
十四、为什么需要采用左闭右开的时间区间？
时间区间可以采用不同的包含规则。
但如果缺少统一约定，系统很容易在版本边界产生重复适用或空档。
例如：旧版本有效至2026年7月1日，新版本从2026年7月1日开始。
如果两者都包含7月1日，系统可能认为两个值同时有效。
因此，本系列建议在适用的技术实现中采用：
[start, end)即包含起始时间，不包含结束时间。
例如：
82 kW:
[2026-01-01, 2026-07-01)
79 kW:
[2026-07-01, infinity)这样，业务时间恰好等于2026年7月1日的查询，只会命中新版本。
这一设计符合PostgreSQL时间范围类型所支持的区间表达方式。
官方参考：https://www.postgresql.org/docs/current/rangetypes.html
需要注意：采用左闭右开区间是本文的实施约定，不代表全部企业、行业或数据库系统必须采用相同表示。
关键是企业必须明确并持续执行统一规则。
十五、时间戳必须明确时区
对于跨境企业，时间表达还存在时区问题。
例如：2026年7月1日00:00。
它到底是北京时间？还是UTC？或者某个海外工厂所在地的当地时间？
如果缺少时区，两个系统可能把同一个字符串解释为不同的绝对时间。
RFC 3339提供了一种基于ISO 8601的互联网日期时间表示格式。
例如：
2026-07-01T00:00:00Z代表UTC时间。
2026-07-01T08:00:00+08:00代表相同的绝对时刻。
RFC 3339官方文档：https://www.rfc-editor.org/rfc/rfc3339.html
对于跨系统交换的时间戳，本系列建议使用明确的UTC时间或带有准确UTC偏移量的时间戳。
对于按当地民事日期生效的政策，还应保留对应的业务时区，例如Asia/Shanghai。
因为仅保存一个固定偏移量，未必足以表达跨越夏令时调整的长期业务规则。
十六、时间精度也属于数据契约
即使具有正确时区，系统仍然可能因为时间精度不同产生错误。
例如：某合同自2026年7月1日生效。
另一个系统将其解释为7月1日08:00 UTC，还有一个系统将其理解为当地时间当天00:00。
它们可能不是同一时刻。
此外，某些事实只有日期精度，例如“2026年第三季度适用”，或者“2026年7月开始执行”。
此时，企业不应该为了满足数据库字段而随意编造一个精确到秒的实际发生时间。
应当保存时间值、时间精度、时间解释规则、时区和来源。
例如：
{
"effective_date": "2026-07-01",
"precision": "DAY",
"business_timezone": "Asia/Shanghai",
"effective_rule": "LOCAL_START_OF_DAY"
}这样，系统才能明确如何把业务日期转换为技术查询边界。
Time Precision也是Knowledge Metadata的一部分。
十七、未知时间不等于无限有效
这是时间治理中很容易被误处理的问题。
假设某历史技术文件没有注明生效日期。
系统可能直接使用valid_from = null，然后把它解释为自始至终有效。
但这里实际上至少存在三种情况。
第一，事实确实长期有效。
第二，事实的生效时间未知。
第三，事实的适用时间尚未核实。
这三种情况完全不同。
因此，本系列建议：Unknown Validity与Open-ended Validity必须区分。
例如：
{
"validity_status": "UNKNOWN",
"valid_from": null,
"valid_to": null
}与：
{
"validity_status": "VERIFIED_OPEN_ENDED",
"valid_from": "2026-07-01T00:00:00Z",
"valid_to": null
}不能具有相同的自动发布资格。
对于关键工程事实，如果缺少有效时间依据，应根据风险进入人工复核或限制使用状态。
十八、如何建立Bitemporal Knowledge Registry？
企业可以在现有Claim Registry上增加双时间轴支持。
一个基础数据结构可以包含：
claim_version_id
claim_key
entity_id
predicate_id
context_id
value
unit
valid_from
valid_to
known_from
known_to
source_id
evidence_id
approval_status
correction_event_id
supersedes_version_id
created_by其中：
claim_key定义同一知识主题。
claim_version_id识别单个历史版本。
valid_from与valid_to定义业务时间范围。
known_from与known_to定义治理系统中该版本的认知时间范围。
需要强调：如果使用数据库自身的System-versioned Temporal Table，那么系统时间可能由数据库自动维护。
如果只是使用普通表和人工定义的字段，则必须额外建立受控写入、事务隔离与审计机制。
不能把两个普通时间字段的存在，直接宣称为完整的Bitemporal Database。
十九、PostgreSQL怎样实现基础双时间查询？
PostgreSQL提供Range Types。其中tstzrange可用于表示带时区时间戳范围。
它也支持使用GiST与Exclusion Constraint管理范围重叠。
官方文档：
https://www.postgresql.org/docs/current/rangetypes.html
https://www.postgresql.org/docs/current/ddl-constraints.html
下面是本系列提出的最小工程示例。
CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE TABLE claim_versions (
claim_version_id TEXT PRIMARY KEY,
entity_id TEXT NOT NULL,
predicate_id TEXT NOT NULL,
context_id TEXT NOT NULL,
numeric_value NUMERIC NOT NULL,
unit TEXT NOT NULL,
evidence_id TEXT NOT NULL,
valid_period TSTZRANGE NOT NULL,
known_period TSTZRANGE NOT NULL,
CHECK (NOT isempty(valid_period)),
CHECK (NOT isempty(known_period)),
EXCLUDE USING gist (
entity_id WITH =,
predicate_id WITH =,
context_id WITH =,
valid_period WITH &&,
known_period WITH &&
)
);这份表结构表达了一项基础约束：
对于同一个Entity、Predicate和Context，不允许两个不同版本在业务时间和系统认知时间两个维度上同时发生重叠。
但它属于简化的单值属性模型。
对于允许多值的关系、多来源冲突记录或尚未批准的候选Claim，应使用独立的Assertion Layer或调整约束范围。
同时，known_period必须由可信写入流程维护。
正式生产中还需要事务控制、写入权限、不可篡改的变更日志、证据关联以及版本状态管理。
不能只使用这张表就认为已经完成全部知识版本治理。
二十、如何查询“当时系统认为是什么”？
仍然使用前面的FW-30案例。
假设数据库已经保存A1、A2、A3三个版本。
现在需要查询：2026年8月1日，企业在当时掌握的额定功率是什么？
可以同时指定业务时间与系统认知时间。
SELECT
claim_version_id,
numeric_value,
unit,
evidence_id
FROM claim_versions
WHERE entity_id = 'CONFIG-FW30-50HZ'
AND predicate_id = 'rated_power_kw'
AND context_id = 'standard_50hz'
AND valid_period @>
TIMESTAMPTZ '2026-08-01T00:00:00Z'
AND known_period @>
TIMESTAMPTZ '2026-08-01T00:00:00Z';预期结果：
Claim Version: A1
Rated Power: 82 kW这里没有使用最新记录覆盖历史认知。
因为查询明确要求业务时间是8月1日，系统认知时间也是8月1日。
这类查询对历史报价审计、客户争议复盘、销售决策回溯、技术承诺来源分析和历史AI回答追踪具有实际价值。
二十一、如何查询“现在核实的历史事实”？
接下来仍然询问2026年8月1日的技术参数。
但系统认知时间改变为2026年11月9日。
SELECT
claim_version_id,
numeric_value,
unit,
evidence_id
FROM claim_versions
WHERE entity_id = 'CONFIG-FW30-50HZ'
AND predicate_id = 'rated_power_kw'
AND context_id = 'standard_50hz'
AND valid_period @>
TIMESTAMPTZ '2026-08-01T00:00:00Z'
AND known_period @>
TIMESTAMPTZ '2026-11-09T00:00:00Z';预期结果：
Claim Version: A3
Rated Power: 79 kW两个查询使用相同的业务时间，却采用不同的认知时点，因此返回不同结果。
这正是双时间轴模型的核心能力。
需要补充的是：
当前最佳认知不等于绝对不可更改的历史真理。
如果未来出现新的有效证据，企业仍然可能再次修订历史事实。
因此，对外解释时更合适的表达是：
“根据当前已核实的工程依据，2026年8月1日适用值为79 kW。”
而不是宣称企业已经永久确定了不可再修订的绝对事实。
二十二、为什么不能只依赖数据库系统版本表？
一些数据库提供System-versioned Temporal Table能力。
例如Microsoft SQL Server可通过系统维护的时间区间和历史表，记录数据行随数据库操作发生的变化。
官方来源：https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables
这类机制能够帮助恢复数据库在历史时刻保存的行状态。
但它本身不能自动解决全部业务有效时间问题。
例如数据库在10月5日更新了某项产品参数。
系统版本表能够保存10月5日前后的数据库状态。
但它不会仅凭这项更新，就自动知道新参数实际上从7月1日开始生效。
因此：System Versioning与Business Validity仍然需要分别建模。
如果企业希望同时回答“当时系统记录什么？”和“现在认为当时业务上应当是什么？”，就需要同时具备系统时间和业务时间的正式语义。
二十三、Knowledge Event Log应该记录什么？
双时间轴提供时间结构，但知识如何发生变化，仍然需要事件记录。
本系列建议建立Knowledge Change Event Log。
例如：
{
"event_id": "KCE-2026-0042",
"event_type": "RETROACTIVE_CORRECTION",
"claim_key": "CONFIG-FW30-50HZ/rated_power_kw",
"old_version_id": "CLV-FW30-082-V1",
"new_version_id": "CLV-FW30-079-V2",
"business_effective_from": "2026-07-01T00:00:00Z",
"recorded_at": "2026-10-05T00:00:00Z",
"evidence_id": "EV-TECH-079",
"approval_status": "APPROVED",
"change_reason": "Verified engineering correction"
}事件至少应回答：发生了什么变化？涉及哪项知识？原版本是什么？新版本是什么？业务何时生效？系统何时确认？依据是什么？谁批准？影响哪些使用者？
事件记录可以帮助企业建立可靠的审计与影响分析能力。
但需要注意：Event Log与Bitemporal Query不是同一种功能。
事件日志记录变化过程。
双时间轴视图则用于重建特定时间条件下的知识状态。
两者通常需要协同使用。
二十四、Event Sourcing与Knowledge Snapshot应该怎样配合？
Event Sourcing可以通过一系列事件重建系统状态。
例如：创建Claim、批准Claim、修订Claim、撤销Claim、重新批准。
但如果企业每次回答AI问题都必须从最早事件重新计算整个知识状态，查询成本可能过高。
因此，可以建立Materialized Snapshot或Read Model。
例如：当前有效Claim视图、指定日期的历史Claim视图、面向WordPress的发布视图、面向RAG的检索视图。
这里需要一项重要约束：
Snapshot必须能够说明它根据哪些事件、数据与规则生成。
否则，当发现错误时，系统可能无法确认某个快照是否需要重新构建。
因此，Snapshot至少应保留Source Event Offset、Claim Version、Ontology Version、Validation Policy Version、Build Time、Publication Status。
这些信息共同形成Temporal Knowledge Snapshot Manifest。
二十五、为什么“最新记录优先”不是可靠的版本裁决规则？
企业数据系统经常采用Last Write Wins，即选择更新时间最新的记录。
这在某些简单数据同步场景中可能有用。
但对于业务事实，最新写入不等于当前有效。
例如：某历史规范刚刚完成数字化，系统将它作为最新上传文件。
如果直接采用最近上传时间，就可能覆盖当前已经批准的新参数。
因此，版本裁决至少需要考虑Entity Identity、Attribute Authority、Context、Valid Time、System Knowledge Time、Evidence、Approval Status和Correction Relationship。
不能只比较updated_at或者version_number。
尤其需要注意：版本号较大，并不意味着其内容适用于所有历史时间。
Knowledge Version Selection必须由业务时间、身份、上下文和权威规则共同决定。
二十六、Temporal Conflict应该怎样定义？
第十一篇已经建立Graph Conflict分类。
现在需要进一步明确Temporal Conflict。
例如：同一个配置在相同业务时间存在两个互相冲突的批准参数；某项新版本已经生效，但旧版本未终止；某个已经撤销的Claim继续被标记为当前有效；某项未来才生效的政策被提前用于当前报价；某份技术文件已经废弃，但RAG索引仍然优先使用。
这些问题并非全部属于普通的字段值冲突。
需要建立时间层面的检查规则。
本系列建议区分：
Valid Time Overlap Conflict。
Knowledge Version Selection Conflict。
Expired Evidence Conflict。
Future-effective Leakage。
Revoked Claim Reuse。
Downstream Publication Lag。
不同冲突应采用不同的处理策略。
例如时间区间重叠可能由结构约束检测；证据是否失效可能需要连接Evidence Registry；下游页面延迟更新则需要依靠发布监测和内容回读。
二十七、Claim Revocation与Supersession有什么区别？
Supersession通常表示某个版本被新版本取代。
Revocation则强调某项声明或使用资格被撤销。
二者不应混淆。
例如：82 kW在旧配置下曾经有效，后续被79 kW替代，这可能属于正常的Supersession。
而如果企业发现某项认证声明从未获得真实依据，则可能需要Revocation。
撤销并不意味着原始记录应该被物理删除。
企业通常仍然需要保留原始声明、撤销依据、撤销时间、相关审批、受影响的公开内容和后续修复结果。
但在当前正式知识视图中，应阻止已经撤销的声明继续作为有效事实使用。
因此：历史保留与当前使用资格必须分开。
二十八、W3C PROV-O怎样描述知识修订与失效？
第六篇已经介绍Data Provenance。
在时间治理中，W3C PROV-O还提供了描述Entity生成、修订和失效的相关词汇。
例如：prov:generatedAtTime、prov:invalidatedAtTime、prov:wasRevisionOf。
这些属性可以用于表达知识实体或资料版本在来源与生命周期中的变化。
官方依据：https://www.w3.org/TR/prov-o/
例如：
@prefix ex: <https://example.org/kg/> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
ex:ClaimVersion2
a prov:Entity ;
prov:wasRevisionOf ex:ClaimVersion1 ;
prov:generatedAtTime
"2026-10-05T00:00:00Z"^^xsd:dateTime .这里表示新版本与旧版本之间存在修订关系，并记录新版本的生成时间。
但必须特别区分：
PROV实体生成或失效时间，不等于业务Claim的Valid Time。
例如新Claim Version在10月5日生成，它所表达的业务事实却可能从7月1日起成立。
因此，不应该把prov:generatedAtTime直接当成business_valid_from。
也不能仅凭prov:wasRevisionOf确定业务版本的生效区间。
企业仍然需要自己的Temporal Claim Model。
二十九、Evidence Version变化以后，哪些Claim应该重新验证？
假设Engineering Specification V4.2被V4.3取代。
这并不自动意味着所有使用V4.2的Claim都错误。
但它确实意味着：企业需要评估这些Claim是否仍然获得有效支持。
例如：V4.3只修改维护说明，额定功率仍然没有变化。此时，产品技术参数可能不需要修订。
另一种情况是：V4.3明确纠正了某项额定功率，那么依赖该参数的Claim必须重新审查。
因此，Evidence Version Change应该触发：
Dependency-based Revalidation。
即先查找依赖被修订Evidence的Claim，再根据变更内容判断影响范围，随后更新必要的Claim Version，最后传播到受影响的内容与AI知识资产。
这比直接将所有依赖文档的内容全部重写更合理。
三十、为什么知识更新必须具备Impact Graph？
前十一篇已经建立Entity、Relation、Claim与Evidence之间的关联。
这些关系在时间治理中具有另一个重要价值：
帮助企业定位某次知识变化影响了哪些消费者。
例如：
Engineering Specification
↓
Rated Power Claim
↓
Product Configuration
↓
Golden Record
↓
┌──────┼──────┬──────┐
↓ ↓ ↓ ↓
PIM CMS PDF RAG
↓ ↓ ↓
Quote Website AI Answer当Claim发生追溯性修订时，系统可以沿着依赖关系识别：
哪些产品页面包含旧值？
哪些PDF仍然引用旧参数？
哪些报价模板需要更新？
哪些RAG Chunk需要撤销或重新索引？
哪些自动化任务已经使用了错误版本？
因此：Knowledge Change必须能够传播到Data Consumer，而不能只停留在主数据层。
三十一、Change Propagation应该怎样进入生产系统？
企业可以建立正式的Knowledge Change Pipeline。
例如：
Approved Knowledge Change
↓
Temporal Claim Update
↓
Identity / Context Check
↓
Impact Graph Analysis
↓
Consumer Notification
↓
CMS / PIM / RAG Update
↓
Publication Verification
↓
Incident Closure其中最重要的不是简单发送通知，而是确认：
消费者是否真正接收了变化？
是否成功更新相应数据？
是否产生新的版本？
是否存在失败任务？
是否有消费者仍然使用旧数据？
因此，Change Propagation应支持幂等执行、失败重试、操作日志、消费者确认、必要的死信队列、超时升级。
在跨系统环境中，还应避免出现主数据已经成功更新，但事件通知没有发出的情况。
可以根据系统架构选择Transactional Outbox或其他可靠事件交付机制。
三十二、Knowledge Freshness不能只看最近更新时间
企业可能通过文件上传日期、文章修改日期、索引构建日期、最后一次抓取时间判断知识是否新鲜。
但这些指标无法单独证明知识内容仍然有效。
例如：一份旧技术手册今天重新上传，它的上传时间很新，但内容可能早已不再适用于当前产品。
反过来：某项技术参数三年没有变化，它不一定已经过时。
因此，Knowledge Freshness应结合是否存在新的权威来源、当前Evidence是否有效、Claim是否仍在适用时间范围内、是否完成规定的复核、是否存在未传播的版本变化。
对于企业治理，可以定义：
Temporal Freshness不是“数据有多新”，而是“系统在指定用途下使用的知识是否仍然适用”。
这一区别对SEO/GEO内容尤其重要。
三十三、Knowledge Update SLA应该怎样制定？
不同知识的更新紧急程度并不相同。
例如重要安全信息、产品认证变化、价格政策、额定功率、售后服务说明、普通产品展示文案。
它们的风险等级和业务影响不同。
本系列建议按风险建立Knowledge Update SLA。
以下为示例性的内部服务目标，不是行业统一要求。
| 知识类型 | 典型风险 | 建议治理方式 |
|---|---|---|
| 安全或重大合规信息 | 严重 | 立即隔离旧声明并升级处理 |
| 关键工程参数 | 高 | 审批后优先传播并回读核验 |
| 价格与交易政策 | 高 | 按正式生效时间同步 |
| 组织与经销关系 | 中至高 | 依据授权有效期更新 |
| 普通产品描述 | 中 | 纳入计划更新 |
| 一般背景知识 | 较低 | 周期性复核 |
真正的SLA应明确发现到确认的时限、确认到批准的时限、批准到生产传播的时限、发布到回读验证的时限、超过时限后的升级责任。
企业可以根据实际系统能力设置目标。
不能把未经实际监测的目标时限当成已达成的治理能力。
三十四、WordPress为什么不能只依赖文章修订历史？
WordPress具备文章修订与修改时间等能力。
但这些信息主要描述网站内容资源自身的变化。
例如产品页面在10月6日更新，这可以反映页面内容曾经发生修改。
但不能直接证明技术参数从10月6日起才生效，因为参数可能从7月1日就已经适用。
因此，建议WordPress关键技术页面额外关联：
Canonical Entity ID。
Claim Version ID。
Evidence ID。
Business Valid Time。
Publication Version。
Content Review Status。
例如：
{
"post_id": 420,
"canonical_entity_id": "PRODUCT-MODEL-000184",
"claim_version_id": "CLV-FW30-079-V2",
"evidence_id": "EV-TECH-079",
"knowledge_valid_from": "2026-07-01",
"content_published_at": "2026-10-06T09:00:00+08:00",
"content_status": "VERIFIED"
}其中knowledge_valid_from属于企业内部知识治理，content_published_at属于网站发布事件。
两者必须区分。
WordPress文章版本可以作为内容审计依据，但不能替代Bitemporal Knowledge Registry。
三十五、Article的datePublished与dateModified应该怎样使用？
Google Search Central的Article结构化数据文档，建议网站在适用时提供datePublished、dateModified，并建议包含准确的时区信息。
Google还明确建议这些日期与网页中相应可见日期保持一致。
官方来源：
https://developers.google.com/search/docs/appearance/structured-data/article
https://developers.google.com/search/docs/appearance/publication-dates
例如：
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Industrial Equipment Technical Guide",
"datePublished": "2026-03-01T09:00:00+08:00",
"dateModified": "2026-10-06T09:00:00+08:00"
}这表示文章首次发布时间为3月1日，文章最后一次相应修改时间为10月6日。
它不能被解释为产品技术参数在10月6日才开始生效。
同样，也不能为了使文章显得更新，就随意修改dateModified而不进行相应的真实内容更新。
Google的公开文档强调，页面日期应真实反映发布或重要更新情况。
因此：SEO Publication Date与Business Knowledge Valid Time必须保持语义独立。
三十六、Sitemap lastmod为什么不能被当成知识生效日期？
Google在Sitemap文档中说明：
<lastmod>应反映页面最后一次重要更新的日期或时间。
它会在该值持续、可验证地准确时考虑这一信息。
Google也说明，主要内容、结构化数据或页面链接发生重要变化，通常可以构成有意义的更新。
官方来源：https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
例如：
<url>
<loc>https://example.org/products/fw-30/</loc>
<lastmod>2026-10-06</lastmod>
</url>这里的10月6日表达网页在这一天发生重要更新。
不应该被解释为设备额定功率从10月6日开始生效。
产品事实的Valid Time应由内部知识治理系统管理。
Sitemap lastmod则由实际网页更新情况决定。
两者可能具有业务关联，但不属于同一个时间字段。
同时：更新Sitemap并不保证Google立即抓取、重新索引或者采用最新内容。
企业仍然需要通过正常的抓取、索引和搜索表现监测确认实际效果。
三十七、SEO历史内容应该修改、保留还是归档？
当某项知识过时，网站可能有几种处理方式：直接更新现有页面；保留历史内容并增加说明；创建具有明确版本身份的新页面；将旧内容归档。
对于持续代表同一产品或主题的页面，通常可以在保留合适URL的同时更新内容。
但如果不同历史版本具有独立使用价值，例如旧设备技术手册、历史版本兼容性说明、已停止销售型号的售后资料，则可能需要保留专门的历史资源。
此时，页面必须清楚说明对应版本、适用型号或配置、有效时间、是否仍然适用于当前产品。
例如：
“该文档适用于2025年生产的指定配置，不代表当前在售版本的全部技术参数。”
这比简单删除全部历史资料更有利于售后、审计和准确的信息获取。
但不应为了扩大SEO页面数量而无条件创建大量差异极小的历史版本页面。
网站信息架构仍然需要依据实际用户任务和独立内容价值决定。
三十八、公开纠错与静默修改之间应该怎样选择？
并不是所有数据变化都必须向用户发布更正声明。
例如普通排版修复、无实质影响的用词调整、内部Metadata纠错，通常不一定需要明显的对外说明。
但如果变化涉及重要技术参数、安全警告、采购决策、认证或合规声明、已经发出的商业承诺，就需要评估是否提供明确的纠错信息。
例如：
技术资料更正说明
本页面于2026年10月6日更新相关技术参数。
经核实，标准50Hz配置的额定功率
自2026年7月1日起适用79 kW。
此前版本中的82 kW不再适用于该日期之后
的指定配置。
具体适用范围请以相应工程规范为准。该示例说明什么时候发现并发布了更正、哪些历史事实被修订、修订适用于什么时间和配置、如何找到正式依据。
对于具有实际决策影响的知识纠错，透明说明往往比无解释地覆盖旧值更便于维护信任。
三十九、RAG为什么需要Temporal Retrieval？
第十一篇已经提出Entity-aware Retrieval。
它通过Entity ID、Relation、Context和Evidence防止跨实体知识混用。
但如果系统没有时间过滤，仍然可能产生错误。
例如向量数据库同时保存V4.1、V4.2、V4.3技术规范。
这些文档都真实存在。
如果用户询问当前技术参数，系统却检索到历史版本，那么最终回答仍然可能不正确。
因此，需要在Entity-aware Retrieval基础上加入：Temporal Retrieval。
也就是根据用户问题与业务规则，选择适当的业务时间和知识认知版本。
例如：
User Question
↓
Resolve User Task
↓
Resolve Entity & Context
↓
Resolve Business As-of Time
↓
Resolve Knowledge As-known-at Time
↓
Temporal Claim Filtering
↓
Evidence & Version Check
↓
Semantic Retrieval
↓
Answer Generation这里的两个时间条件必须能够被区分。
否则，系统可能只选择最新文件，却仍然无法回答历史问题。
四十、Temporal RAG应该怎样定义查询契约？
本系列建议为高风险知识查询增加Temporal Query Contract。
例如：
{
"query_id": "Q-2026-001",
"entity_id": "CONFIG-FW30-50HZ",
"predicate_id": "rated_power_kw",
"context_id": "standard_50hz",
"business_as_of": "2026-08-01T00:00:00Z",
"knowledge_as_of": "2026-11-09T00:00:00Z",
"query_mode": "CURRENT_BEST_KNOWN_HISTORY",
"require_approved_claim": true,
"require_valid_evidence": true
}其中business_as_of指定用户询问的业务时间。
knowledge_as_of指定应当采用哪个认知时点的正式知识。
query_mode用于明确回答任务。
例如：
CURRENT_FACT表示当前有效事实。
HISTORICAL_AS_KNOWN表示过去某时点系统已知的信息。
CURRENT_BEST_KNOWN_HISTORY表示现在根据最新核实结果，对历史事实的判断。
这些字段属于本系列自定义的查询契约，不是某个向量数据库的通用API。
企业需要在检索服务中真正实现相应的时间过滤与版本选择逻辑。
四十一、为什么RAG不能只使用最新Embedding？
向量数据库中的Embedding主要用于表达文本或其他内容的语义特征。
Embedding生成时间并不等于知识生效时间。
例如一份2025年的旧手册，在2026年11月重新生成Embedding。它拥有很新的索引时间，但并不因此成为当前有效知识。
同样，一份当前有效技术文件，也可能已经被索引数月。
因此：Index Time ≠ Knowledge Valid Time。
本系列建议RAG Chunk至少保留Document ID、Entity ID、Claim Version ID、Evidence ID、Business Valid Period、Knowledge Period、Approval Status、Index Build Version。
还应执行：
检索前时间过滤。
候选结果版本复核。
答案生成前证据检查。
必要时的答案后验证。
如果旧Chunk已经失效，应将其从当前知识检索范围中撤销，或者限制到明确的历史查询模式。
对于部分向量数据库，过滤能力可能存在具体实现限制。
因此，企业需要通过真实测试确认过滤规则确实得到执行，而不是只在Metadata中保存相关字段。
四十二、Temporal RAG回答应该怎样表达不确定性？
假设用户询问：
“2026年8月1日，FW-30标准50Hz配置的额定功率是多少？”
如果系统已经完成追溯核实，可以回答：
“根据目前已批准的工程修订资料，该配置在2026年8月1日适用的额定功率为79 kW。此前系统在该日期使用过82 kW记录，相关更正于2026年10月5日登记。”
如果用户询问：
“2026年8月1日企业当时向客户提供的参数是多少？”
则应回答：
“根据当时的正式系统记录，企业使用的额定功率为82 kW。后来完成的追溯核实将该日期适用的技术参数更正为79 kW。”
这两种回答都基于同一个治理体系。
它们不同，是因为用户的时间问题不同。
如果系统无法确定用户想查询历史事实，还是历史认知，或者缺少足够Evidence，则不能强行生成一个不带时间说明的确定答案。
Temporal Grounding要求AI明确区分事实适用时间与知识获知时间。
四十三、AI Agent为什么必须具备Temporal Authorization？
相比普通RAG问答，AI Agent还可能执行操作。
例如生成报价、发送技术规格、修改产品页面、更新CRM、调用PIM API、向客户发送售后说明。
如果Agent使用了错误知识版本，结果可能直接影响真实业务。
例如客户要求当前可采购配置，Agent却根据两年前的技术规范生成报价。
或者客户询问2025年的设备售后要求，Agent却将2026年的新政策无条件适用于旧订单。
因此，Agent执行高风险业务操作前，应至少验证：
Entity Identity。
Knowledge Version。
Business Valid Time。
Context。
Evidence。
Authorization。
Consumer Contract。
对于存在重大时间冲突的任务，应进入人工复核。
本系列建议建立：Temporal Action Gate。
其基本原则是：Agent拥有读取历史知识的权限，不意味着它有权将历史知识作为当前业务承诺。
四十四、Temporal Knowledge Graph应该怎样建模？
第十一篇已经建立Entity–Relation–Claim–Evidence结构。
现在需要进一步将时间引入关系本身。
例如：
Manufacturer A
↓ manufactures
Product Model FW-30
↓ hasConfiguration
Standard 50Hz
↓ hasClaim
Rated Power = 79 kW
↓ validDuring
[2026-07-01, ...)
↓ knownSince
2026-10-05
↓ supportedBy
Specification V4.3这里需要注意：validDuring与knownSince属于本文内部语义模型的示例关系。
企业可以选择采用RDF、具备时间属性的关系数据库或其他图谱实现方式。
但必须明确：时间究竟附着在实体、关系、Claim还是Evidence上？
例如，一家公司可能长期存在，但它与某经销商之间的授权关系只在特定期间成立。
因此，不应该只给Organization Entity增加统一有效期，再把它套用到全部商业关系。
不同知识对象需要管理各自的时间生命周期。
四十五、怎样建立Temporal Quality Gate？
第七篇建立Data Quality Gate。
第十篇建立Entity Identity Gate。
第十一篇建立Graph Quality Gate。
第十二篇需要进一步建立：Temporal Quality Gate。
它应该检查：
| 规则 | 失败情形 | 处理方式 |
|---|---|---|
| Valid Time | 业务生效区间缺失或不合法 | Review / Block |
| Knowledge Time | 认知时间不可追溯 | Block |
| Temporal Overlap | 单值Claim存在不合理重叠 | Block |
| Evidence Validity | 当前证据已失效 | Quarantine |
| Supersession | 版本替换关系不明确 | Review |
| Revocation | 撤销的Claim仍被当前使用 | Block |
| Future-effective Claim | 未生效知识被提前使用 | Block |
| Historical Reconstruction | 无法恢复规定的历史状态 | Fail |
| Consumer Propagation | 下游仍引用失效版本 | Incident |
| Timezone Policy | 时间解释存在歧义 | Review / Block |
这里的Block、Review与Quarantine属于本系列建议的治理动作。
不同企业可以根据业务风险制定更严格的处理政策。
但对于Critical Claim，建议：
在无法确认适用时间或存在重大时间冲突时，不允许其自动进入当前正式知识层。
四十六、CI/CD应该怎样测试知识时间规则？
知识时间治理不能只依赖编辑人员手工检查。
它应该具备可重复执行的自动化测试。
TEST-001：历史认知恢复。
业务时间2026-08-01，知识认知时间2026-08-01，预期82 kW。
TEST-002：追溯更正。
业务时间2026-08-01，知识认知时间2026-11-09，预期79 kW。
TEST-003：更正前业务事实。
业务时间2026-06-01，知识认知时间2026-11-09，预期82 kW。
TEST-004：版本重叠。
同一实体、属性和Context，在两个时间维度均存在不合法重叠，预期拒绝写入。
TEST-005：未来生效。
新版本从2026-12-01生效，查询2026-11-09当前值，预期仍返回适用的旧版本。
TEST-006：撤销版本。
某Claim已经撤销，当前正式RAG检索不应将其作为有效技术事实。
TEST-007：历史审计。
即使Claim已经完成修订，系统仍应能够恢复规定历史时点保存的原始认知。
这些测试可以进入Pull Request验证、数据管道测试和知识发布验收。
测试通过的重点不是“数据库能够查询历史记录”，而是：
系统能否在不同业务时间和认知时间下，稳定返回正确的知识版本。
四十七、Knowledge Temporal Quality应该怎样度量？
本系列建议建立Temporal Knowledge Scorecard。
可以从以下维度入手。
Temporal Coverage：关键Claim中，具有明确业务有效时间的比例。
Bitemporal Coverage：关键Claim中，同时具有业务时间与可审计认知时间的比例。
Historical Reconstructability：抽样历史查询中，系统能够准确重建指定历史认知状态的比例。
Stale Claim Usage Rate：正式消费者使用已失效Claim的情况占比。
Temporal Conflict Count：尚未解决的关键时间冲突数量。
Correction Propagation Lag：知识更正批准后，到下游消费者完成更新验证之间的时长。
Revocation Completion Rate：被撤销的Claim在要求时限内完成必要下游失效处理的比例。
Temporal RAG Accuracy：AI在具有明确时间约束的评估任务中，正确选择知识版本的比例。
这些指标必须明确统计对象、分母、时间窗口、抽样方式、严重程度以及独立验证依据。
尤其不能把“所有数据都具有updated_at字段”，直接当作“Bitemporal Coverage达到100%”。
四十八、中小型B2B企业怎样用30天建立第一版Temporal Knowledge Governance？
不建议一开始就为企业所有数据建立复杂的Bitemporal Database。
可以从一个最容易发生知识更新冲突的领域开始，例如产品技术参数、价格政策、客户授权关系、认证有效期。
第一周，选择20—30项关键Claim，明确Entity、Context、Evidence、Valid Time和当前版本关系。
交付：Temporal Claim Inventory V1。
第二周，为关键Claim建立历史版本和System Knowledge记录，明确追溯修订、版本替代及撤销规则。
交付：Knowledge Version Registry V1。
第三周，建立Temporal Quality Gate与历史查询测试，验证旧认知与当前最佳历史认知可以分别恢复。
交付：Temporal Validation Rules V1。
第四周，连接WordPress与RAG，执行一项模拟追溯性更正。
检查Claim是否正确更新、历史版本是否保留、网页是否更新、旧Chunk是否失效、当前与历史查询是否返回正确结果。
交付：Temporal Knowledge Release Gate V1。
这个30天计划的目标不是建设复杂平台，而是让企业的一条关键知识链路具备：正确版本选择、可靠历史恢复、变更传播和错误修复能力。
四十九、SEO / GEO Knowledge Versioning的MUST、SHOULD、MAY规范
以下规范属于本系列提出的企业内部工程实施要求，并不代表W3C、Google、IETF或数据库厂商共同发布了统一的SEO/GEO Temporal Knowledge强制标准。
MUST｜必须
MUST-01：关键知识必须明确其适用的Entity与Context。
MUST-02：具有时间限制的Critical Claim必须具备可解释的Business Valid Time。
MUST-03：需要历史审计的知识必须保留可恢复的System Knowledge History。
MUST-04：不得将Document Updated Time、Knowledge Valid Time与Page Modified Time直接等同。
MUST-05：关键知识更正不得在没有适当审计记录的情况下直接覆盖历史认知。
MUST-06：追溯性更正必须明确业务生效范围与系统确认时间。
MUST-07：同一Entity、Predicate和Context的单值Claim不得存在未经批准的不合理时间重叠。
MUST-08：撤销或失效的Critical Claim不得继续无条件用于当前正式业务回答。
MUST-09：Current Claim与Historical Claim必须能够按照明确时间条件区分。
MUST-10：正式知识发布前必须完成适用的Temporal Quality Validation。
MUST-11：知识变更必须能够识别关键下游消费者及必要的修复范围。
MUST-12：Temporal RAG与AI Agent不得仅依据最近索引时间选择业务知识版本。
MUST-13：重要时间字段必须具有明确的时间格式、时区或业务日期解释规则。
MUST-14：历史事实与历史系统认知不得被混为同一种查询结果。
SHOULD｜建议
企业应建立Knowledge Version Registry。
应将Valid Time和Knowledge Time纳入关键Data Contract。
应为追溯性更正建立Correction Event。
应为知识撤销和版本替代建立独立的治理流程。
应在WordPress、PIM和RAG之间传递必要的Claim Version ID。
应建立依赖图谱，以定位受知识变更影响的下游资产。
应定期评估历史查询恢复能力。
应根据风险建立Knowledge Update SLA。
应对重大纠错保留适当的公开说明和内部审计证据。
MAY｜可选
成熟企业可以进一步采用：
Bitemporal Database。
System-versioned Temporal Tables。
Event Sourcing。
Temporal Knowledge Graph。
Historical Snapshot Registry。
Change Data Capture。
Temporal RAG。
Temporal Query Policy Engine。
Automated Claim Supersession。
Knowledge Revocation Propagation。
Temporal Quality Observability。
但这些技术应依据实际风险、数据规模、业务需求和维护能力选择。
企业不需要为了声称具备Temporal Governance，就部署全部技术组件。
五十、正式上线前的Temporal Knowledge Checklist
对于准备进入网站、报价系统、知识库或Agent的关键Claim，应至少完成以下检查：
- Entity Identity是否经过验证？
- Context是否明确？
- 是否存在Business Valid Time？
- 时间精度是否符合业务含义？
- 时区或当地生效日期是否明确？
- System Knowledge History是否可恢复？
- 当前版本是否与历史版本正确关联？
- 是否存在不合理的有效时间重叠？
- 是否存在未经裁决的历史版本冲突？
- Supersession是否正确限定适用范围？
- Revocation是否已阻止旧Claim继续用于当前用途？
- Evidence是否在指定时间和场景下适用？
- 当前WordPress页面是否使用正确的Claim Version？
- 网站发布日期与知识生效日期是否被区分？
- Sitemap lastmod是否反映真实页面更新？
- RAG是否能够按Business As-of与Knowledge As-of筛选？
- AI Agent是否具备使用相应历史知识的权限？
- 变更是否已经传播至关键消费者？
- 是否具备历史回读与纠错能力？
- 是否保留必要的审批、事件与发布记录？
这形成了本系列提出的：SEO / GEO Temporal Knowledge Admission Checklist。
五十一、完整端到端案例：从技术纠错到搜索与AI知识修复
最后，将本文的全部机制放回最初的工业设备案例。
第一阶段：原始知识正式建立
2026年3月1日，企业批准并登记标准50Hz配置额定功率82 kW。
该Claim具有Canonical Entity ID、Claim ID、Context、Evidence、Approval、Valid Time、System Knowledge Time。
随后进入PIM、WordPress与RAG。
第二阶段：业务事实发生变化
2026年7月1日，相关技术调整开始适用。
但企业知识治理系统尚未收到并确认这项变化。
因此：业务事实已经发生变化，系统认知尚未同步。
这段差异是后续审计的重要对象。
第三阶段：完成追溯核实
2026年10月5日，工程部门确认标准50Hz配置自7月1日起适用79 kW。
企业创建Correction Event。
保留旧Assertion的认知历史。
建立新的Claim Version。
将旧参数的当前最佳有效区间调整至7月1日以前。
将新参数的有效区间设为7月1日以后。
第四阶段：执行知识质量验证
系统检查Entity ID是否正确、Context是否一致、Evidence是否有效、时间区间是否重叠、Claim是否获得批准、是否存在其他冲突。
只有通过相应检查，才能进入正式知识层。
第五阶段：执行Impact Analysis
系统发现WordPress产品页面使用旧参数、某报价模板使用旧参数、RAG索引保存旧技术Chunk、某历史客户报价曾经引用82 kW。
这些资产不应该全部使用同一种修复动作。
当前产品页面需要更新。
当前报价模板需要更新。
当前RAG检索需要使用新版本。
历史报价记录则需要保留原始内容，并根据业务要求关联纠错说明。
第六阶段：发布和回读验证
WordPress页面完成实质性更新。
页面显示正确参数及必要的适用说明。
Article的dateModified反映页面实际更新。
Sitemap的lastmod反映相应的重要网页变化。
RAG重新索引或者撤销旧Chunk的当前使用资格。
第七阶段：验证历史与当前查询
系统执行三个问题。
问题一：当前该配置的额定功率是多少？
回答79 kW。
问题二：2026年8月1日，当时系统记录的参数是什么？
回答82 kW，并说明这是历史认知。
问题三：现在核实，2026年8月1日适用的参数是什么？
回答79 kW，并说明追溯更正的依据。
三种答案互不矛盾，因为它们使用不同的时间条件。
这就是Temporal Knowledge Governance在真实业务中的价值。
五十二、从“最新知识”到“适时知识”，企业真正需要改变什么？
在传统网站管理中，企业经常追求内容越新越好、数据越新越好、文件版本越高越好、知识库更新越快越好。
但对于正式业务知识，这些目标都需要限定条件。
一个三年前建立、今天仍然有效的工程事实，不一定需要改变。
一个今天刚刚上传的历史资料，也不一定适用于当前业务。
一个昨天才完成的纠错，可能需要追溯修改数月前的事实判断。
因此，企业真正应该追求的不是简单的Latest Knowledge，而是：
Temporally Appropriate Knowledge。
即在指定业务任务、对象、Context和时间条件下，选择适当且可验证的知识版本。
前十一篇已经建立来源、质量、契约、语义、身份、关系和证据。
第十二篇进一步加入：时间与版本。
整个体系可以表达为：
Trusted Source
↓
Verified Entity
↓
Approved Semantic Definition
↓
Validated Claim & Relationship
↓
Evidence & Provenance
↓
Business Valid Time
↓
System Knowledge Time
↓
Version & Correction Policy
↓
Temporal Quality Gate
↓
Governed Knowledge Release
↓
WordPress / Analytics / RAG / Agent
↓
Monitoring & Historical Reconstruction这不是要求企业按单一线性顺序完成全部处理。
实际生产中，各项治理能力应贯穿数据采集、变更、发布和使用过程。
但有一项原则必须始终成立：
企业不能只知道某条知识是什么，还必须知道它在什么时候、以什么依据、对哪些使用场景成立。
写在最后：知识可能过时，也可能后来才被证实
当企业讨论数据可靠性时，经常关注数据是否准确、来源是否权威、结构是否正确、是否拥有正式审批。
这些条件很重要，但仍然不足以回答所有业务问题。
因为事实可能发生变化，证据可能被修订，历史错误可能在数月后才被发现，系统也可能在某段时间内持续使用当时认为正确、后来却被纠正的知识。
因此：
Current Knowledge不等于Historical Knowledge。
Historical System Belief不等于Current Best-Known Historical Truth。
Latest Updated Record不等于Currently Applicable Fact。
Publication Date不等于Business Effective Date。
知识治理需要的不只是更新能力，还需要时间解释能力、历史恢复能力、版本冲突处理能力、知识撤销能力、变更传播能力以及明确的事实依据。
本篇最重要的结论是：
Knowledge Versioning确保企业能够保留知识的变化历史；Temporal Validity确保企业能够判断某项知识何时成立；Bitemporal Governance进一步使企业同时回答“当时事实应当是什么”与“当时系统知道什么”，并通过版本、证据与时间约束，让SEO、GEO和AI系统使用适合当前任务的知识。
对SEO而言，这意味着网站不能简单依靠文章更新时间替代技术知识的有效性管理。
对GEO与RAG而言，这意味着AI必须能够区分当前事实、历史事实和历史认知。
对数字营销而言，这意味着产品、客户、价格、授权及分析指标都需要具备适用的时间口径。
这些能力不会直接保证Google排名或AI引用。
但它们决定企业能否在长期变化的业务环境中，持续提供可信、可解释和可追溯的知识。
真正可靠的知识体系，不是永远只保留最新答案，而是能够在正确的时间条件下给出正确的答案。
下一篇
《SEO / GEO 数据治理与规范标准细则（十三）：Data Lineage & Change Impact——为什么知道数据来自哪里，仍然无法判断一次修改会影响哪些系统？》
第六篇已经建立Data Provenance。
第十二篇进一步建立Knowledge Versioning和Temporal Validity。
接下来，需要研究如何把来源、转换、实体、Claim、Evidence、页面、报表与AI检索资产连接为可执行的依赖关系。
重点包括Data Lineage、Column-level Lineage、Transformation Dependency、Knowledge Impact Graph、Change Data Capture、Consumer Dependency Registry、Breaking Change Impact、Lineage Observability、Incident Propagation、Automated Revalidation。
最终建立：SEO / GEO Data Lineage & Change Impact Governance Standard。
参考依据与标准边界
1. W3C — PROV-O: The PROV Ontology
提供Entity、Activity、Agent以及生成、派生、修订和失效等来源关系的标准表达能力。
2. IETF — RFC 3339: Date and Time on the Internet
提供带有UTC偏移关系的互联网时间戳表示格式，可用于跨系统时间交换。
https://www.rfc-editor.org/rfc/rfc3339.html
3. PostgreSQL — Range Types
介绍tstzrange等范围类型、区间边界、索引及范围约束的相关机制。
https://www.postgresql.org/docs/current/rangetypes.html
4. PostgreSQL — Constraints
介绍Exclusion Constraints等数据库约束能力，可用于防止不符合业务规则的时间范围重叠。
https://www.postgresql.org/docs/current/ddl-constraints.html
5. Microsoft — Temporal Tables
说明System-versioned Temporal Tables的当前表、历史表、系统时间区间及历史状态查询机制。
https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables
6. Google Search Central — Article Structured Data
说明Article结构化数据中的datePublished和dateModified等属性及其使用建议。
https://developers.google.com/search/docs/appearance/structured-data/article
7. Google Search Central — Byline Dates
解释网页发布日期和更新日期如何通过用户可见信息及结构化数据提供给Google，并说明日期选择并非依赖单一因素。
https://developers.google.com/search/docs/appearance/publication-dates
8. Google Search Central — Build and Submit a Sitemap
说明Sitemap中lastmod应反映页面重要更新日期，以及Google如何在其准确时考虑这一信息。
https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
9. W3C — RDF 1.1 Concepts and Abstract Syntax
提供知识图谱资源及关系表示的基础数据模型。
https://www.w3.org/TR/rdf11-concepts/
10. W3C — Shapes Constraint Language（SHACL）
为RDF图约束验证提供正式规范，可用于与时间质量规则协同实施知识发布检查。
本系列自定义实施规范说明
本文提出的 SEO / GEO Temporal Claim Registry、Knowledge Version Registry、Temporal Quality Gate、Temporal Query Contract、Knowledge Change Event、Temporal Knowledge Snapshot Manifest、Knowledge Update SLA、Temporal Action Gate、MUST / SHOULD / MAY规范、30天实施路径及完整工程验收流程，属于本系列结合企业数据治理、SEO、WordPress、RAG与AI Agent使用场景形成的内部工程实施模型。
其中，Valid Time、Transaction Time与Bitemporal Data属于时间数据建模中的成熟概念，但本文针对SEO/GEO设计的字段命名、版本状态、发布门禁与业务工作流，并非由W3C、Google、IETF或数据库厂商共同制定的统一标准。
本文所有工业设备型号、额定功率、版本时间、SQL查询结果及业务纠错事件均为技术说明用示例，不代表实际产品数据。
企业需要结合真实业务系统、数据库事务机制、证据审核、权限控制与下游消费者完成实施和验证，才能将这些模型转化为可运行的生产治理能力。