Sample Drift Card is for sample-pack curators cleaning up raw one-shot exports before they hit an ingestion spreadsheet, a pack manifest, or some distributor portal that treats inconsistent naming like a crime scene. The recurring job is familiar: a folder of kicks, snares, hats, stabs, and tonal hits arrives with half-useful filenames, guessed tempos, uneven keys, and tags that need to become operational metadata instead of producer folklore.
Project marker: sample-drift-card-v1.
The canonical fixture is a raw CSV of one-shot rows. Load it, tune tempo tolerance, key normalization, duplicate detection, energy banding, and filename policy, then apply the transformation explicitly. Pending controls are visible before they touch the result, because invisible auto-cleanup is how a pack leaves the studio with snare_final_REAL2.wav still pretending to be metadata.
Four systems define daily-2026-07-25-sample-drift-card:
- One-shot metadata normalization. The tool turns inconsistent source rows into stable sample cards with normalized tempo, key, instrument family, energy band, duplicate warnings, and pack-safe rename suggestions.
- Material rule controls. Tempo tolerance, key policy, duplicate sensitivity, energy grouping, and rename format each affect the canonical fixture independently. The interface is not a slider museum.
- Before/after curation review. Source rows and transformed manifest evidence sit in the same workspace so a curator can inspect what changed before exporting.
- Parser-ready manifest output. Export writes a JSON manifest and rename CSV shaped for Splice-style sample pack ingestion prep. The committed validator checks structure, transformed fields, rename evidence, warnings, and downstream-safe formatting.
The downstream target is deliberately unglamorous: a sample-pack ingestion prep spreadsheet and manifest parser. That is the actual pressure point. Sample libraries do not need a mood board. They need boring, stable fields that survive handoff from the curator to the catalog system.
The live release was verified by opening the published browser app, running the canonical fixture through the workflow, exporting the manifest bytes, and rerunning the committed validator against the live output.