資料溯源與 C2PA

資料可以帶著自己的來源紀錄進入 AI 管線。今天那份紀錄是 PROV-O,不是 C2PA。

每一個已發布 checkpoint 的資料集,都能取得一份機器可讀的來源圖:誰發布、我們做了什麼、簽章的 Merkle root 是什麼、以及去哪裡驗。不需要金鑰。把它對映成 C2PA 2.2 的形狀是計畫中的下一步,今天還沒有任何端點產出 C2PA manifest。

現在就取得得到的東西

下面這一段不是說明文字,是本頁載入時實際打端點取回的內容。端點若停止回應,這一段會整段消失,而不是繼續描述一份沒有人拿得到的文件。

GET /v2/proof/provenance?dataset=twse_daily_price

provenance_version  twmd-provenance/v1
status              ok
entity_count        17
signed_by           ed25519:9b3481cf1cf7780a
snapshots           2026-08-14, latest-trade_date, 2026-08-19-trade_date, 2026-08-20-trade_date … (17 total)

這份文件自己寫明了它的界線。此處照端點原文呈現,不改寫:

  • that the figures the source published are themselves correct
  • anything about how the source produced them -- no activity is asserted for their side, because we do not observe it
  • that this graph is complete: it describes the snapshots we PUBLISHED, and a period we never checkpointed has no entity here

2026-08-23 實測:此端點免金鑰即可呼叫。沒有已發布 checkpoint 的資料集會回 200 但沒有圖——不存在的資料集鍵也是同樣的回應,API 不區分這兩者。

要變成 C2PA,還得改什麼

C2PA:尚未提供

今天沒有任何端點產出 C2PA manifest。下面每一列是一個我們已經提供的概念、它會對映到的 C2PA 概念,以及兩者之間真正卡住的東西——其中一列的對映會讓我們失去一項能力。

簽章 checkpoint(merkle_root + ed25519 簽章)

Claim signature

簽的位元組不同。我們的金鑰只簽 checkpoint merkle_root 的 ASCII hex(端點自己這樣寫);C2PA 的 claim signature 簽的是一個 claim,而 claim 參照一組 assertion。這不是換個名字就成立的對映。

公開金鑰端點(裸 ed25519 公鑰,SPKI PEM)

X.509 certificate chain / trust list

C2PA 驗證器要的是一條可以鏈到受認可 trust list 的 X.509 憑證鏈,不是一把裸公鑰。所以「第三方 C2PA 驗證器驗得過」這個驗收條件,先決條件是取得憑證,而不是寫轉換程式。這是這件事真正的成本所在。

snapshot 實體 + as_of + 來源署名

Assertions (c2pa.actions, metadata)

這一塊對映最直接:PROV-O 圖裡已經有實體、活動、代理人與時間,轉成 assertion 是結構重排。但 C2PA 對 assertion 的標籤有既定詞彙,自訂欄位要進 vendor 命名空間,對映表還沒定。

inclusion proof(單一列在快照裡的證明)

— no equivalent

C2PA 的 hard binding 綁的是一個完整資產的雜湊。逐列的 inclusion proof 在 C2PA 裡沒有對應概念,對映之後會失去這個能力。誠實的說法是:C2PA manifest 會是我們證明能力的一個子集,不是升級。

所有被問到的標準的狀態,以及各自最後一次實際呼叫的日期,列在標準與互通性

為什麼會有人問這個

EU AI Act 第 50 條的透明度義務自 2026-08-02 起適用,要求特定 AI 系統以機器可讀的方式標示其輸出。這對建 AI 系統的機構產生了一個實際需求:管線裡每一項輸入的來源要說得出來、而且要是機器讀得懂的形式。

TWMD 在這件事裡的位置要說清楚:市場資料不是 AI 生成內容,我們也不是客戶那套 AI 系統的提供者——第 50 條的義務不落在我們身上,我們也不宣稱代客戶滿足它。我們能做的是讓輸入本身帶著可驗證的來源紀錄,讓那份義務在客戶端變得可回答。

PoC 的範圍與界線

  • 範圍是一個資料集,不是全站。先證明一份符合 C2PA schema 的 manifest 產得出來、而且驗得過,再談要不要鋪開——標準還在演進,提前鋪開等於買下一份長期維護成本。
  • 在憑證到位之前,PoC 最多只能做到 schema 有效,不能做到第三方驗證器驗過簽章鏈。這兩件事不會被寫成同一句話。
  • PROV-O 那份文件不會因為 C2PA 而下架。它證得比 C2PA manifest 多(逐列 inclusion proof),而且今天就能用。

這些圖所描述的簽章 checkpoint,以及解析它們的端點,說明在可驗證資料

本頁內容不構成投資建議。