title: "時序事件資料庫、來源快照與版本鏈 v0.1" series: "網路資訊海動態秩序化" series_id: "EML-IIODO" document_id: "EML-IIODO-WP-07" document_type: "內部 MD 技術白皮書" author: "Neo.K" organization: "EveMissLab" version: "0.1.0" status: "內部時序事件、來源快照與版本治理基線" date: "2026-08-01" language: "zh-TW" visibility: "internal" license_note: "內部技術文件；本規格描述領域觀測平台的時序資料、來源快照、版本鏈與歷史回放工程基線。實際保存期限、來源內容留存、隱私與刪除政策仍須依授權、法規、robots／服務條款與部署環境調整。"

時序事件資料庫、來源快照與版本鏈 v0.1

從「現在資料庫」到「當時世界狀態可以被重建的資料庫」

摘要

本文件是《網路資訊海動態秩序化》系列第十七篇，也是第七份內部技術白皮書。前六份技術文件已依序建立 AGIRight 半自動工作流、Scheduler–Loop–Graph Runtime、任務風險與自主分級、Domain Pack、每日三則領域差分生成器，以及母站—子站共用資料、發布與訂閱架構。

至此，系統已能回答：

今天有哪些事件值得注意？

但若沒有正式的時序與版本資料模型，系統仍無法可靠回答：

2026 年 8 月 1 日下午 3 點時，我們當時知道什麼？

更無法回答：

那件事實際在什麼時候發生？來源什麼時候發布？我們什麼時候第一次觀測？之後什麼時候知道原本的判斷錯了？

因此，本規格將事件資料從單一「最新版」升格為多時間、追加式、可回放的歷史資料模型。

本篇採用三個核心時間維度：

T=(T_v,T_o,T_s)

其中：

$T_v$ ：Valid／Application Time，事件或主張在外部世界中成立、發生或適用的時間；
$T_o$ ：Observation Time，觀測系統第一次取得該證據或形成該判斷的時間；
$T_s$ ：System／Transaction Time，該版本正式進入平台紀錄系統並成為可查詢狀態的時間。

來源本身另保留：

T_p=\text{Source Publication Time}

但 $T_p$ 被視為 Evidence 的屬性，而不是取代上述三個平台時間維度。

因此，一則事件不再只有：

created_at
updated_at

而是具有：

Occurrence + Publication + Observation + SystemRecord + Revision

本規格同時建立：

Temporal Event Store；
Immutable Source Snapshot；
Evidence Version；
Event Version；
Domain Projection Version；
Publication Version；
Correction／Retraction／Supersession Chain；
Merge／Split Lineage；
Content Hash 與 Integrity Manifest；
Historical Replay；
Historical As-Known Query；
Contemporary Recompute；
Retention／Tombstone／Governed Deletion；
來源快照分層保存；
時序索引與查詢 API；
資料庫、物件儲存、搜尋索引與圖層的責任分離。

最核心的不變式是：

\boxed{ HistoricalState \neq CurrentState-OldRows }

真正的歷史必須保存「當時存在的證據、當時的版本、當時的判斷與後來的修正」，而不是只把目前資料庫中的舊列備份起來。

關鍵詞： Temporal Database、Bitemporal、Tri-temporal、Valid Time、System Time、Observation Time、Immutable Snapshot、WARC、Memento、PROV-O、Event Versioning、Correction Chain、Retraction、Merge Split Lineage、Historical Replay、Content Addressing、WORM、AGIRight

1. 文件目的

本文件回答以下工程問題：

一個事件究竟需要幾種時間？
Valid Time、Observation Time、System Time 為什麼不能混成一個 timestamp？
來源發布時間與事件發生時間不同時如何處理？
同一 URL 的網頁內容後來被修改，平台如何證明當時看到了哪一版？
來源快照是否應永久保存？保存文字、HTTP metadata 還是完整 response？
Source Snapshot、Evidence Version、Event Version、Domain Projection Version、Publication Version 如何分離？
更正、撤回、取代、補充與普通編輯差異為何？
Merge／Split 後原 Event ID 是否消失？
如何回答「當時所知」與「今日回看」兩種不同歷史問題？
歷史回放時應使用當時的 Domain Pack 還是今天的 Domain Pack？
如何避免 UPDATE 直接覆蓋舊事件狀態？
如何對來源快照做內容完整性驗證？
是否需要 blockchain 才能做不可竄改歷史？
Retention、隱私與可治理刪除如何與歷史保存共存？
如何讓下一篇 Temporal Knowledge Graph 直接引用穩定的事件版本與時間關係？

本篇相依關係為：

TH04_{HistoricalMemory} + TH07_{ReversibleClassification} + WP05_{DailyDeltaGenerator} + WP06_{SharedEventCore} \rightarrow WP07_{TemporalEventStore}

2. 非目標

WP-07 v0.1 不負責：

完整 Temporal Knowledge Graph 推理；
最終資料庫產品選型；
全球 Web Archive；
無限制永久保存所有第三方全文；
法律上保證某一來源永遠可保存；
將所有網站鏡像成公開服務；
大規模影音封存策略；
完整 GDPR／各國資料保護法合規實作；
多 Agent 爭議仲裁；
自主 AGI 長期治理。

這些由後續 WP-08 至 WP-10 或其他專案處理。

3. 第一原則：事件的「發生時間」不是資料庫的「知道時間」

假設事件在：

10{:}00

發生。

來源在：

11{:}30

發布。

平台在：

12{:}10

第一次抓到來源。

AI 在：

12{:}14

形成事件版本。

人類在：

15{:}00

修正事件判斷。

如果系統只保存：

updated_at = 15:00

就失去了幾乎全部歷史語義。

因此：

T_{occurrence} \neq T_{publication} \neq T_{observation} \neq T_{system} \neq T_{revision}

這是整個 WP-07 的起點。

4. 三時間核心模型

4.1 Valid／Application Time

Valid Time 表示一項事件、狀態或主張在外部世界中被認為適用的時間。

例如：

valid_from = 2026-08-01T10:00:00Z
valid_to   = null

若後來得知某政策其實只在 10:00 至 16:00 有效：

