Disclosure: AI tools were used for source collection and editorial review. The article was written by a human author, who checked the facts, code, and conclusions.

AI x Crypto Systems disclosure: this article is a technical explanation, not investment advice. AI x Crypto Systems does not recommend buying, selling, or holding any cryptoasset.

Training Data Provenance

Training Data Provenance can look healthy while the dataset story is wrong. In the postmortem below, a model card points to sha256:9f22..., the training file has not changed, and the team still cannot answer why an opt-out record reached training. The incident is not a cryptography problem. The incident is a missing manifest diff.

incident: support-classifier-v7
symptom: opt-out record appears in training explanation sample
dataset_hash: sha256:9f22...
hash_status: correct
missing: source policy, exclusion report, reviewer status
impact: model build cannot prove why the record was included

Symptom

Training Data Provenance starts with a symptom, not a standard. The symptom in this case is a user asking why a support message they opted out of appears in a model-review sample. The team checks the model card, finds the dataset hash, recomputes the digest, and confirms the final archive matches the recorded value. Training Data Provenance has byte identity, yet the review still cannot explain the record.

The symptom matters because it separates two questions that teams often merge. A hash answers "which bytes did we train on?" but the incident asks "why were these bytes allowed to exist in the training set?" Croissant 1.1 allows file objects to carry sha256 checksums, which is useful for byte identity. Training Data Provenance needs that anchor, but the anchor does not supply collection rights, exclusion history, or reviewer intent.

That is the bug.

Triage Note

Training Data Provenance triage should write down what is known before it starts inventing explanations. Known: the final file hash is stable. Unknown: whether the source export included an opt-out list, whether the redaction transform ran after the opt-out merge, whether the reviewer accepted a limitation, and whether the model card copied the right manifest. Training Data Provenance fails when those unknowns are hidden behind a confident digest.

The first triage note should therefore read like this:

Manifest Before

Training Data Provenance becomes concrete when the broken manifest is shown. The bad manifest below looks respectable because it has a dataset name, a final digest, and a transform list. It is still not enough. The fields that would explain source policy, exclusion evidence, and reviewer status are either absent or vague.

dataset: support-classifier-training
created_at: 2026-05-22T18:10:00Z
source: support-chat-export
rights_basis: internal
transforms:
  - normalize
  - dedupe-v1
sha256: 9f2277aa...
model_build: support-classifier-v7

Training Data Provenance does not reject this manifest because YAML is bad; Training Data Provenance rejects this manifest because the manifest cannot answer the incident. "Internal" is not a rights basis. support-chat-export is not a source record. dedupe-v1 does not say whether opt-outs were removed. The digest says the file is stable, not that the process was reviewable.

Diff Evidence

Training Data Provenance improves when the repair is a diff, not an essay. The diff below is the smallest artifact that changes the review. It does not merely add more metadata; it adds the missing causal links: source version, opt-out list, rights policy, redaction transform, exclusion report, reviewer status, and unresolved risks.

 dataset: support-classifier-training
 created_at: 2026-05-22T18:10:00Z
-source: support-chat-export
-rights_basis: internal
-transforms: [normalize, dedupe-v1]
-sha256: 9f2277aa...
+source_records:
+  - support-chat-export@2026-05-22
+  - opt-out-list@2026-05-22
+rights_basis: internal-use-policy-2026-04 + customer-exclusion-log
+transforms:
+  - normalize-v1
+  - pii-redaction-v3
+  - opt-out-removal-v2
+  - dedupe-v2
+exclusion_report: removed-records-8841.json
+reviewer_status: accepted_with_limits
+unresolved_risks:
+  - non-English coverage gap
+  - legacy tickets before consent-policy migration
+sha256: 4d81c0ee...
 model_build: support-classifier-v7

Provenance Model

Training Data Provenance needs a model for the words "source", "transform", and "reviewer." W3C PROV describes provenance through entities, activities, and agents, which is a good mental model for this incident. The support export and opt-out list are entities. Redaction and opt-out removal are activities. The pipeline and reviewer are agents. Training Data Provenance gets better when the manifest names those roles instead of compressing them into one source string.

That model does not need a giant platform on day one. A small manifest can point to source files, transform logs, exclusion reports, reviewer decisions, and model builds. The important property is traceability: a reviewer should be able to walk from a model artifact to a dataset digest to a manifest diff to a source record. Training Data Provenance is useful when the walk is possible without asking someone to remember a pipeline meeting.

Rights Layer

Training Data Provenance needs a rights layer because a digest can preserve disallowed data perfectly. MLCommons says Croissant 1.1 adds machine-actionable provenance, vocabulary interoperability, and governance metadata. That direction is important because AI dataset metadata is not only about loading files. The metadata has to carry usage restrictions, consent signals, and policy context where automation can inspect them.

