Prompt · Data
Data cleaning prompt
Normalising human-entered records — addresses, company names, dates, phone numbers — where a silent "correction" is indistinguishable from corruption.
Normalise the records below.
<records>
{{records}}
</records>
Target format:
{{format}}
Rules:
- Apply only transformations that cannot lose information: whitespace, capitalisation, date and number formatting, obvious encoding artefacts.
- Do not correct spelling, expand abbreviations, infer missing values or merge records you believe are duplicates.
- Where a value is ambiguous — a date that could be day-month or month-day, a name that could be two people — leave it unchanged and flag it.
- Where a value cannot be parsed into the target format, leave it unchanged and flag it. Never substitute a default.
Return JSON:
{
"records": [ /* normalised, same order and same count as input */ ],
"flags": [ {"index": <number>, "field": "<name>", "issue": "<what is ambiguous>", "original": "<the value>"} ],
"changed": <count of records modified>
}
The output must contain exactly as many records as the input. If you would drop one, flag it instead.What to fill in
{{records}}- JSON or CSV rows. Send a batch, not one at a time — consistency across the batch is part of what you are buying.
{{format}}- Explicit: ISO 8601 dates, E.164 phone numbers, title case names. Ambiguity here becomes inconsistency in the output.
Why it is written this way
Every rule in the prompt is there because of a specific failure it prevents. Knowing which is which is what lets you adapt it instead of only pasting it.
Lossless and lossy are separated
Trimming whitespace is safe. Expanding "St" to "Street" is a guess that is wrong when it meant "Saint". The prompt permits the first category and forbids the second, which is the whole distinction between cleaning and corrupting.
Ambiguity is flagged, never resolved
03/04/2026 is two different dates. A cleaner that picks one is generating data. Flagging turns an invisible error into a visible queue.
The record count is fixed
Silent row loss is the hardest data bug to find, because nothing errors and the total only looks slightly wrong. Making the count an explicit contract catches it immediately.
Deduplication is excluded
Merging records is a decision with business consequences and no undo. It belongs in a separate, reviewed step — never bundled into a cleaning pass.
The version most people write, and what it costs
Clean up this data and fix any errors:
{{records}}"Fix any errors" is the licence to invent. It expands abbreviations wrongly, corrects a surname that was spelled correctly, silently reformats ambiguous dates to one interpretation, and quietly drops a malformed row. The output is cleaner and less true, and no field records that anything happened.
What it still gets wrong
- It has no reference data. It cannot validate that an address exists or that a company name is spelled the way that company spells it.
- Large batches drift — normalisation applied at row 5 may differ from row 400. Batch in chunks and spot-check across boundaries.
- Flagged records are the point of the output. A pipeline that ignores the flags array has gained nothing over the naive version.
Check it before you ship it
- JSONL Validator for Fine-Tuning DatasetsLine-numbered parse errors plus the structural checks uploads actually fail on.
- Dataset Deduplicator for Fine-TuningCatches duplicates that differ only in case, spacing or punctuation.
- CSV to JSON ConverterSpreadsheet export in, clean JSON records out, with types inferred.
To build one of these from scratch for a task not covered here, the prompt generator assembles the same structure — delimiters, output contract, edge cases — from an expert-authored blueprint, and the prompt review checklist is what to run over the result.