valid_from = 10:00
valid_to   = 16:00

形式上採：

[t_{start},t_{end})

即左閉右開區間。

這避免相鄰版本在邊界時間重疊。

4.2 Observation Time

Observation Time 表示本平台何時實際取得證據或看見事件訊號。

T_o(e)=\text{first observed by the observatory}

這一時間很重要，因為：

世界已經發生，不代表平台已經知道。

Observation Time 直接支援：

detection latency；
crawler latency；
source latency；
early signal analysis；
「平台當時是否可能知道」的歷史查詢。

4.3 System／Transaction Time

System Time 表示某一版本何時正式成為資料庫紀錄的一部分。

T_s(v)=\text{recorded by the system}

它回答：

在資料庫自身的歷史上，這個版本從什麼時候開始存在？

因此一個版本需要：

system_from
system_to

而不是只有 updated_at。

4.4 三時間不是冗餘

本系列採：

TemporalRecord=(ValidTime,ObservationTime,SystemTime)

這比純 bitemporal 多出 Observation Time。

原因是領域觀測平台本身就是感測器：

World \rightarrow Source \rightarrow Observation \rightarrow SystemRecord

「何時觀測到」本身就是重要研究資料。

5. Source Publication Time 作為 Evidence 時間

來源發布時間：

T_p(s)

保存在 Source／Evidence 層。

例如：

source_published_at: 2026-08-01T11:30:00Z
source_modified_at: 2026-08-01T14:20:00Z
observed_at: 2026-08-01T12:10:00Z

來源修改時間不得直接覆寫第一次發布時間。

如果來源沒有可信發布時間：

source_published_at: null
source_time_confidence: unknown

不能由 AI 猜測一個日期填入。

6. 時間欄位的信心與來源

所有非系統生成的時間最好帶來源與信心：

time_assertion:
  value: "2026-08-01T10:00:00Z"
  kind: occurrence
  basis: source_claim
  source_snapshot_id: SS_...
  confidence: 0.82

因此：

TimeValue \neq TimeTruth

時間本身也可以是一項需要修正的主張。

7. Event Time 可以是點、區間或未知

不是所有事件都有精確 timestamp。

v0.1 至少支援：

POINT
INTERVAL
DATE_ONLY
MONTH_ONLY
BEFORE
AFTER
APPROXIMATE
UNKNOWN

例如：

T_v(e)\in\{point,interval,partial,unknown\}

歷史系統不應把「2026 年 8 月」強行轉成「2026-08-01 00:00:00」。

8. Event Version 與 Event Identity 必須分離

Global Event ID：

GEID-01J...

表示「同一個被追蹤事件身分」。

Event Version ID：

EVID-01J...

表示「某一時刻平台對該事件的具體版本」。

因此：

GEID \rightarrow \{EVID_1,EVID_2,\dots,EVID_n\}

而不是每次修正都產生新的 Global Event。

9. Event Version 採 Append-Only

事件版本不得：

UPDATE event_version
SET summary = 'new';

來秘密覆寫歷史。

而是：

EVID-v1
  ↓ was_revised_by
EVID-v2
  ↓ was_revised_by
EVID-v3

因此：

Revision(v_i)\rightarrow v_{i+1}

舊版本仍可查詢。

Current Event View 只是：

Current(GEID)=LatestValidVersion(GEID)

它是一個 projection，而不是歷史本體。

10. 版本變更的語義類型

不能把所有版本都叫 update。

v0.1 定義：

CORRECTION
CLARIFICATION
ENRICHMENT
RETRACTION
SUPERSESSION
STATUS_CHANGE
TIME_CORRECTION
ENTITY_CORRECTION
CLASSIFICATION_ONLY
EDITORIAL_ONLY

其中：

10.1 Correction

修正原本錯誤內容。

10.2 Clarification

原內容未必錯，但新內容提高精度。

10.3 Enrichment

增加新證據或上下文。

10.4 Retraction

原事件版本或主張不應再被當作有效依據。

10.5 Supersession

新的版本／資源正式取代舊版。

10.6 Editorial Only

只修文字、排版，不改事件語意。

這一層與 Crossref 對 correction／retraction／update，以及 DataCite 的版本關係有直接工程相似性。

11. Source Snapshot 是 Evidence 的不可變觀測物

URL 不是快照。

URL\neq Snapshot

同一 URL：

https://example.org/article

今天與明天可能返回不同內容。

因此每次高價值抓取應產生：

SourceSnapshot
├── snapshot_id
├── source_id
├── requested_url
├── resolved_url
├── canonical_url
├── fetched_at
├── http_status
├── response_headers
├── mime_type
├── charset
├── content_length
├── content_hash
├── normalized_text_hash
├── storage_locator
├── archive_locator
├── rights_metadata
└── integrity_status

12. Snapshot Identity 採內容定址與觀測識別雙軌

兩個不同抓取時間取得完全相同 bytes 時：

ContentHash_1=ContentHash_2

但仍然可以有不同：

snapshot_observation_id

因此：

SnapshotObservation \neq ContentBlob

資料層可採：

SnapshotObservation
  └── content_hash → ContentBlob

相同內容只保存一次 blob，但保留多次觀測紀錄。

13. Source Snapshot 的三個保存層級

不是所有來源都需要完整 WARC。

Tier S0：Metadata Only

保存：

URL；
timestamp；
hash；
status；
title；
source metadata。

Tier S1：Normalized Evidence

增加：

extraction text；
quote anchors；
normalized HTML／JSON；
content hash。

Tier S2：Archival Snapshot

增加：

raw HTTP response；
headers；
binary payload；
WARC／equivalent archival container；
immutable object retention。

選擇函數：

SnapshotTier=f(SourcePolicy,License,Risk,Importance,Retention)

14. WARC 作為完整 Web 快照參照

WARC 適合 S2 來源快照，因為它能將多個 Web resource 與 metadata 聚合為可交換的 archival record。

但本規格不要求所有來源都必須使用 WARC。

v0.1 原則是：

ArchiveSemantics>ArchiveFormatLockIn

只要能保存：