The rights layer should not overpromise. A manifest field saying rights_basis: internal-use-policy-2026-04 does not prove that every source claim is true. It proves the build had a declared rights basis that reviewers can challenge. Training Data Provenance proves a recorded data story, not the moral or legal truth of every line in that story. That humility keeps crypto commitments from becoming compliance theater.

Transform Layer

Training Data Provenance usually fails in the transform layer. An opt-out list may exist, but the transform may run before the list is joined. A redaction step may exist, but only for English. Deduplication may exist, but may preserve a record through a near-duplicate. Datasheets for Datasets is still relevant because it asks creators to document motivation, composition, collection, preprocessing, uses, distribution, and maintenance. Training Data Provenance turns those questions into build artifacts.

The transform layer needs exact names. clean-data is not enough; pii-redaction-v3 and opt-out-removal-v2 are reviewable. dedupe is not enough; dedupe-v2 threshold=0.84 is reviewable. A Training Data Provenance manifest should make it possible to reproduce the question, "Did the exclusion step run after the opt-out list was loaded?"

Build Link

Training Data Provenance closes the incident only when the model build links back to the repaired manifest. The build record should contain code version, dataset manifest hash, training configuration, evaluation set, model artifact hash, and reviewer status. Without that link, the repaired manifest is just a document near the model, not part of the model's evidence chain.

The Data Provenance Initiative paper shows why this boring link matters: popular AI datasets can have missing, inconsistent, or unclear licensing and attribution metadata. Training Data Provenance should assume metadata is imperfect and preserve uncertainty explicitly. A field called unresolved_risks is not a weakness; it is the part of the receipt that tells the next reviewer where not to overclaim.

Reviewer Status

Training Data Provenance needs reviewer status because automation cannot own every judgment. The reviewer should be able to mark a source as accepted, rejected, quarantined, or accepted with limits. The difference matters. Accepted means the source is fit for the declared use. Accepted with limits means the model owner must carry a caveat into the model card. Quarantined means the data should not enter training until a condition is resolved.

The reviewer status is also the first line a future incident responder should read. If the disputed record came from a source marked accepted with limits, the responder knows the risk was known. If the source was never reviewed, the responder knows the process failed. Training Data Provenance should make missing review state visible, not hide it behind a final archive digest.

Quarantine Step

Training Data Provenance should include a quarantine step when the manifest cannot answer a user-facing incident. Quarantine does not mean the entire model must be deleted immediately; it means the disputed source cannot be used for new training until the missing source, rights, transform, and reviewer fields are resolved. That step changes the operational posture from "we have a hash" to "we know which evidence is missing."

The quarantine record can be small, but it must be separate from the repaired manifest:

quarantine:
  source_record: support-chat-export@2026-05-22
  trigger: opt-out record found in model-review sample
  blocked_use: new training and benchmark publication
  allowed_use: incident reproduction in restricted environment
  exit_condition: opt-out-removal evidence and reviewer status attached

Training Data Provenance uses quarantine to prove restraint, not truth. The record proves the team stopped treating an underexplained dataset as clean. It does not prove the disputed record was maliciously included, and it does not prove the repaired pipeline is perfect. The value is narrower and more useful: the next model build cannot quietly reuse the same weak manifest.

The short quarantine step changes the incentives inside the team. Without quarantine, the easiest path is to keep training and promise to document the dataset later, which is how provenance debt becomes permanent. With quarantine, the missing manifest fields become release blockers instead of housekeeping tasks. Training Data Provenance is partly a technical artifact and partly a forcing function: the model owner must either attach the evidence or admit that the dataset cannot support the next build.

Model Card Patch

Training Data Provenance should patch the model card after the manifest is fixed. A model card that only lists dataset_hash=sha256:9f22... invites the same failure later. The patched model card should include the manifest hash, source set, transform set, reviewer status, unresolved risks, and the quarantine history if any. The model card does not need to dump the full manifest into the article; it needs to point to the evidence that explains the hash.

A useful model-card line is specific: training_manifest=sha256:4d81c0ee; reviewer_status=accepted_with_limits; unresolved_risks=legacy tickets before consent-policy migration. That line is not pretty, but it is searchable and reviewable. Training Data Provenance improves when the model artifact carries enough pointers for a future incident responder to reconstruct the data story without Slack archaeology.

Postmortem Close

Training Data Provenance closes this incident with a sentence that is more useful than "we had a hash." The better sentence is: model support-classifier-v7 trained on manifest 4d81c0ee, built from source export and opt-out list dated 2026-05-22, after pii-redaction-v3, opt-out-removal-v2, and dedupe-v2, with reviewer status accepted_with_limits and two unresolved risks. That sentence is long because the real data story is long.

The final lesson is narrow. Training Data Provenance should keep the hash, but the hash is the last line of the receipt, not the receipt itself. A digest catches byte drift. A manifest diff catches process drift. The model owner needs both before the next user asks why their record was in the training set.