AI CSV Checks: Count Records, Not Lines

An AI-assisted import report says your CSV contains three orders. You expected two. The extra order appears to begin halfway through a delivery note. Before deleting that apparently broken line, check whether the import has mistaken a line inside a quoted field for the beginning of another record.

For independent creators and business owners, the important distinction is between the text file’s physical lines and its logical records. A delivery instruction can contain a line break while remaining part of one order. The review needs to preserve that relationship before counting, summarising or changing anything.

A line break can belong inside a field

RFC 4180, published in October 2005, documents a common CSV format. It describes fields containing line breaks, commas or double quotes as enclosed in double quotes. A double quote inside such a field is represented by a pair of double quotes. The document is informational, rather than an Internet standard.

The practical consequence is that a comma does not always separate fields, and a line break does not always separate records. Its role depends on the surrounding CSV structure. A routine that simply splits text at every comma and every line break has ignored that structure.

Establish the file’s delimiter, quoting rules, encoding and header convention before commissioning an AI-generated import. The settings need to match the source. A successful example from another export is a starting point for investigation, rather than proof that the same assumptions apply here.

Follow two fictional orders through four physical lines

Consider a fictional packing report with three fields: Order, Note and Parcels. Its text consists of the following four physical lines. The first order’s quoted note continues onto the third line:

• Order,Note,Parcels
• A101,"Leave at desk, please
• Call on arrival",2
• A102,"Label says ""Fragile""",1

For the checked example, the line endings are CRLF: carriage return followed by line feed. There is also a final line ending. The quotation marks beginning on the second physical line close on the third, so the line break between them belongs to A101’s Note field.

The final line represents A102. Its note reads Label says "Fragile" after parsing. The doubled quotation marks are the CSV representation of the quotation marks inside that text; they are not instructions to create another field.

The correct result is one header and two data records, each with three fields. The parcel counts are two and one, giving a total of three. These are invented orders, not business data.

Check the parser’s result rather than inferring it from the display

An isolated check using Python 3.12.14 and its standard csv.reader produced those two data records and preserved the embedded line break. Python’s CSV documentation explicitly warns that the reader’s line_num is the number of source lines read, which can differ from the number of records returned.

In the check, the header ended at source line 1, A101 ended at line 3 and A102 ended at line 4. Four source lines had been consumed, but only three rows had been returned, including the header. Subtracting one header from a physical-line count would therefore give the wrong number of orders.

This verifies the stated example in that Python environment. It does not establish how a particular spreadsheet, database or AI integration will import the file. Repeat the check along the actual route used for the work.

Keep newline handling and record counting explicit

Python’s documentation says to open file objects used with its CSV module with newline='', so the module can handle newlines itself. It also supports dialect settings for differences such as delimiters and quoting. Those are implementation choices to record in the handover.

For this fictional report, count data records after parsing and after identifying the header. Retain the source order identifiers beside the parsed notes. Ask for field counts and the parcel total as separate checks, so the owner can inspect whether the structure and values survived.

If a note unexpectedly becomes a new order, return to the source text and parser settings. Deleting the line might make a count look plausible while losing a real delivery instruction. An unexplained repair is particularly difficult to assess once the original has been overwritten.

Turn awkward examples into acceptance cases

A useful trial should include the content the workflow is expected to preserve. For the fictional packing report, I would require the following outcomes. This is a proposed review routine, rather than a claim that these cases cover every CSV variant:

• The comma in A101’s note remains inside the Note field.
• The line break within that note is retained without creating an order.
• The quotation marks around “Fragile” survive as note content.
• Both parsed records retain three fields and the correct order identifiers.
• The data-record count is two and the parcel total is three.

Set those expectations before reviewing the generated importer. If the implementation disagrees, investigate the source convention, parsing operation and intended result. Do not redefine the expected content merely to match the output.

A blank field and a missing record also deserve separate treatment. The example contains neither an empty order nor a spare line to remove. If those appear in a later export, document their meaning before adding a cleanup rule.

Make the saved handover explain what was counted

For the final report, write that the source had four physical lines and two data records after its header was excluded. Preserve the distinction in any AI summary. A broad label such as rows can otherwise leave a collaborator unsure whether it refers to displayed lines or parsed records.

MaryChuks.com’s guide to repeated keys in AI-edited JSON examines a related issue: the way software reads a structured file can affect what remains available for review. Keep the original text and the interpreted result connected.

The finished importer should demonstrate that each order still carries its own instruction and parcel count. Once that relationship is intact, counting and summarising become meaningful. The aim is a dependable handover in which another person can explain what constitutes a record and reproduce the checks.

Sources

Primary documentation checked on 29 October 2026. The packing report is fictional. Its stated parsing outcomes were checked with Python 3.12.14; no live business import was tested.

• RFC 4180: Common Format and MIME Type for Comma-Separated Values Files — October 2005.
• Python 3.12 documentation: CSV File Reading and Writing — maintained documentation.