An auditor asks a municipal ML team to reproduce exactly which dataset version and feature transformations produced a permitting-delay model deployed six months ago. The team needs to trace this after the fact. Which practice during data preparation makes this kind of reproducibility possible?

Mechanism: recording dataset versions, feature transformation logic, and lineage as part of the preparation pipeline, for example through Feature Store's versioning or dataset snapshots tied to each training run, creates a traceable record connecting a deployed model back to the exact data and transformations that produced it, which is exactly what reproducibility and audit requests depend on. Why the wrong options fail by concept: relying on script comments provides an informal, easily outdated description rather than a verifiable, queryable record tied to the specific run, comments drift out of sync with what the code and data actually did. Keeping only the most recent dataset version discards the historical record entirely, once that's gone there's no way to reconstruct what a model six months old was actually trained on. Re-running today's pipeline against today's data assumes the data and transformation logic haven't changed since then, an assumption that's rarely safe and defeats the purpose of an audit that specifically wants the historical state, not a fresh approximation of it. Scope caveat: lineage tracking only helps if it's applied consistently from the start, retroactively reconstructing lineage for data that was never versioned is often impossible. Operational check: pull the recorded lineage for the six-month-old model and confirm it resolves to a specific, retrievable dataset snapshot and transformation configuration, not just a general description.