Free Text to CSV Record Repair Prompt Template

This prompt is for integration engineers and data pipeline operators who receive narrative or semi-structured text from a model when a structured CSV output was expected. The primary job-to-be-done is to convert a messy, free-text model response into a clean, delimited, and consistently ordered CSV record that can be ingested by downstream systems without manual cleanup. The ideal user is someone building a production data extraction pipeline who needs a reliable repair step after a primary structured-output generation attempt has failed or produced an unparseable result.

Use this prompt when the model's output contains the correct data but in the wrong shape—for example, a paragraph describing a transaction instead of a comma-separated row, or a markdown list of fields instead of a quoted CSV line. The prompt is designed to enforce consistent column ordering, proper quoting of fields containing commas or newlines, and escaping of double-quote characters. It is not suitable for repairing outputs where the underlying data is missing, hallucinated, or factually incorrect; for those cases, pair this with a factuality or hallucination-removal prompt from the Output Repair pillar. Do not use this prompt when the model has already produced valid CSV that merely needs schema validation—use a schema-mismatch repair prompt instead.

Before wiring this into an application, define the exact column schema you require and provide it as part of the [OUTPUT_SCHEMA] placeholder. The prompt works best when the expected columns are explicitly listed with their data types and a brief description, so the model can map narrative fields to the correct columns. For high-stakes pipelines involving financial, legal, or healthcare data, always add a human review step after repair and log both the original and repaired outputs for auditability. The next section provides the copy-ready template you can adapt and test against your own failure cases.

This prompt template is designed for integration engineers who need to repair model outputs that failed to produce structured CSV data directly. When a model returns a narrative response, markdown table, or semi-structured text instead of a clean CSV row, this prompt converts that raw output into a properly delimited record with quoted fields, escaped special characters, and consistent column ordering. The template uses square-bracket placeholders that you replace with your specific schema, input text, and output constraints before sending it to the model.

textCopy
You are a data normalization assistant. Your task is to convert the provided free-text model response into a single, valid CSV record.

## INPUT TEXT
[RAW_MODEL_OUTPUT]

## TARGET SCHEMA
You must produce a CSV row with exactly these columns, in this order:
[COLUMN_NAMES]

## RULES
1. Extract values from the input text for each column. If a value is not present, use an empty string.
2. Enclose every field value in double quotes.
3. Escape any double quotes within field values by doubling them ("" -> """").
4. Join fields with a comma delimiter. Do not add spaces around commas.
5. Output ONLY the CSV row. Do not include headers, markdown fences, explanations, or any other text.
6. If the input contains multiple potential records, extract only the first complete record.
7. Normalize [NORMALIZATION_RULES] as specified.

## OUTPUT FORMAT EXAMPLE
Given columns ["Name", "Role", "Start Date"], a correct output would look like:
"Jane Doe","Senior Engineer","2024-01-15"

## CONSTRAINTS
[ADDITIONAL_CONSTRAINTS]

## RISK LEVEL
[RISK_LEVEL]

Produce the CSV row now.

To adapt this template, replace [RAW_MODEL_OUTPUT] with the free-text response you need to repair. Set [COLUMN_NAMES] to a comma-separated list of your target column headers in the exact order required by your downstream CSV parser. Use [NORMALIZATION_RULES] to specify any domain-specific transformations, such as date format standardization (YYYY-MM-DD), phone number canonicalization (+1-555-0100), or enum value mapping ('admin' -> 'Administrator'). The [ADDITIONAL_CONSTRAINTS] placeholder lets you add field-specific rules like numeric range checks or required-field enforcement. Set [RISK_LEVEL] to low, medium, or high to control how aggressively the model should handle ambiguous or missing values—high-risk scenarios should trigger empty fields rather than guesses. After copying the template, test it against at least five representative inputs, including edge cases with missing fields, embedded commas, and double-quote characters, before wiring it into your production pipeline.

The Free Text to CSV Record Repair prompt is designed to sit inside a post-generation repair loop, not as the primary structured output generator. Wire this prompt after your initial model call returns narrative text or markdown instead of valid CSV. The harness should catch the malformed output, extract the raw text, inject it into the [RAW_TEXT] placeholder along with the expected [COLUMN_HEADERS] and any [FIELD_CONSTRAINTS], and call the repair model. This is a recovery path, so treat it as a fallback with its own timeout, cost budget, and failure mode.

Validation is mandatory before accepting the repaired output. After the repair model returns a CSV string, run it through a deterministic parser that checks: (1) the number of columns matches the expected header count, (2) every row has the same number of fields after quote-aware splitting, (3) no unescaped delimiter characters exist inside unquoted fields, and (4) required columns contain non-empty values. If validation fails, you have three options: retry the repair prompt once with the validation error message appended to [RAW_TEXT] as context, fall back to a simpler model with a stricter prompt, or escalate the record to a human review queue. Do not silently ingest broken CSV into downstream systems—corrupted delimiters will shift columns and poison databases.

Model choice matters for this task. Smaller, faster models often struggle with consistent quote escaping and delimiter discipline, especially when the raw text contains commas, quotes, or newlines inside field values. Prefer a mid-tier or higher model with strong instruction-following for the repair step. If latency is critical, use a fast model for the initial generation and reserve a more capable model for the repair path. Log every repair attempt with the original raw text, the repaired CSV, validation results, and the model version used. This trace data is essential for debugging systemic failures—if a particular input pattern consistently fails repair, you may need to adjust the upstream prompt or add a preprocessing step before the repair call.

Delimiter conflicts are the most common production failure. If your raw text contains the same character you're using as the CSV delimiter (e.g., commas in address fields), the repair model must quote those fields correctly. Your harness should detect this risk by scanning [RAW_TEXT] for the target delimiter character before calling the repair prompt. If the text is delimiter-heavy, consider using a less common delimiter like the pipe character (|) or tab, and specify this explicitly in the [FIELD_CONSTRAINTS] section of the prompt. For high-risk pipelines where data integrity is non-negotiable, add a post-repair reconciliation step: count the number of records in the raw text (if known) and verify the CSV row count matches. Mismatched counts indicate the model dropped or merged records and should trigger escalation.

Wire this into your application as a recoverable error handler, not a silent fixer. Wrap the repair call in a try-catch block with explicit logging, a maximum of two retries, and a dead-letter queue for records that fail all repair attempts. If you're processing a batch, isolate failed records so one bad repair doesn't block the entire pipeline. For regulated or financial data, always require human review on repaired records before they enter the system of record—the repair prompt is a recovery tool, not a guarantee of correctness. Monitor the repair rate as a key health metric: a rising repair rate signals that your primary structured output prompt needs attention, and you should invest in fixing the root cause rather than relying indefinitely on the repair path.