Why CSV Import Edge Cases Escape Your Runbook
A note on how small divergences in CSV imports—column shifts, encoding issues, end-of-month exceptions—gradually drift outside the runbook.
CSV imports look simple on paper. Read a file with a fixed column order, a fixed encoding, and a fixed format. That is all there seems to be.
But real-world CSVs are rarely clean. Column names drift slightly, spaces creep in, full-width and half-width characters fluctuate, and at month-end a different person generates the file. Exceptions that are not in the runbook accumulate little by little.
The problem is not the exceptions themselves. It is that the decisions made when they occur live in people’s memories instead of the runbook.
This vendor always has one extra column
This month, delete blank lines before importing
This code can proceed even if the master record is missingThese decisions start as temporary workarounds. But when the same thing happens the next month, they quietly become standard operating procedure. Even though nothing is recorded in code or in the runbook, on the floor they turn into “the usual fix.”
I think the assumption that input is clean is risky even when handing data to AI. Before tuning prompts, you need to decide where to detect input drift and how to roll back to the original data when something fails.
The quiet failures of CSV import are an input-quality problem that existed long before AI. The newer the technology you introduce, the more important it is not to ignore this old issue.
