TW Market Data LogoTW Market Data

Data provenance and C2PA

Data can carry its own origin record into an AI pipeline. Today that record is PROV-O, not C2PA.

For every dataset with a published checkpoint there is a machine-readable origin graph: who published the figures, what we did to them, the signed Merkle root, and where to verify it. No key required. Mapping that onto the shape of C2PA 2.2 is the planned next step; today no endpoint emits a C2PA manifest.

What you can fetch right now

What follows is not a description — it is fetched from the endpoint when this page loads. If the endpoint stops answering, this section disappears rather than continuing to describe a document nobody can obtain.

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)

The document states its own limits, and they are reproduced here in the endpoint's own words rather than paraphrased:

  • — 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

Measured 2026-08-23: this endpoint answers without an API key. A dataset with no published checkpoint answers 200 with no graph — and so does a dataset key that does not exist, which the API does not distinguish.

What would have to change for C2PA

C2PA: not served

No endpoint emits a C2PA manifest today. Each row below is a concept we already serve, the C2PA concept it would map onto, and what actually stands between them — including one row where the mapping loses something.

Signed checkpoint (merkle_root + ed25519 signature)

→Claim signature

Different bytes are signed. Our key signs the ASCII hex of a checkpoint's merkle_root and nothing else — the endpoint's own words — while a C2PA claim signature covers a claim that references a set of assertions. This mapping is not a rename.

Public-key endpoint (raw ed25519 key, SPKI PEM)

→X.509 certificate chain / trust list

A C2PA validator expects an X.509 chain that validates to a recognised trust list, not a bare public key. So the acceptance criterion "a third-party C2PA validator verifies the chain" is gated on obtaining a certificate, not on writing a converter. That is where the real cost of this work sits.

Snapshot entity + as_of + source attribution

→Assertions (c2pa.actions, metadata)

This is the cleanest mapping: the PROV-O graph already carries entities, activities, agents and times, and turning them into assertions is a structural rearrangement. But C2PA has a defined vocabulary for assertion labels and custom fields belong in a vendor namespace; that mapping table is not written.

Inclusion proof (one row is in the snapshot)

→— no equivalent

C2PA's hard binding is a hash over a whole asset. A per-row inclusion proof has no counterpart, and would be lost in translation. The honest statement is that a C2PA manifest would be a SUBSET of what we can already prove, not an upgrade to it.

The status of every standard we are asked about, with the date each was last called, is on standards and interop.

Why anyone is asking

The transparency obligations in Article 50 of the EU AI Act apply from 2026-08-02, requiring certain AI systems to mark their output in machine-readable form. That creates a practical need for institutions building AI systems: every input in the pipeline has to have a stateable origin, in a form a machine can read.

TWMD's position needs stating precisely: market data is not AI-generated content, and we are not the provider of a customer's AI system — Article 50's obligations do not fall on us, and we do not claim to discharge them on anyone's behalf. What we can do is make the input itself carry a verifiable origin record, so that the obligation is answerable on the customer's side.

The proof of concept, and its limits

  • The scope is one dataset, not the platform. First establish that a schema-valid C2PA manifest can be produced and validated; only then discuss rolling it out. The standard is still moving, and rolling out early is buying a maintenance cost.
  • Until a certificate is in place, the proof of concept can reach schema validity but not third-party signature-chain validation. Those two will not be written as if they were one sentence.
  • The PROV-O document does not go away when C2PA arrives. It proves more than a C2PA manifest can — down to a single row — and it works today.

The signed checkpoints these graphs describe, and the endpoints that resolve them, are documented on verifiable data.

Not investment advice.