Before accepting an AI-written CSV importer, check that every source column remains distinguishable through parsing, header cleanup and destination mapping. A successful read and the expected row count can coexist with a lost field. Validate the column contract before constructing the records that the rest of the application will use.
This matters for routine business integrations: order uploads, reporting exports, supplier files and migration scripts. An assistant may produce a compact importer that reads a file into dictionaries, trims column names and immediately starts validating values. If two columns become one key along the way, later validation sees an already reduced version of the source.
This guide proposes a focused review method and fictional examples. The local checks described here exercise Python parsing and a small header guard. They are not an evaluation of an AI coding product or a production import system.
Keep column positions until names are trustworthy
The Python CSV documentation distinguishes a reader returning field lists from DictReader, which maps fields to dictionary keys. It also documents how dictionary reading handles records with extra or missing fields. Those conveniences are parsing behavior, rather than an application-specific schema check.
Start an unfamiliar import by retaining the header as an ordered list. Record the original label and position of each column. That preserves the information needed to diagnose a duplicate before any name-based representation obscures it.
Consider this fictional file:
request_id,amount,amount
Q-17,120,15There are three source fields in the data record. A dictionary cannot retain two separate entries under the same amount key. In our local Python check, DictReader retains the later value, 15, under that key. The record count remains one, so a check that only counts imported rows misses the loss of 120.
The example does not tell us what the two amounts mean. They might be an invoice amount and a discount, amounts in different currencies, or a duplicated export column. That uncertainty is the reason to stop mapping, rather than a reason to choose the first or last value.
Normalization creates a second collision point
Checking exact duplicates is necessary, but it does not cover what the importer does next. A cleanup rule can turn different labels into the same name. For example, an application that strips surrounding whitespace and case-folds labels maps both Amount and amount to amount.
Keep that rule explicit. Do not ask the assistant to make headers generally consistent and let it choose arbitrary punctuation removal, abbreviation expansion or synonym matching. Those transformations change which distinctions the application can preserve.
The following illustrative guard checks raw and normalized uniqueness. It is a header check, not a complete CSV importer. It assumes an agreed header-bearing CSV dialect has already supplied a list of strings.
def checked_headers(raw):
if not raw or any(not name.strip() for name in raw):
raise ValueError("missing_header")
if len(set(raw)) != len(raw):
raise ValueError("duplicate_header")
canonical = [name.strip().casefold() for name in raw]
if len(set(canonical)) != len(canonical):
raise ValueError("normalized_header_collision")
return canonicalFor the stated policy, request_id,Amount, amount must fail the second uniqueness check. A developer can then report the conflicting source positions and original names. The guard deliberately does not rename one column or guess which value should survive.
Preserve the source file separately from any corrected version. A useful diagnostic identifies the conflicting columns without copying the entire business upload into ordinary logs. The person correcting the export needs the original distinction, not a rewritten header that conceals what happened.
Parsing research does not settle business mappings
The 2018 paper by van den Burg, Nazábal and Sutton studies detecting CSV dialects from row and type patterns. Its scope discussion explicitly separates dialect recovery from broader tasks such as header and table detection. Recovering a matrix of strings is a different problem from establishing what its columns mean.
This is historical parsing research, not a study of today’s coding assistants or evidence of their error frequency. We use its problem boundary here, without importing its accuracy results into an AI reliability claim.
For a recurring business feed, agree encoding, delimiter, quoting and header expectations with the source owner. A format detector can help investigate an unfamiliar file. It cannot approve an ambiguous pair of business fields merely because it found a consistent rectangular table.
Validate the destination mapping separately
Unique source names do not guarantee unique destination fields. Suppose a fictional integration receives gross_total and total, and an AI-written alias table maps both to amount. The source header passes both uniqueness checks, but constructing the destination object can still overwrite a value.
Review the mapping as a small table before using it. Each accepted source column should have an explicit destination or an explicit exclusion under the import contract. For this proposed design, each ordinary destination field accepts one source column. A combination of columns requires a separately specified transformation.
| Source situation | Required review decision |
|---|---|
| Identical header labels | Reject the ambiguous header or obtain an approved positional mapping. |
| Different labels collide under cleanup | Report both originals; revise the source or approve a distinct mapping. |
| Unique sources map to one destination | Reject the collision unless a deliberate combining operation is defined. |
| Unexpected extra column | Apply the contract’s explicit reject or exclude policy; do not silently discard it. |
| Familiar columns arrive in another order | Map by approved identities, or reject if the feed contract requires fixed order. |
These are editorial recommendations, not universal rules for every CSV consumer. An exploratory tool may preserve duplicate names using positional identifiers or generated suffixes. That can retain addressability. It still does not establish whether amount_2 means a discount, a tax or an accidental duplicate.
For an operational feed, resolve that meaning before writing business records. Do not equate making the parser accept a file with making its interpretation acceptable.
Test the stage that could lose information
Give the coding assistant several deliberately different fixtures. Include an ordinary valid header, an exact duplicate, a whitespace-and-case collision, and two aliases aimed at one destination. State the expected accept or reject outcome before asking it to revise the importer.
Also include short and wide records. Header uniqueness does not prove that every later record has the expected number of fields. Parse records with the CSV library rather than splitting physical lines: a quoted field can contain a line break. Confirm the field count before associating values with the checked columns.
Check the intermediate representation as well as the final error message. A validator that runs after a dictionary has already discarded a field may be unable to describe the original problem. Preserve enough position-based information to show which input was rejected and why.
Kolesnik’s September 2026 practitioner guide to CSV import previews provides a related bounded example: enforce a known header and report record-level defects before any database write. Its example explicitly distinguishes validation from application and states its limits. It is practitioner guidance, not independent testing of an AI-generated importer.
Make successful rejection an acceptance result
An ambiguous file should produce a clear failure with no business writes from that attempted import. For this proposed contract, a header failure rejects the whole file before record application starts. Other record errors need their own agreed atomic or partial-import policy.
Ask for a report of the actual checks run, including the parser version and fixture revision. Do not accept an explanation that the code should handle duplicates as evidence that it did. Our record-cleaning guide addresses the separate question of whether similar row values identify the same business object; column validation must happen before those records can be interpreted reliably.
Start with one real feed contract and a tiny synthetic file containing distinguishable values in every column. Trace those values through the parser and mapping stages. The importer earns acceptance when it preserves every approved distinction and rejects the cases whose meaning remains unresolved.