Markdown Table to JSON Conversion Prompt Template

This prompt is a post-generation repair tool for data pipeline engineers and platform teams. Use it when a model returns a well-formed markdown table instead of the structured JSON your downstream system requires. The core job is to convert that table into a clean JSON array of objects with correct types, null handling, and a predictable schema, so it can enter a database, API, or analytics pipeline without manual cleanup. This is a tactical fix for a specific failure mode, not a replacement for schema-first output design.

The ideal scenario is a validation-and-repair loop: your primary structured output generation fails validation, the fallback logic detects a markdown table in the response, and this prompt acts as the repair step before retrying or escalating. It assumes the markdown table is syntactically well-formed but needs type coercion (e.g., "$1,200" to 1200.00), null handling for empty cells, and conversion to a JSON array of objects. You should wire this prompt behind a validator that checks for row count preservation, required field presence, and type correctness before the output proceeds further.

Do not use this prompt as your primary generation strategy. If you consistently receive markdown tables instead of JSON, fix the root cause by improving your system prompt, output schema instructions, or model choice. This prompt is also inappropriate for repairing severely malformed tables with merged cells, missing headers, or inconsistent column counts—those require a different repair strategy or human review. For high-risk domains like finance or healthcare, always add a human approval step after conversion to verify that no data was dropped or mistyped during the repair.

This prompt template is designed to be dropped into a post-generation repair loop when a model has returned a markdown table instead of the expected JSON structure. It accepts the raw markdown table, an optional output schema, and explicit constraints about type coercion, null handling, and row preservation. The template uses square-bracket placeholders so you can wire it into your application's prompt assembly layer without manual editing.

textCopy
You are a precise data conversion tool. Your only job is to convert the provided markdown table into a valid JSON array of objects.

## INPUT MARKDOWN TABLE
[INPUT]

## OUTPUT SCHEMA (OPTIONAL)
If provided, map each column to the specified field name and type. If not provided, use the header row as field names and infer types from the data.
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## CONVERSION RULES
1. Preserve every row from the input table. The output array must have exactly the same number of objects as the input table has data rows.
2. Coerce values to the types specified in the output schema. If a value cannot be coerced, set it to null and add a "_coercion_error" field with the original value and reason.
3. Trim whitespace from all string values.
4. Convert empty cells to null, not empty strings, unless the schema explicitly requires strings.
5. For numeric fields, remove commas, currency symbols, and percentage signs before parsing. Store the raw numeric value.
6. For boolean fields, accept "true", "yes", "1", "y" as true; "false", "no", "0", "n" as false (case-insensitive).
7. Do not add, remove, or reorder columns beyond what the schema specifies.
8. Do not include any explanatory text, markdown fences, or commentary. Return only the JSON array.

## EXAMPLES
[EXAMPLES]

## OUTPUT
Return a single JSON array of objects. No other text.

To adapt this template, replace each placeholder with the values your application assembles at runtime. The [INPUT] placeholder should receive the raw markdown table string. The [OUTPUT_SCHEMA] placeholder can be a JSON Schema fragment, a list of field-name-to-type mappings, or an empty string if you want the model to infer types from the header row. The [CONSTRAINTS] placeholder lets you add domain-specific rules, such as date format requirements, enum value lists, or maximum string lengths. The [EXAMPLES] placeholder should contain one or two few-shot examples showing the expected input-output pair, which dramatically improves conversion accuracy for edge cases like merged cells or multi-line cell content. After conversion, always validate the output JSON against your expected schema and verify that the row count matches the input table's data rows before allowing the payload to proceed downstream.

The Markdown Table to JSON prompt is designed to be called as a post-processing step in a data pipeline, not as a standalone chat interaction. In a typical production flow, a primary model generates a narrative response that includes a markdown table. Your application detects the table, extracts it, and passes it to this repair prompt. The prompt's output is a JSON array of objects that can be validated against your expected schema before ingestion into a database, API, or analytics store. The harness around this prompt is what makes it reliable: you need a clear contract for inputs, a strict schema for outputs, and a set of validation checks that run before the data moves downstream.

Start by wrapping the prompt in a function that accepts a single markdown_table string and an optional expected_schema definition. The function should call the model with response_format set to json_object (or the equivalent for your provider) and a low temperature (0.0–0.1) to maximize determinism. After receiving the response, parse the JSON and run a series of validation checks before returning the result. At minimum, validate that: (1) the output is valid JSON, (2) the top-level structure is an array, (3) the number of rows matches the number of data rows in the input table, (4) all required fields from your expected schema are present in every object, and (5) field types match the expected types (string, number, boolean, null). If any check fails, log the failure with the input table, the raw model output, and the specific validation error. Then decide whether to retry, fall back to a simpler parser, or escalate for human review.

For retry logic, implement a maximum of two retries with exponential backoff. On the first retry, append the validation error message to the prompt as additional context so the model can self-correct. For example, add a line like The previous output failed validation: [ERROR_MESSAGE]. Please fix the output. before resubmitting. If the second attempt also fails, do not retry indefinitely. Instead, route the failure to a dead-letter queue or a human review interface. For high-throughput pipelines, consider implementing a circuit breaker that stops sending requests if the failure rate exceeds a threshold (e.g., 20% over a 5-minute window). This prevents cascading failures and wasted API costs when the model is consistently producing malformed outputs.

Logging and observability are critical for this prompt because it operates in a repair loop. Log every call with: the prompt version, model identifier, input table hash, output row count, validation pass/fail status, latency, and token usage. If validation fails, also log the specific field and value that caused the failure. These logs feed into your eval dashboard, where you can track metrics like row count preservation rate, type coercion accuracy, and overall repair success rate. Use these metrics to decide when the prompt needs updating—for example, if you see a spike in type coercion failures for a specific field, you may need to add an explicit example or constraint to the prompt template. Finally, always run this prompt in a staging environment with a golden dataset of known markdown tables and expected JSON outputs before deploying any prompt changes to production.