Data Type Mismatch Repair Prompt

This prompt is designed for a specific job-to-be-done: repairing individual fields in a structured output that contain a value of the wrong data type. The ideal user is a backend or integration engineer who has already run a schema validator against a model's output and received a precise list of type mismatch errors. For example, a validator might flag that price is the string "19.99" instead of the expected number, or that is_active is the string "true" instead of a boolean. The prompt's job is to take that invalid payload, the target schema, and the specific error list, and then produce a corrected payload where only the type-coercion errors are fixed, along with a structured report of every change made.

To use this prompt effectively, you must wire it into a post-generation validation and repair loop. The workflow begins when a structured output fails validation. Your application should first filter the validation errors to isolate only data type mismatches, such as type violations from a JSON Schema validator. You then populate the prompt's placeholders: [INVALID_OUTPUT] with the full failed payload, [TARGET_SCHEMA] with the expected schema, and [TYPE_ERRORS] with the filtered list of mismatches. The prompt instructs the model to perform safe coercions—for instance, parsing numeric strings or converting "true" to a boolean—while handling dangerous edge cases. A critical edge case is the string "null" versus a JSON null value; the prompt forces the model to decide whether to coerce to a null literal or to treat it as a non-nullable string error, logging the decision. The output is not just the repaired payload but a coercion_report that details every action taken, enabling downstream audit and routing.

Do not use this prompt for repairing malformed syntax like broken JSON brackets, unquoted keys, or trailing commas. Those structural errors require a different tool, such as the JSON Repair Prompt Template, because a model cannot reliably coerce types in a document it cannot parse. This prompt assumes the input payload is already syntactically valid JSON (or another parseable format) and that the only errors are type mismatches against a known schema. If you feed a syntactically broken payload into this prompt, the model will likely fail to produce a valid repair and may hallucinate corrections. Always gate this prompt behind a syntax check. After the repair, you must re-validate the corrected payload against the schema. If the repair introduces new errors or the coercion_report flags destructive coercions, escalate the record for human review rather than silently ingesting potentially corrupted data.

The prompt below is designed to be pasted directly into your repair harness. It instructs the model to act on a specific invalid payload and a list of pre-parsed type errors, coercing values to their target types where safe. The model is explicitly told to handle edge cases like the string "null" versus a true null, and to report any destructive coercions it performs. Replace every square-bracket placeholder with the concrete data from your validation failure before sending the request.

textCopy
You are a precise data repair system. Your task is to fix type mismatches in a structured output that failed validation.

## INPUT
- Invalid Payload:
[INVALID_PAYLOAD]

- Type Errors (field path, expected type, actual type, current value):
[TYPE_ERROR_LIST]

## TARGET SCHEMA CONTEXT
[SCHEMA_CONTEXT]

## INSTRUCTIONS
1. For each error, attempt to coerce the current value to the expected type.
2. Follow these coercion rules:
   - String "true"/"false" -> Boolean.
   - Numeric string (e.g., "42", "3.14") -> Number.
   - String "null" or empty string -> null, only if the field is nullable.
   - Single-element array -> unwrap to scalar if the target type is scalar.
   - Scalar -> wrap in array if the target type is an array.
   - Boolean -> 1/0 for number, "true"/"false" for string.
   - If coercion is impossible or semantically destructive, keep the original value and flag it.
3. Do not invent new data. Do not change values that are already correct.
4. Return the fully repaired payload as valid JSON.
5. Append a `_repair_log` array at the top level of the response object. Each log entry must have:
   - `field`: the field path that was repaired.
   - `action`: "coerced", "kept_invalid", or "set_null".
   - `original_value`: the value before repair.
   - `repaired_value`: the value after repair.
   - `confidence`: "high", "medium", or "low".

## OUTPUT FORMAT
Return a single JSON object with the repaired payload and the repair log. Do not include any other text.

To adapt this template, replace [INVALID_PAYLOAD] with the exact JSON string that failed validation. Populate [TYPE_ERROR_LIST] with a structured list of errors, each containing the JSON path, expected type, actual type, and the offending value. The [SCHEMA_CONTEXT] placeholder should contain the relevant portion of your JSON Schema, Pydantic model, or interface definition so the model understands nullability and constraints. If your application cannot tolerate any destructive coercion, add a hard constraint: "If coercion would change semantic meaning, set the value to null and log the action as 'set_null' with low confidence." Always validate the repaired output against your schema before accepting it, and route any payload with a low-confidence repair log entry to a human review queue.

The Data Type Mismatch Repair Prompt is designed to sit inside a structured output pipeline, not as a standalone conversational tool. Its job is to receive a payload that has already passed JSON syntax checks but failed schema validation due to type errors—such as a string where a number is expected, or a bare value where an array is required. The prompt must be called programmatically, with the original payload, the target schema, and the specific validation errors injected into the [TYPE_ERRORS] placeholder. This separation of concerns keeps the repair logic focused: the model does not need to guess what went wrong; it receives a precise error report and acts as a targeted coercion engine.

The typical flow is: (1) Receive raw LLM output. (2) Parse as JSON. If parsing fails, route to a syntax repair prompt first. (3) Validate against the target schema using a library like Ajv (JavaScript/TypeScript) or Pydantic (Python). (4) If type mismatch errors are found, extract the error details—field path, received type, expected type—and populate the [TYPE_ERRORS] variable. (5) Call the LLM with this repair prompt, passing the original payload, errors, and schema context. (6) Parse the repaired payload from the model's response. (7) Re-validate. If still invalid, increment a retry counter and consider escalating to a human or a more capable model. Log every coercion action from the coercion_log for auditability. Set a maximum of 2 retries for type coercion before escalating, as repeated failures often indicate a deeper schema misunderstanding that no prompt can fix.

When wiring this into production, treat the coercion_log field as a first-class audit artifact. Each entry should record the field path, the original value, the coerced value, the coercion method applied (e.g., string_to_number, null_string_to_null, single_value_to_array), and a confidence flag. Store this log alongside the repaired payload so that downstream consumers and auditors can trace every transformation. For high-risk domains—finance, healthcare, compliance—route any coercion with a confidence below high to a human review queue. Never silently coerce values that could change business meaning, such as converting a date string to a different format or interpreting a numeric string as a different unit.

Model choice matters here. This prompt works best with models that have strong instruction-following and JSON output capabilities. For cost-sensitive pipelines, use a smaller, faster model for the repair step and reserve a more capable model for escalation when retries are exhausted. If the repair prompt itself returns malformed JSON, apply the same syntax repair step you use for the primary output. Avoid infinite loops by enforcing a hard limit of 3 total repair attempts (syntax + type) before failing the request and returning a structured error to the caller.