Dataset Versioning
Dataset versioning records the exact data snapshot, labels, filters, schema, and split policy used for training or evaluation. Without it, experiment tracking can tell which run won but not what evidence it used.
Pinning a dataset version
A dataset version should be immutable and addressable. It should identify source tables or files, extraction time, transformation code, label definition, exclusions, schema, checksums, and train/validation/test split seed. For mutable warehouses, table name is not a version; the snapshot or query result is.
Concretely, suppose two training runs a week apart both read warehouse.events filtered to June. If late-arriving rows land in the June partition between the runs, the two models learn from different data under an identical query — an untracked change that makes any comparison between them meaningless. Pinning the snapshot time (or materializing the query result) means re-running the manifest reproduces exactly the same rows, which is the precondition for experiment tracking and model-versioning to mean anything.
Artifact: Dataset Manifest
dataset:
name: churn_training
version: "2026-07-11.v3"
sources:
- table: warehouse.customers
snapshot: "2026-07-10T23:59:00Z"
- table: warehouse.events
snapshot: "2026-07-10T23:59:00Z"
label:
definition: "cancelled subscription within 30 days"
positive_window_days: 30
split:
method: deterministic_hash
key: customer_id
seed: 20260711
checks:
row_count: 1832741
schema_hash: "sha256:6b7f..."Training pipelines should emit this manifest and model-versioning should point to it. The related data-engineering page on data lineage covers the upstream graph; this page fixes the ML snapshot contract.
Failure Modes
Common failures are training from live tables, overwriting labels, changing exclusion rules without a new version, and mixing active-learning labels into old benchmarks. Version the split as well as the raw data.
References
Nav