Provenance and versioning for small datasets

Goal

Make every dataset used in a report answer three questions: where did it come from, what was done to it, and which exact version produced this number.

Prerequisites

A repository for the code, a storage location for files too large for it, and the rule that raw data is never edited in place. The W3C PROV data model supplies the vocabulary: entities (files, tables), activities (a cleaning script run), agents (a person or program), and relations such as wasGeneratedBy, used, wasAttributedTo and wasDerivedFrom.

Steps

1. Keep raw data immutable in a raw/ directory or bucket; name files with source and retrieval date, and record the exact origin (URL, query, export settings, who supplied it) in a README beside them.
2. Compute and store a checksum for every raw file; later references cite the checksum, not only the name.
3. Derive, never overwrite: each transformation is a script that reads one version and writes a new file; the script and its parameters are the provenance of the output.
4. Version the data with the code. Files that fit are committed directly; for larger files, commit a pointer. The DVC getting-started guide shows dvc add data/data.xml producing a small .dvc file with the file's hash, which Git tracks while the content goes to a cache and a configured remote. Git LFS works on the same principle: its project page describes replacing large files with text pointers inside Git while the contents live on a remote server.
5. Describe the package: a datapackage.json descriptor following the Data Package standard lists the resources with their paths and licences and, for tabular files, a Table Schema (field names, types, constraints, missing values), so that tools can validate the files and readers know what a column means.
6. Tag the state used by a report: a Git tag or commit hash covering code and data pointers; put that identifier in the report.
7. Write a short provenance note per derived file in PROV terms, for example clean.csv wasDerivedFrom raw/export-2026-09-01.csv; wasGeneratedBy clean.py@abc123; wasAttributedTo <agent>. Prose is enough; the vocabulary keeps it consistent across projects.

Expected result

Any figure in a report resolves to a commit, a data checksum and a script; a corrected raw export produces a new version rather than an untraceable edit.

Limits and test basis

Personal data and licences constrain what may be stored and shared; provenance records must not become a copy of restricted data. Very frequent updates (streams) need a database with audit history rather than files. The workflow follows the cited specifications and documentation; no measurement of its cost is claimed.