Data lineage for evaluation sets: provenance of test data

What data lineage means, and why a set without it proves nothing

Data lineage is the recorded path of each data item from its origin, through every transformation, to the place it is used. In testing it describes the evaluation sets from which verdicts are drawn. A set of 2,000 documents labelled human-written or AI-generated is a benchmark only if someone can say, for each one, where it came from, how it was labelled and what was done to it before scoring. That account is the lineage; its evidential form, who held the item and when, is the chain of custody. The guide to designing an evaluation test set asks for it before size.

Three failures follow, and each turns a measurement into an opinion. A claim that a detector flagged 4 of 1,000 human-written essays rests on the essays being human-written and unaltered; without a source and a labelling method the denominator is unknown, and a rate with an unknown denominator has no meaning. A detector trained on public text may have seen the documents in the set; with no source and no date, leakage cannot be checked. And when a second team gets a different number later, only matching hashes settle the dispute.

What to record for each item

The author category is the field most often filled by assumption. "Human-written" by signed attestation with draft history is a different fact from "human-written" because the item pre-dates public generators, or was found on a website in 2019. Record the method as a controlled value (attested, dated pre-generator, rater-labelled, generated under a logged prompt), never as free text, and record the generator, prompt and settings for the AI-generated side.

Lineage at set level, and where to keep it

Some facts belong to the set. The set version changes whenever any item is added, removed or altered, with a changelog saying why. The split records which items are held out for evaluation and which were used for calibration, since an item used to choose a threshold cannot fairly measure it. The labelling record names who labelled, under what instructions, and how well they agreed, covered in the guide to measuring agreement between labellers. The sampling frame is partitioning inputs into equivalence classes applied to documents: essays and news articles are two partitions, and a pooled result hides their difference.

Three artefacts cover most needs. A manifest file is a table, one row per item, holding every field above with the SHA-256 of the content; it lives in version control beside the set, and its own hash is what a report cites. A dataset card is the human-readable companion in the datasheets for datasets pattern: motivation, composition, collection, preprocessing and uses. Where lineage must cross organisations, the W3C PROV data model gives a standard vocabulary of entities, activities and agents in RDF, XML or a plain notation; one benchmark rarely needs it.

Leakage checks: has the model seen this item?

Leakage is the presence of evaluation items, or near copies, in the data a model was trained on. It inflates every score and is invisible without lineage. The exact check compares the hash of each item, and of chunks within it, against any reachable training corpus index; the near-duplicate check runs a similarity search over shingled n-grams or an embedding and flags matches. An item collected after the model's documented training cut-off cannot have leaked in the ordinary way, though retraining moves the cut-off. The guide to running a detector benchmark properly treats leakage as a threat to validity alongside label error.

Data lineage for an evaluation set: the protocol

1. 1

   Define the manifest schema

   Fix the per-item and set-level fields before collecting anything, with controlled values for author category and method. A field added later is empty for earlier items.

2. 2

   Record origin at collection time

   Capture source, licence, date and author category as each item enters the set, by whoever collects it. Later reconstruction is guesswork and is marked as such.

3. 3

   Log every transformation

   Each cleaning, truncation or de-identification step appends a line with the tool, version and date. Keep the originals.

4. 4

   Hash and freeze

   Compute a SHA-256 for every item in its final form, write the hashes into the manifest, hash the manifest and tag the set with a version.

5. 5

   Run the leakage checks

   Match hashes and near-duplicates against available training indexes, record the result per item with the index version, and remove or flag matches.

6. 6

   Cite the version in every result

   Every rate reported from the set names the set version, manifest hash and run date, so a reader can obtain the same bytes and repeat the run.

Worked example: 2,000 items by source category

A team assembled 2,000 documents for a detector benchmark and audited the lineage before the first run, placing each item in one source category. The counts below are invented but realistic.

The audit changed the benchmark before any detector ran. The 340 rater-labelled items had an agreement of 0.61 between two raters, low enough to report them as a separate partition. The 150 generated items with no saved prompt were flagged, since they can never be regenerated. The leakage check matched 27 of the 610 archive items in a public corpus index; they were removed and the set moved to version 1.1. The headline false positive rate, 9 of 1,003 human-written items flagged (0.9%, 95% interval 0.4% to 1.7%), was reported against version 1.1 and its manifest hash, and a second team reproduced it three months later.

Pitfalls

• Lineage reconstructed after the run. Origins filled in from memory are estimates presented as facts.
• Author category by assumption. "Found on the web before 2022" fails when drafts, translations and rewrites circulate undated.
• Hashing before the last transformation. A hash taken before truncation binds the record to bytes that were never scored.
• Silent edits under one version. Fixing a typo without bumping the version makes two results incomparable while looking identical.
• Leakage checked once. A model retrained after the check may now contain the set. Repeat it when the model changes.

What to record and how to report it

A run report cites the set version and manifest hash, the items per partition and labelling method, the agreement figure for any rater-labelled partition, the leakage result with its index version, and the run date and detector version. Rates go with denominators and intervals. Where the result may be quoted in a dispute, the manifest, the bytes and the run output are stored read-only with the person and time of each step, as described in a test record that holds up as evidence. Which sets run and how often belongs in the strategy that governs the test effort; the lane's other guides are in the hub for testing AI systems and authenticity pipelines.

Data lineage turns an evaluation set from a folder of files into evidence. Every manifest field answers a question a sceptical reader will ask, and the version with its hash lets two people argue about the same bytes. Record it, freeze it, cite it.

This guide is part of the testing AI systems hub. It is best read alongside evaluation test set design for ai models and inter-rater agreement for ai evaluation labels, which cover the neighbouring questions.