原始 payload；
response metadata；
擷取時間；
identity；
integrity；
linkage；

即可替換底層容器。

15. Memento-style Historical Access

RFC 7089 Memento 的核心概念非常適合平台的歷史來源查詢：

Original Resource；
Memento；
TimeGate；
TimeMap。

內部可以映射：

OriginalResource → SourceIdentity
Memento          → SourceSnapshot
TimeMap          → SnapshotTimeline

因此 API 可以支援：

GET /sources/{source_id}/snapshots?at=2026-08-01T12:00:00Z

取得最接近指定時間的已知快照。

16. 不可變快照不等於永久公開副本

Immutable 表示：

既有 snapshot object 不應被靜默改寫。

不代表：

所有第三方內容必須永久公開。

因此：

ImmutableInternalRecord \neq PermanentPublicMirror

公開展示仍受：

來源授權；
著作權；
隱私；
robots／服務條款；
takedown；
retention policy；
法規。

控制。

17. Object Lock／WORM 作為高價值快照防竄改層

對重要證據可使用 WORM 類型儲存。

例如：

snapshot-v1

一旦寫入後，在 retention window 內不能覆寫。

若來源更新：

snapshot-v2

建立新版本，而非改 v1。

因此：

Correction\rightarrow NewObjectVersion

不是：

Correction\rightarrow MutateOldObject

18. Integrity Manifest

每個快照應生成：

integrity:
  sha256_raw: "..."
  sha256_normalized: "..."
  size_bytes: 123456
  fetched_at: "..."
  collector_version: "..."

如需要更高層次防竄改，可在批次建立：

MerkleRoot(batch_n)

或簽章 manifest。

但 v0.1 不要求 blockchain。

TamperEvidence \not\Rightarrow Blockchain

19. Evidence Version 與 Source Snapshot 不同

Source Snapshot 是觀測到的原始物。

Evidence Version 是平台如何從 Snapshot 中抽取證據。

例如：

Snapshot SS-001
├── EV-001 extraction model A
└── EV-002 extraction model B

因此：

SourceSnapshot \rightarrow EvidenceVersion \rightarrow EventVersion

未來換 extraction model 時，不需要重新宣稱原始來源改變。

20. Evidence Record 最小結構

evidence_version_id: EV_...
source_snapshot_id: SS_...
extractor_version: extractor-0.4.2
quote_anchor:
  start: 1042
  end: 1315
normalized_claim: "..."
evidence_type: primary_source
confidence: 0.91
system_from: "..."
system_to: null

如果原始 extraction 錯誤：

EV1 → corrected_by → EV2

而不是修改 EV1。

21. Event Version 最小結構

event_version_id: EVID_...
global_event_id: GEID_...
revision_no: 4
revision_type: clarification
status: active
valid_time:
  start: "..."
  end: null
observation_time: "..."
system_time:
  start: "..."
  end: null
source_evidence_refs:
  - EV_...
entity_refs:
  - ENT_...
claim_refs:
  - CLM_...
summary: "..."
previous_version: EVID_...
provenance_bundle: PROV_...

22. Domain Projection Version 必須獨立

同一 Event Version 可以在不同時間被某個 Domain Pack 重新分類。

EventVersion=constant

但：

ProjectionVersion_{t_1}\neq ProjectionVersion_{t_2}

例如：

DPV-1: importance = 0.42
DPV-2: importance = 0.81

原因可能只是 taxonomy 或 scoring policy 更新。

因此 Event 本體不能因子站重新評分而被改版。

23. Publication Version 也必須獨立

公開頁面改標點不應產生新 Event Version。

所以：

EventVersion \neq PublicationVersion

Publication Version 可分：

SEMANTIC
TRANSLATION
EDITORIAL
LAYOUT
SEO_METADATA

只有 SEMANTIC 變更才可能要求回溯 Event／Projection。

24. 四種版本鏈不可混用

最少需要：

V_s=\text{Source Snapshot Version}

V_e=\text{Event Version}

V_d=\text{Domain Projection Version}

V_p=\text{Publication Version}

因此：

V_s\neq V_e\neq V_d\neq V_p

這是 WP-07 最重要的不變式之一。

25. Correction Chain

更正不是覆寫，而是關係：

EVID-1
  └── corrected_by → EVID-2
                     └── clarified_by → EVID-3

每一條關係帶：

relation_type: corrected_by
reason_code: wrong_entity
created_at: "..."
actor: agent-or-human
review_ref: RV_...

26. Retraction 不等於 Delete

事件撤回時：

status = retracted

並建立：

EVID-x → retracted_by → RETRACTION-NOTICE

歷史查詢仍應知道：

當時平台曾經採信這個版本，但後來撤回。

因此：

Retracted\neq Erased

除非有法律、隱私或安全理由要求更高層級刪除。

27. Crossref／DataCite-style Version Relation

平台內部可採類似關係：

is_previous_version_of
is_new_version_of
has_version
is_version_of
updates
corrects
retracts
supersedes

其價值不是模仿 DOI 系統，而是讓版本關係可機器查詢。

28. Merge Lineage

原本：

GEID-A
GEID-B

後來發現其實是同一事件。

不能直接刪掉 B。

採：

GEID-A ─┐
        ├── merged_into → GEID-C
GEID-B ─┘

或保留一個 canonical successor：

GEID-B → alias_of → GEID-A

依事件語義選擇。

29. Split Lineage

若原本一個事件：

GEID-A

後來發現其實有兩個獨立事件：

GEID-A
  ├── split_into → GEID-B
  └── split_into → GEID-C

原 A 進入：

status = superseded_by_split

而不是從歷史消失。

30. Merge／Split 不允許循環 lineage

Lineage Graph 必須避免：

A\rightarrow B\rightarrow C\rightarrow A

除非該 relation 本身不是 successor relation。

對 merged_into／split_successor 採 DAG 約束。

31. Global Event Identity 的穩定性

原則：

IdentityStableUntilSemanticBreak

一般 clarification 不換 GEID。

真正 semantic break、merge 或 split 才改 lineage。

這避免：

每次摘要變了就變成新事件。

