A CSV fails on structure long before it fails on content.

A model asked for a dataset produces plausible rows. It does not know your column contract, so an address containing a comma arrives unquoted, and the row silently gains a field.

The second failure is truncation. Long generations stop mid-row, which produces a final line with fewer columns than the header and no error until import time.

The third is drift within a file: dates formatted per row, a currency symbol appearing halfway down, a numeric column with a stray unit in one cell.

Parsing the file as a table exposes the mechanical defects immediately, without any knowledge of what the data means.

Structural checks do not know that a column is meant to be a date. That requires a schema: column names, types, required fields and value ranges.

Where the schema matters, validate against it explicitly. A date column accepting three formats will load in a spreadsheet and fail in a database, and the failure appears in production rather than in review.

Prioritise the columns that join. An identifier with a leading zero lost to spreadsheet coercion is the classic, and it is invisible until the import matches nothing.

Commas inside text need quoting, quotes inside text need doubling, and line breaks inside a field need the whole field quoted. Each of those is a parse failure waiting to happen.

Encoding is the other silent one. A UTF-8 file opened as Latin-1 produces mojibake in names and addresses, which is a data quality incident rather than a display quirk.

Check for a byte-order mark at the start, which breaks the first header name in surprising ways on some loaders.

It cannot tell you whether the data is correct, representative or current. A structurally perfect file can encode a fabricated dataset, which is exactly the risk with generated tables.

It cannot tell you whether the aggregation is right. Totals, deduplication and unit consistency are questions about the domain.

And it cannot tell you whether publishing the file is lawful. A clean CSV of personal data is still personal data.

Validate the structure first, and fix the ragged rows before anything else, since every downstream count depends on the parse being right.

Then check the join column against a known-good list, and the date column for a single format. Those two checks catch most real import failures.

Then sample ten rows and read them. If the data is generated, the sample is where invented names, impossible dates and duplicated addresses become obvious.