CSV Dialect Control Prompt Template

This prompt template is built for ETL engineers, data pipeline builders, and integration developers who cannot tolerate CSV dialect ambiguity. If your target system rejects files because of semicolon-vs-comma confusion, inconsistent quoting around fields containing delimiters, or wrong line terminators, this prompt provides the explicit dialect contract the model needs to produce conformant output on the first attempt. It is not for generic CSV generation or ad-hoc spreadsheet exports. It is for production pipelines where a single malformed row breaks an automated ingestion job.

The template forces you to declare every dialect parameter upfront: the delimiter character, quote character, escape rules, line terminator sequence, and header presence. You also supply the exact column schema, null representation rules, and an output example that demonstrates the expected quoting behavior. This level of specificity removes the model's freedom to guess your dialect. In testing, the most common failure mode is not the model ignoring the rules—it is the input data containing the delimiter character without proper escaping, which the prompt's quoting instructions must handle explicitly. Always include a concrete example row that contains your delimiter, a quote character, and a newline-like value to verify the model applies escaping correctly.

Do not use this prompt when you need the model to infer a schema from unstructured text, when you are generating CSV for human review only, or when your downstream system is lenient enough to accept multiple dialects. In those cases, a simpler CSV generation prompt with less rigid constraints will suffice. If you are working with regulated data, financial records, or healthcare information, add a human review step after generation and before ingestion. The prompt can produce syntactically valid CSV, but it cannot guarantee semantic correctness of the cell values. Wire the output through a dialect validator and a schema validator before it reaches your target system.

The following prompt template is designed to generate CSV output that conforms to a specific dialect. It forces the model to declare and adhere to delimiter, quote character, escape rules, and line terminators before producing any data. This is not a generic 'output CSV' instruction—it is a dialect contract that prevents the most common CSV generation failures: delimiter collision, inconsistent quoting, and platform-specific line ending mismatches.

textCopy
You are a CSV generation engine. You must produce output that strictly conforms to the CSV dialect parameters defined below. Do not deviate from these rules under any circumstance.

## Dialect Parameters
- Delimiter: [DELIMITER]
- Quote character: [QUOTE_CHAR]
- Escape character: [ESCAPE_CHAR]
- Line terminator: [LINE_TERMINATOR]
- Header row required: [HEADER_REQUIRED]
- Quoting strategy: [QUOTING_STRATEGY]

## Quoting Rules
1. If QUOTING_STRATEGY is "ALL", wrap every field value in the quote character.
2. If QUOTING_STRATEGY is "MINIMAL", only quote fields that contain the delimiter, the quote character, or the line terminator.
3. If QUOTING_STRATEGY is "NONNUMERIC", quote all non-numeric fields.
4. If QUOTING_STRATEGY is "NONE", never quote any field. If a field contains the delimiter, quote character, or line terminator, replace those characters with a single space.

## Escape Rules
- If a quoted field contains the quote character, escape it by doubling it (e.g., "" becomes """").
- If ESCAPE_CHAR is set to a specific character, use that character to escape the quote character instead of doubling.
- Never let an unescaped quote character appear inside a quoted field.

## Line Terminator Rules
- Use the exact LINE_TERMINATOR specified. Do not mix \n and \r\n within the output.
- The last record may or may not end with a line terminator, per [FINAL_TERMINATOR] preference.

## Input Data
[INPUT_DATA]

## Output Constraints
- If HEADER_REQUIRED is true, the first row must be a header row with column names derived from the input data.
- Every record must have exactly the same number of fields.
- Do not include any text before or after the CSV output. No explanations, no markdown fences, no commentary.
- If the input data is empty or cannot be represented in the specified dialect, output an empty string.

## Output

To adapt this template, replace each square-bracket placeholder with your target dialect parameters. For a standard RFC 4180 CSV, set [DELIMITER] to ,, [QUOTE_CHAR] to ", [ESCAPE_CHAR] to " (doubling), [LINE_TERMINATOR] to \r\n, [HEADER_REQUIRED] to true, and [QUOTING_STRATEGY] to MINIMAL. For tab-separated values, change [DELIMITER] to \t. For Excel-compatible CSV in European locales, set [DELIMITER] to ;. The [INPUT_DATA] placeholder should receive your source records in a structured format such as a JSON array of objects, which gives the model clear field boundaries to map to columns.

Before wiring this into a production pipeline, test it against your target parser. Common failure modes include: the model adding markdown fences around the output despite instructions, inconsistent quote escaping when fields contain both delimiters and quotes, and trailing whitespace inside quoted fields. Add a post-generation validation step that parses the output with your target CSV library and rejects any response that fails to parse with the expected dialect parameters. If the validation fails, retry with the same prompt or escalate to a repair prompt.

The CSV Dialect Control prompt is designed to be the final generation step before data lands in a downstream system. It should be wired into an application harness that treats the prompt as a deterministic function: accept a dialect specification and source data, return a validated CSV string or a structured error. The harness is responsible for enforcing the contract, not the model. This means the application layer must own dialect validation, retry logic, and logging before any byte reaches a database, file system, or analytics tool.

Build the harness around a generate_csv(dialect_spec, source_data) -> Result function. The function should: (1) assemble the prompt with the dialect spec and source data injected into the template; (2) call the model with temperature=0 and explicit response_format instructions if available; (3) run the raw output through a dialect validator that checks the actual delimiter character, quote character, escape rules, line terminators, and header presence against the spec; (4) if validation fails, retry up to two times with the validation error message appended to the prompt as a correction instruction; (5) if all retries fail, log the failure with the full prompt, raw output, and validation errors, then escalate to a dead-letter queue or human review. For high-throughput pipelines, add a pre-flight check that scans source data for characters that collide with the chosen delimiter or quote character and either reject the batch or auto-escalate the dialect choice.

Log every generation attempt with a trace ID, the dialect spec hash, the model and version used, the validator result, and the retry count. This trace data is essential for debugging dialect drift when downstream systems suddenly reject output that previously passed. Avoid the temptation to fix malformed CSV in post-processing scripts—every silent repair hides a prompt failure that will recur. Instead, use the harness to surface failures early, tune the prompt or dialect spec, and keep the generation path auditable.