32. Historical Query Mode A：As Known At

問題：

在系統時間 $t_s$ ，平台當時知道什麼？

查詢：

Q_{known}(t_s)

只允許使用：

SystemFrom\le t_s<SystemTo

的版本。

這是最重要的 audit query。

33. Historical Query Mode B：As Valid At

問題：

外部世界在 $t_v$ 被認為是什麼狀態？

查詢：

Q_{valid}(t_v)

適合：

法規生效期；
模型版本存在期；
公司職位任期；
事件持續區間。

34. Historical Query Mode C：Observed Between

問題：

平台在某時間窗第一次觀測到了哪些新東西？

Q_{obs}([t_1,t_2))

這是每日差分生成器最直接的輸入之一。

35. Historical Query Mode D：Current Corrected View

問題：

用今天已知的修正看過去，那天發生了什麼？

Q_{current}(t_v\mid SystemNow)

這與 As Known At 完全不同。

因此：

HistoricalTruthView \neq HistoricalKnowledgeView

36. Historical Query Mode E：Replay

Replay 不是重新執行最新模型。

真正 replay 需要 pin：

Run Manifest
Domain Pack Revision
Model／Prompt Version
Event Version Set
Source Snapshot Set
Selection Generator Version

因此：

Replay(t) = F(State_t,Policy_t,Inputs_t)

而不是：

F(State_{now},Policy_{now},Inputs_t)

37. Contemporary Recompute 與 Replay 必須分開

Replay 問：

當時為什麼得到那個結果？

Recompute 問：

今天重新分析當時資料會得到什麼？

因此：

Replay_{historical}(t) \neq Recompute_{current}(t)

兩者都應保留。

38. Bitemporal 與本規格的關係

傳統 bitemporal 常使用：

ApplicationTime+SystemTime

本規格增加 Observation Time：

ApplicationTime+ObservationTime+SystemTime

原因是領域觀測平台需要測量：

DetectionLatency=T_o-T_v

以及：

IngestionLatency=T_s-T_o

這兩個量本身就是系統性能與歷史分析的一部分。

39. Source Latency

可額外定義：

SourceLatency=T_p-T_v

若 $T_v$ 可知。

因此總延遲可拆：

T_s-T_v = (T_p-T_v) + (T_o-T_p) + (T_s-T_o)

分別對應：

來源發布延遲；
觀測延遲；
平台處理延遲。

40. 時間精度不可偽造

如果來源只說：

2026 年夏季。

不能儲存成：

2026-06-01T00:00:00Z

並假裝精確。

應保留：

precision: season
value: 2026-summer

或：

range:
  start: 2026-06-01
  end: 2026-09-01
precision: inferred_range

並明確標記推定。

41. 時區規則

所有系統時間以 UTC 保存：

T_s\in UTC

外部事件如有地方時區，另保存：

source_local_time
source_timezone
normalized_utc_time

不能只保存轉換後 UTC，否則日後無法重建原始語境。

42. Leap／Clock／Future Timestamp 防護

Runtime 至少檢查：

遠超過現在的 source timestamp；
明顯錯誤年份；
source modified time 早於 published time；
observation time 晚於 system time 的異常；
crawler clock skew。

異常進：

TIME_QUARANTINE

而不是自動修成看似合理值。

43. Temporal Store 的邏輯表

v0.1 建議至少：

source_identity
source_snapshot
content_blob
evidence_version
global_event
event_version
event_lineage
domain_projection_version
publication_version
selection_manifest
provenance_bundle
retention_policy

44. Source Identity 與 URL 分離

一個 Source：

OpenAI Blog

可能有很多 URL。

一個 URL 也可能 redirect。

因此：

SourceIdentity \neq URL

Source Identity 保存 organization／publication identity；Source Resource 保存具體 Web resource。

45. Event Version SQL 參考結構

CREATE TABLE event_version (
    event_version_id      uuid PRIMARY KEY,
    global_event_id       uuid NOT NULL,
    revision_no           bigint NOT NULL,
    revision_type         text NOT NULL,
    valid_from             timestamptz,
    valid_to               timestamptz,
    observation_time       timestamptz NOT NULL,
    system_from            timestamptz NOT NULL,
    system_to              timestamptz,
    status                 text NOT NULL,
    payload                jsonb NOT NULL,
    previous_version_id    uuid,
    provenance_bundle_id   uuid NOT NULL
);

實際 DB 引擎可以用原生 temporal table、range、trigger 或 append-only event store 實作。

本規格定義語義，不綁定單一產品。

46. 時序區間使用半開區間

統一：

[start,end)

避免：

v1 valid_to = 12:00
v2 valid_from = 12:00

在 12:00 同時命中兩版。

47. Current Pointer 只是加速層

可以建立：

current_event_version

Materialized View 或 pointer table。

但它不能成為唯一資料來源。

CurrentPointer \subset TemporalHistory

而不是反過來。

48. Search Index 不是歷史真相層

Elasticsearch／OpenSearch／向量索引等適合搜尋，不適合成為 canonical temporal store。

索引可以重建：

SearchIndex=Rebuild(TemporalStore)

所以：

Loss(SearchIndex) \not\Rightarrow Loss(History)

49. Vector Embedding 也需要版本

同一 Evidence 經不同 embedding model：

Embedding_{v1}\neq Embedding_{v2}

因此：

embedding_model: text-embedding-x
embedding_version: 3
source_object_version: EV_...

向量不是事件本體，只是衍生索引。

50. Snapshot Normalization 也必須版本化

HTML → text 的 normalization pipeline 改變時：

normalized_text_v1
normalized_text_v2

不代表 raw snapshot 改變。

因此：

RawHash=constant

但：

NormalizedHash_{v1}\neq NormalizedHash_{v2}

是合理的。

51. PROV-O 對應

可將：

SourceSnapshot      → prov:Entity
EvidenceExtraction  → prov:Activity
EvidenceVersion     → prov:Entity
Agent／Human        → prov:Agent

並使用：

prov:wasDerivedFrom
prov:hadPrimarySource
prov:wasRevisionOf
prov:wasAttributedTo
prov:wasAssociatedWith
prov:generatedAtTime
prov:invalidatedAtTime

