Evidence and preparation
Dataset provenance: trace the source
Dataset provenance is the record of where material came from and how it became the collection being discussed. Start with a traceable history, not a claim that possession proves ownership or licensing permission.
Last checked
Keep the source history and the permission decision connected but separate. A well-documented origin does not by itself clear the rights.
What should a provenance record explain?
The W3C PROV Data Model describes provenance through entities, activities and responsible agents, including derivations between entities. In plain English, those distinctions help separate the material, what happened to it and who was responsible. The standard is a technical model, not a legal opinion on ownership.
Our suggested business record is deliberately simpler: identify the source, explain the steps that produced the proposed collection, name the responsible internal role and list the evidence still missing. You do not need to build a new catalogue system to start asking those questions.
Keep this record internal while it contains sensitive system names, people or contractual information. An introductory enquiry only needs a non-confidential summary.
Start with the systems and collection history
For each contributing source, record the business purpose for which the material was collected, its broad date range and the system that currently holds it. Distinguish records your team created from imported, commissioned, acquired or externally supplied material.
Ask what changed when a system migrated, a supplier changed or a business unit was acquired. Do not assume that today's folder structure reflects the original source. If only a spreadsheet export survives, record that limitation and identify any supporting documentation still available.
Use source labels that an internal colleague can trace. Avoid an entry such as old database if several systems fit that description. At the same time, do not include connection strings, credentials or private network details in an editorial or enquiry document.
Record transformations without rewriting history
List the steps between the original records and the proposed collection: extraction, exclusions, joins, deduplication, redaction, translation, labelling or other processing. For each step, note its purpose, the responsible role, the relevant date or version and what evidence of the method remains.
Separate a documented step from an assumption. If somebody believes that an old export removed duplicates but the method is unavailable, record that as unverified. Do not retrofit a precise account merely because a reviewer would prefer one.
An illustrative chain is a service-system extract followed by removal of attachments and a separately reviewed outcome-label file. Each stage should be identifiable; the final filename alone cannot explain how the parts were combined. This is an invented example, not a description of a customer dataset.
Connect provenance to the dictionary and version
A data dictionary explains what fields mean. A provenance record explains where the collection and its transformations came from. Link them using the same dataset identifier and version, rather than merging them into an unmaintainable document.
For example, a status field may have different definitions before and after a system change. The dictionary should explain the meanings; the provenance note should identify the change and which records it affects. Neither document should imply that a conversion restored missing historical detail.
Keep a short change record when the proposed scope changes. State whether a revision changes the records, only their documentation or both. This helps avoid discussing one version while reviewing a description of another.
Use the history to ask better permission questions
Create a separate questions list for the appropriate adviser: which agreements cover each contributing source, who can approve the proposed use, and what restrictions need resolving? Link to the relevant internal evidence without copying confidential terms into a public document.
Treat third-party contributions, customer material and personal information as distinct review areas. A purchase invoice, system administrator account or inherited archive is not enough reason to mark every issue cleared. If a permission cannot be evidenced, leave its status unresolved.
Use the existing agreement checklist for the wider commercial discussion and the anonymisation guide for the separate privacy distinction. This article does not replace either review or supply contract wording.
Finish with a small, usable working record
For each source or transformation, record: a stable label; what it contributed; the relevant period; the responsible internal role; where supporting evidence is held; its current verification status; and the next unresolved question. Use checked, partly checked and unknown honestly, with a date for the review.
Ask a colleague to trace one non-sensitive example through the description without opening new access to the source systems. Where the explanation breaks, add an evidence gap rather than inventing a missing link. Do not send the example itself to Fairlode.
For the first conversation, summarise the broad origins, preparation already documented and outstanding restrictions. Use the licensing readiness checklist to complete that outline. A traceable history can make the discussion more precise; it does not establish demand, a price or permission to share files.
General information, not legal advice, a valuation or a buyer offer. Illustrative examples are not customer case studies.
Sources and further reading
Sources checked 22 October 2026. Historical research is background, not evidence of current buyer demand.