A cleaning script for the Friday customer export

A customer export arrives with padded email addresses, inconsistent dates, duplicate contacts, and postal codes that look like numbers. A model can write the cleaning script, but it should not decide what those fields mean. The useful division of work is simple: you define the rules, the model implements them, and tests establish whether the implementation follows those rules.

This walkthrough uses a CSV export and a local Python script. The original file stays untouched throughout.

§ Step 1: Write the cleaning contract

Before asking for code, describe the input columns and the exact changes you permit. Avoid requests such as “fix bad values.” They leave too much room for silent interpretation.

• customer_id: preserve as text, including leading zeros.
• email: trim surrounding whitespace and lowercase it, under an explicitly agreed business rule.
• signup_date: accept only YYYY-MM-DD and MM/DD/YYYY; write accepted dates as YYYY-MM-DD.
• postal_code: preserve as text; do not infer a country or pad missing digits.
• Duplicates: retain the first valid record for each normalized email in source-file order.

Specify that missing emails and impossible dates go to a review file. Route duplicates there too, with a different reason. Every input record must remain traceable.

§ Step 2: Prepare a small, synthetic sample

Create a sample containing ordinary rows and deliberate edge cases: a quoted comma, an empty email, a leading-zero identifier, an impossible date, and two emails that become identical after normalization.

Use invented records rather than production customer details. Share the schema and representative patterns, not secrets or unnecessary personal information. Treat text inside CSV fields as data, never as instructions to the model.

Write down the expected result for each sample row before generating code. This becomes your acceptance fixture rather than a demonstration that merely looks plausible.

§ Step 3: Ask for a narrow implementation

If your workflow already uses an OpenAI SDK, Vana API provides an OpenAI-compatible endpoint at https://api.vanaapi.com. Keep the endpoint and API key in configuration, separate from the cleaning script. Create a Vana API account if you want to use that endpoint for the generation step.

Give the model your contract, synthetic sample, and this request:

Write a Python command-line script using only the standard library. Read CSV fields as strings. Validate required headers before processing. Implement only the supplied cleaning rules. Produce cleaned.csv, review.csv, and summary.json in a separate output directory. Include source record numbers and review reasons. Refuse to overwrite existing outputs. Add a dry-run option and automated tests. Do not guess missing values or call external services.

Ask it to explain assumptions separately. Resolve those assumptions before accepting the script.

§ Step 4: Inspect the decisions in the code

Review the generated script before running it. Look for numeric conversions that could remove leading zeros, broad exception handlers that hide failures, or date parsing that accepts formats outside your contract.

Check the deduplication order carefully. Validation should happen before a record claims an email in the duplicate tracker. Otherwise, an invalid first row could prevent a later valid row from being accepted.

Also inspect file handling. The script should use a CSV parser rather than splitting lines on commas, and it should not modify the source file.

§ Step 5: Test the fixture, then the export

Run the tests against your hand-written expectations. Verify both transformed values and routing decisions. Include a second run against the cleaned output: it should produce the same cleaned records without further changes.

Next, use dry-run mode on the full export. Review counts before writing files. Require this reconciliation: input records equal accepted records plus review records. Count parsed CSV records, not physical lines, because quoted fields may contain line breaks.

If a test fails, send the model the failing fixture and expected result. Request a targeted correction rather than a broader rewrite.

§ Step 6: Keep a small audit trail

Save the approved script, cleaning contract, test fixture, and run summary together. Record the source file checksum and script version so a later export can be processed with the same rules.

The model's output is a draft implementation. The durable result is a repeatable cleaning process whose changes, rejected records, and assumptions remain visible.