建立 provenance lineage。

這使版本史不只知道「前一版是誰」，還知道「誰、何時、用什麼來源與流程產生」。

52. Provenance Bundle 本身也要版本化

若後來發現 provenance metadata 有錯：

不能直接改掉原 bundle。

PROV_1\rightarrow PROV_2

並保留：

wasRevisionOf

也就是：

溯源本身也需要溯源。

53. Selection Manifest 與 Event Store 連結

WP-05 的每日三則 Selection Manifest 必須 pin：

candidate_event_version_ids
projection_version_ids
source_snapshot_ids
domain_pack_revision
generator_version
selected_set

如此才能重建：

2026-08-01 為什麼選這三則？

54. Run Manifest 與 Temporal Store 連結

WP-01／02 Run Manifest 至少保存：

run_id
started_at
completed_at
pack_revision
runtime_version
model_refs
input_snapshot_cutoff
output_version_ids

其中：

input_snapshot_cutoff

定義該次 Run 可看見的資料上界。

這可避免 replay 時偷偷使用未來證據。

55. 防止 Future Leakage

Historical Replay 最大風險之一：

重跑舊日期時，模型讀到了後來才出現的資料。

因此：

Input.system\_from\le ReplayCutoff

並要求：

ObservationTime\le ReplayCutoff

否則不是歷史 replay，而是 retrospective recompute。

56. As-Known Snapshot Cut

定義歷史截面：

K(t)=\{x\mid x.system\_from\le t<x.system\_to\}

對所有 Event／Evidence／Projection 套用同一 cutoff。

這形成：

當時資料庫看到的完整世界截面。

57. Event Sourcing 與 Temporal Table 的角色

v0.1 不要求只能二選一。

Event Sourcing 適合：

workflow／domain action log；
merge／split／retract command；
audit trail；
replay mutation sequence。

Temporal Table 適合：

point-in-time query；
current／history row view；
bitemporal state；
analytics。

可採：

CommandLog + TemporalReadModel

而不是宗教式只選一種架構。

58. Database Engine Strategy

v0.1 接受三種策略：

Strategy A：Native Temporal SQL

使用支援 system-versioned／application-time 的資料庫能力。

Strategy B：Append-only Version Table

由應用程式自己建立：

valid_from
valid_to
system_from
system_to

Strategy C：Event Log + Materialized Temporal Projection

command/event log 為寫入來源，再建 temporal read model。

不論底層哪種策略，上層 API 語義應一致。

59. Native Temporal SQL 只是參照，不是完整答案

現行 SQL Server system-versioned temporal table 可以自動保存 row history，並支援 point-in-time FOR SYSTEM_TIME 查詢。

但它主要解決 system-versioned row history。

本平台仍需自己表示：

Observation Time；
Source Publication Time；
Merge／Split；
Evidence lineage；
Domain Projection；
Retract semantics。

因此：

NativeTemporalDB \subset WP07Requirements

60. 歷史資料 Retention 不能默認無限

歷史表會持續成長。

因此每種資料有：

retention_class

例如：

R0 transient
R1 operational
R2 historical-metadata
R3 evidence-archive
R4 protected-record

保存政策依：

Retention=f(Legal,License,Risk,Value,Cost,Privacy)

而不是全部永久保存。

61. Hot／Warm／Cold／Archive 分層

建議：

Hot     → current + recent versions
Warm    → recent historical versions
Cold    → older event／projection history
Archive → raw evidence snapshots／WARC／protected record

查詢頻率與保存價值分離。

62. Raw Snapshot 與 Derived Data 保留期限可以不同

第三方原文可能只能短期保存，而衍生 metadata／hash／event relation 可依法保留更久。

因此：

Retention(SourceBytes) \neq Retention(EventMetadata)

這使歷史系統不必把「保存歷史」誤解成「永久鏡像全文」。

63. Governed Deletion

若必須刪除內容：

先區分：

PURGE_BYTES
REDACT_FIELDS
TOMBSTONE_RECORD
REMOVE_PUBLIC_ACCESS
LEGAL_HOLD

能保留 metadata 時，建議：

status: purged
purged_at: "..."
reason_code: legal_request
content_hash: "..."

而不是讓紀錄像從未存在過。

64. Tombstone

Tombstone 保存：

原 ID；
曾存在的事實；
刪除／失效時間；
原因類型；
successor／replacement。

不保存已被要求刪除的敏感 payload。

因此：

Tombstone\neq CopyOfDeletedData

65. Legal Hold

若資料進入法律或審計保留：

retention_state = LEGAL_HOLD

一般清理 Job 不得移除。

Policy Engine 必須把 legal hold 放在 retention 優先級之上。

66. Snapshot Fetch Policy

不是每個 URL 每次都完整保存。

抓取政策可依：

ETag；
Last-Modified；
content hash；
event importance；
source change frequency；
evidence maturity；
retention class。

決定是否產生新 snapshot。

67. Snapshot Deduplication

若：

RawHash_{new}=RawHash_{old}

只新增 Observation record，不新增 ContentBlob。

可以大幅降低保存成本。

68. Source Mutation Detection

同一 URL 發現：

RawHash_{t_1}\neq RawHash_{t_2}

觸發：

SOURCE_MUTATED

再判斷：

EDITORIAL_CHANGE
MATERIAL_CHANGE
UNKNOWN_CHANGE

Material Change 可觸發 Event reevaluation。

69. Diff Artifact

可保存：

SnapshotDiff
├── old_snapshot_id
├── new_snapshot_id
├── text_diff
├── semantic_diff
├── changed_sections
└── materiality

Diff 本身是衍生物，可重算，不必成為 canonical evidence。

70. Correction Trigger

來源修改不等於事件一定要改。

SourceChange \not\Rightarrow EventRevision

只有：

MaterialEvidenceChange \rightarrow Reevaluation

再由 Domain／Event policy 決定是否產生新 Event Version。

71. Evidence Maturity 與時間聯動

事件剛出現時：

E0 signal

後來：

E1 single-source
E2 multi-source
E3 primary-confirmed
E4 corrected/stable

Evidence Maturity 的變化本身產生版本，但不必改 Global Event ID。

72. Stabilization Window

對高變動 breaking event，可以設定：

W_s

例如 30 分鐘／6 小時／24 小時。

在 $W_s$ 中允許快速 revision，但每版仍留下 lineage。

不允許「因為變化太快，所以直接覆寫」。

73. Version Explosion 控制

頻繁微小修正可能造成版本爆炸。

因此可對 EDITORIAL_ONLY 採 batching：

MinorEdits_{window}\rightarrow OnePublicationRevision

但 Event semantic version 不可用 batching 隱藏重要修正。

74. Semantic Version 與 File SemVer 不同

Event revision_no=7 不代表 SemVer。

Domain Pack／Runtime 仍可使用：

0.1.0

Event Version 更適合單調 revision sequence 或 immutable ID。

不要混用：

SoftwareSemVer\neq EventRevision

75. Event Status State Machine

建議：

PROVISIONAL
   ↓
ACTIVE
   ↓
CONFIRMED
   ↓
SUPERSEDED

旁路：

ACTIVE → RETRACTED
ACTIVE → DISPUTED
PROVISIONAL → REJECTED

Status change 本身形成新版本或獨立 transition event。

76. Disputed 狀態

不能只有 TRUE／FALSE／RETRACTED。

DISPUTED 表示：

有實質衝突證據，平台尚未收斂。

此狀態可保存多個 Claim Version，由下一篇 Temporal Knowledge Graph 表示其支持／反對關係。

77. Claim Version

對爭議性事件，可把 Event 與 Claim 分離：

GlobalEvent
├── Claim-A v1/v2
├── Claim-B v1
└── Evidence Set

這樣來源 A 修正自己的說法，不必讓整個事件 identity 失效。

78. Entity Resolution Version

人物、公司、論文、模型身分也會被重新解析。

因此：

EntityResolutionVersion

必須可追溯。

若錯把兩個同名人物合併：

EntityMergeError \rightarrow ResolutionRevision

並重新計算受影響事件投影。

79. Cascading Recompute

一個 Entity 修正可能影響：

Evidence
→ Event
→ Domain Projection
→ Daily Selection
→ Publication

但不能同步全部阻塞。

使用：

RECOMPUTE_REQUIRED

事件排入 background queue。

80. Recompute Lineage

重新計算產生新衍生版本：

recomputed_from: DPV_old
reason: entity_resolution_revision
input_cutoff: "..."
policy_revision: "..."

因此可區分：

原事件改了。

與：

我們的分類模型改了。

81. Historical Replay API

建議：

GET /history/state?system_at=...
GET /events/{geid}/versions
GET /events/{geid}?valid_at=...
GET /events/{geid}?known_at=...
GET /sources/{source_id}/snapshots
GET /sources/{source_id}/snapshots?at=...
GET /projections/{dpid}/versions
GET /publications/{pubid}/versions

82. Dual-Time Query API

對 bitemporal 查詢可支援：

GET /events
  ?valid_at=2026-07-01T00:00:00Z
  &known_at=2026-08-01T00:00:00Z

語義是：

以 8 月 1 日當時已知的資料，7 月 1 日被認為發生了什麼？

這是一般「查舊新聞」做不到的查詢。

83. Observation Query API

GET /events
  ?observed_from=...
  &observed_to=...

回答：

系統那一天新看到什麼？

這是 DDDG 的核心 feed。

84. Historical Cut Export

可匯出：

historical-cut-2026-08-01T00:00Z.jsonl

內容只包含當時可見版本。

用途：

replay；
benchmark；
regression test；
historical research；
AI training／evaluation（須遵守資料權利）。

85. Historical Cut 必須帶 Manifest

cutoff_system_time: "..."
cutoff_observation_time: "..."
pack_revisions:
  - "..."
record_count: 12345
merkle_root: "..."
exporter_version: "..."
created_at: "..."

避免後來不知道這份歷史資料集的生成條件。

86. Query Consistency

跨多表歷史查詢需要一致性快照。

不能：

Event 查到 12:00 狀態；
Evidence 查到 12:05 狀態；
Projection 查到 12:10 狀態。

同一 Historical Cut 必須共享：

SystemCutoff=t

87. Transaction Boundary

一組關聯版本更新應有共同 transaction／change set：

ChangeSet
├── EventVersion
├── ProjectionVersion
├── ProvenanceBundle
└── AuditRecord

若其中一項失敗，不能留下半套歷史。

88. Change Set ID

每次語義更新帶：

change_set_id

讓 audit 可以問：

哪些資料是同一次修正造成的？

89. Single Writer 不代表 Single Agent

同一 Event Aggregate 在同一時間只允許一個 commit owner：

ConcurrentWriters(GEID)\le1

但多 Agent 可以並行提出 Proposal。

最後由 commit layer 序列化版本。

90. Optimistic Concurrency

更新時帶：

expected_revision_no

若資料庫目前 revision 已不同：

VERSION_CONFLICT

要求重新讀取與 rebase，而不是最後寫入者直接覆蓋。

91. Version Conflict 與 Merge

兩個 Agent 同時產生：

proposal-A
proposal-B

系統可以：

選一個；
合併；
建立 disputed；
升級人工。

但真正 Event Version commit 仍形成線性 revision chain，語意分歧另存 Proposal／Claim Branch。

92. Branching History

某些知識爭議不應強制線性化。

因此：

ClaimBranch-A
ClaimBranch-B

可以共存。

但 Global Event revision 的行政歷史仍保持可追蹤。

因此：

AdministrativeHistory=lineage

EpistemicHistory=possibly\ branching

93. Temporal Invariants

v0.1 強制：

I1

SystemFrom<SystemTo

除 current open interval。

I2

同一 entity／version class 的 system intervals 不重疊。

I3

Observation Time 不得晚於產生該 observation record 的 System Time，超出 clock tolerance 則 quarantine。

I4

任何 current semantic state 必須可追溯至少一個 Evidence Version 或明確標記 inferred_without_primary_evidence。

I5

任何 Retraction 不得刪除 lineage。

I6

任何 Merge／Split 必須保留 predecessor。

I7

任何 Historical Replay 不得讀取 cutoff 之後的 System／Observation Version。

I8

Source Bytes、Event Version、Projection Version、Publication Version 不共用版本號語意。

94. Consistency Checker

背景 Job 定期檢查：

temporal overlap；
dangling previous_version；
merge／split cycle；
missing snapshot；
hash mismatch；
retracted current pointer；
projection pinned to missing event version；
publication pinned to retired projection；
invalid cutoff；
retention violation。

輸出：

TEMPORAL_INTEGRITY_REPORT

95. Historical Drift Metrics

可以量測：

95.1 Correction Rate

CR= \frac{CorrectedEventVersions}{AllCommittedEventVersions}

95.2 Retraction Rate

RR= \frac{RetractedEvents}{PublishedEvents}

95.3 Detection Latency

DL=T_o-T_v

95.4 Processing Latency

PL=T_s-T_o

95.5 Source Mutation Rate

SMR= \frac{ChangedSnapshots}{ObservedSnapshots}

95.6 Replay Reproducibility

RepR= \frac{SuccessfulHistoricalReplays}{ReplayAttempts}

96. 歷史資料的 AI 品質研究價值

有了 Temporal Store，就可以問：

哪些來源最常事後修改？
哪種 Agent 最常把 provisional signal 誤判成 confirmed event？
哪些領域 detection latency 最長？
哪些 taxonomy 變更造成最多歷史重分類？
哪些「每日三則」後來被證明低估？
哪些 early signal 最終演化成 macro event？

因此歷史資料不只是 archive，也是未來 AI 自我校正的訓練與評估資料。

97. 不允許用未來答案回寫過去評分

若今天知道某事件後來非常重大：

不能偷偷修改當天的 historical importance score。

應保留：

historical_score = 0.42
current_retrospective_score = 0.95

因此：

HistoricalEvaluation \neq RetrospectiveEvaluation

98. Retrospective Annotation

後見之明可以另外保存：

RetrospectiveAnnotation
├── target_event_version
├── created_at
├── perspective_time
├── assessment
└── evidence_refs

這讓系統能研究：

哪些訊號當時看起來小，後來變大？

而不污染原始歷史狀態。

99. 資料儲存拓撲建議

v0.1 建議責任分離：

Relational Temporal Store
  ├── identity
  ├── version metadata
  ├── temporal interval
  ├── lineage
  └── policy state

Object Store
  ├── raw snapshot
  ├── WARC
  ├── binary attachment
  └── large export

Search / Vector Index
  ├── current search
  └── derived semantic index

Event Bus
  └── mutation / recompute / archive jobs

其中 canonical history 以 Temporal Store + immutable object 為主。

100. AGIRight v0.1 遷移路徑

M0：現況

保存目前文章與來源連結。

M1：Source Observation

新增：

source_id
snapshot_id
observed_at
content_hash

M2：Event Version

每個 Topic／Event 引入：

global_event_id
event_version_id
system_from
system_to

M3：Projection Version

AGIRight taxonomy／importance 改為 versioned projection。

M4：Selection Pinning

每日三則保存完整 Selection Manifest。

M5：Snapshot Tiering

重要來源進 S1／S2 snapshot。

M6：Historical Query

支援：

known_at
valid_at
observed_between

M7：Replay

能重跑某日每日三則，不讀取未來證據。

101. MVP 最小資料模型

若不一開始做完整架構，最小版只需要六張邏輯表：

source_snapshot
evidence_version
global_event
event_version
domain_projection_version
version_relation

加一個 object store。

就已能成立：

Evidence + TemporalEvent + ProjectionHistory

102. MVP 最小 API

POST /snapshots
POST /events
POST /events/{id}/revisions
POST /events/{id}/retract
POST /events/merge
POST /events/split
GET  /events/{id}/versions
GET  /events?known_at=
GET  /events?valid_at=
GET  /events?observed_from=&observed_to=

足以支援 WP-08 的 Temporal Knowledge Graph。

103. 驗收測試

T01｜URL Mutation

同 URL 內容改變後產生新 Snapshot，不覆寫舊 bytes。

T02｜Event Correction

事件修正後舊 Event Version 仍可查。

T03｜As-Known Query

查詢舊 system time 不得看到後來加入的 correction。

T04｜Current Corrected Query

查詢同一 valid time，但使用 current knowledge，可看到 correction。

T05｜Future Leakage

Historical Replay 嘗試讀取 cutoff 後來源必須失敗。

T06｜Merge

兩事件合併後 predecessor 仍可解析到 successor。

T07｜Split

事件 split 後舊 GEID 不得靜默消失。

T08｜Retraction

Retracted event 不出現在 current active view，但可出現在 historical view。

T09｜Hash Integrity

Snapshot bytes 被修改後 integrity checker 必須報錯。

T10｜Projection Recompute

只更新 Domain Projection 時不得產生新的 Event semantic version。

T11｜Publication Edit

只修改翻譯／SEO 時不得污染 Event／Projection version。

T12｜Retention

到期 raw bytes 可依 policy 清除，但允許的 tombstone／metadata 正確保留。

104. Threat Model

WP-07 主要威脅包括：

歷史覆寫；
Future leakage；
Timestamp fabrication；
Source mutation 未被偵測；
Snapshot bytes 被竄改；
Retraction 被當 delete 隱藏；
Merge／Split lineage 斷裂；
Projection change 被誤記成 Event change；
Publication edit 污染事實版本；
Retention job 過度刪除；
Archive 無視來源授權；
replay 使用錯誤的 Pack／Model revision。

105. 核心安全原則

105.1 Append, Don’t Overwrite

語義歷史預設追加，不覆寫。

105.2 Pin Inputs

Run、Replay、Selection 都 pin version。

105.3 Immutable Evidence Where Permitted

高價值 Evidence 快照在合法範圍內不可變。

105.4 Separate Time Dimensions

不能把 occurrence、observation、system time 壓成一個 timestamp。

105.5 Preserve Lineage

更正、撤回、合併、拆分都保留 predecessor。

105.6 Govern Deletion

刪除是 policy action，不是隨手 DELETE FROM。

106. 與現有工程體系的關係

本規格不是重新發明 temporal database。

SQL Server 現行 system-versioned temporal tables 會自動保存舊 row version，並支援 point-in-time FOR SYSTEM_TIME 查詢，證明「current table + history table + system time query」已是成熟資料庫模式。另一方面，傳統 bitemporal 模型將 application／valid time 與 system／transaction time分開，正好支援「外部世界何時成立」和「資料庫何時知道」的差異。

本規格在此之上增加 Observation Time，因為資訊觀測站需要研究「何時看見」這個感測行為本身。

RFC 7089 Memento 則為 Web resource 的過去狀態提供 Original Resource、Memento、TimeGate、TimeMap 等明確概念，適合作為 Source Snapshot Timeline 的 Web 原生參照。

WARC 是網路封存領域成熟的 aggregate format，可將 harvested Web resource 與 metadata 一併保存；本規格將其視為 S2 Archival Snapshot 的可選格式，而非強制底層。

PROV-O 提供 wasDerivedFrom、hadPrimarySource、wasRevisionOf、generatedAtTime、invalidatedAtTime 等關係，可用於 Source Snapshot → Evidence → Event Version 的 provenance graph。

Crossref 對 corrections、retractions 與 significant update 的版本治理，以及 DataCite 的 IsNewVersionOf／IsPreviousVersionOf／HasVersion／IsVersionOf，提供了「重大修正不應秘密覆蓋原記錄，而應建立顯式關係」的成熟學術基礎設施案例。

S3 Object Lock 類 WORM 能力則證明 object version 可以在 retention window 內防止覆寫／刪除；本規格只將其視為高價值快照的完整性工具，不把特定雲端產品當成必要依賴。

本文件的新意不在任何單一 temporal table 或 archive format，而在於把：

ValidTime + ObservationTime + SystemTime + ImmutableEvidence + EventVersion + ProjectionVersion + PublicationVersion + CorrectionLineage + HistoricalReplay

整合為領域資訊觀測平台的一致資料契約。

107. 參考資料與工程查核

本文件於 2026-08-01 重新查核以下資料：

Microsoft Learn, Temporal Tables - SQL Server：system-versioned temporal tables、current／history table、row validity period 與 FOR SYSTEM_TIME point-in-time query。
- https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables
Microsoft Learn, Manage historical data in system-versioned temporal tables：history retention、長期歷史資料成長與 retention policy。
- https://learn.microsoft.com/en-us/sql/relational-databases/tables/manage-retention-of-historical-data-in-system-versioned-temporal-tables
PostgreSQL Documentation 19, Temporal Tables：application time、system time 與 bitemporal 定義參照。
- https://www.postgresql.org/docs/19/ddl-temporal-tables.html
RFC 7089, HTTP Framework for Time-Based Access to Resource States — Memento：Original Resource、Memento、TimeGate、TimeMap、datetime negotiation。
- https://www.rfc-editor.org/rfc/rfc7089.html
Library of Congress, WARC, Web ARChive file format：WARC 之 Web archive aggregate、record metadata、ISO 28500 與封存用途。
- https://www.loc.gov/preservation/digital/formats/fdd/fdd000236.shtml
W3C, PROV-O: The PROV Ontology：Entity／Activity／Agent、wasDerivedFrom、hadPrimarySource、wasRevisionOf、generation／invalidation provenance。
- https://www.w3.org/TR/prov-o/
Crossref, Version control, corrections, and retractions：重大更新、更正、撤回、版本可辨識與原記錄保留。
- https://www.production.crossref.org/documentation/principles-practices/best-practices/versioning/
DataCite, Versioning：IsPreviousVersionOf、IsNewVersionOf、HasVersion、IsVersionOf。
- https://support.datacite.org/docs/versioning
AWS, S3 Object Lock：WORM、retention period、legal hold、object version protection。
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html

108. 下一階段

WP-07 完成後，系統已具有：

SharedEventIdentity + TemporalVersion + ImmutableEvidence + CorrectionLineage + HistoricalReplay

下一個問題是：

Event 之間的「誰導致誰、誰支持誰、誰反駁誰、誰取代誰、哪個微觀事件最後聚合成哪個宏觀趨勢」如何被跨站、跨時間表示？

因此下一篇 EML-IIODO-WP-08 將處理：

《Temporal Knowledge Graph 與跨站事件關聯 v0.1》

正式建立：

TemporalNode + VersionedEdge + EvidenceEdge + CrossDomainRelation + EventChain + CausalCandidate + GraphReplay

並把 WP-07 的穩定 Event Version 與時間截面轉成真正可查詢的時序知識圖。

109. 結論

只保存「現在最新內容」的資訊平台，本質上沒有真正的歷史記憶。

它最多只有：

CurrentDatabase + OldBackups

而本系列需要的是：

\boxed{ WhatHappened + WhenItWasPublished + WhenWeObservedIt + WhenWeRecordedIt + WhatWeBelievedThen + HowWeCorrectedItLater }

這意味著「時間」不再只是文章排序欄位，而是資料模型的第一級結構。

同樣地，「版本」也不再只是 v1、v2，而必須回答：

到底是來源變了、事件理解變了、領域投影變了，還是公開頁面只是換了措辭？

因此 WP-07 最終固定四條獨立版本鏈：

\boxed{ SourceSnapshotVersion \neq EventVersion \neq DomainProjectionVersion \neq PublicationVersion }

並在其下加入：

ValidTime + ObservationTime + SystemTime

與：

Correction + Retraction + Merge + Split + Replay

當這一層成立後，平台第一次真正具備回答：

「在某個歷史時間點，世界發生了什麼，而我們當時又知道了什麼？」

的工程能力。

也只有到了這一步，前面所說的「網路資訊海動態與歷史收集平台」才不再只是大量新聞頁面的堆積，而開始成為真正可查詢、可修正、可重放的領域歷史記憶基礎設施。

17_時序事件資料庫來源快照與版本鏈_v0.1.0