Incorrect Field Type Coercion Prompt Template

This prompt is for data engineers and integration developers who receive model outputs that are semantically correct but typed incorrectly—a string where an integer is required, a 'yes'/'no' string instead of a boolean, or an ISO date string that must become a typed date object. The job is to coerce these values into the correct types defined by a downstream schema without losing information or introducing silent corruption. You should use this prompt when your validation layer has already confirmed that the field names and structure match the target schema, but type mismatches are blocking ingestion into a database, API, or analytics pipeline.

The ideal user has a target schema available—either as a JSON Schema document, a database table definition, or a typed interface specification—and a batch of model outputs that failed type validation. The prompt requires three inputs: the malformed output payload, the target schema with type definitions for each field, and a coercion policy that specifies how aggressive the transformation should be (for example, whether 'N/A' should become null or raise a failure). The prompt produces a repaired payload plus a coercion audit log that records every type change, the original value, the coercion rule applied, and any fields that could not be safely coerced.

Do not use this prompt when the model output is structurally broken—missing required fields, hallucinated extra fields, or malformed JSON—because those problems require structural repair prompts first. Do not use it when the semantic meaning of a value is wrong rather than its type representation; coercing 'cat' to an integer will fail, and that failure is correct. This prompt is also inappropriate when the target schema itself is ambiguous or when multiple valid type interpretations exist and require business logic to resolve. In regulated or high-risk domains, always route coercion failures to a human review queue rather than silently defaulting or dropping values.

Before wiring this into production, define your coercion failure thresholds: how many uncoercible fields per record are acceptable, and what happens when the threshold is exceeded. Pair this prompt with a validation step that confirms the repaired output passes schema validation, and log every coercion decision for auditability. If you are processing high-volume streams, consider whether a deterministic transformation layer can handle common coercions before calling the model, reserving the prompt for ambiguous cases that require semantic judgment.

This prompt template accepts a model output record that contains type violations—such as string-encoded numbers, inconsistent boolean representations, or unparsable date strings—and a target schema that defines the expected types. It instructs the model to coerce each field to the correct type, produce a normalized output record, and generate a coercion audit log that records every change made. The template is designed to be dropped into a post-generation repair pipeline where downstream systems reject records that fail type validation.

textCopy
You are a type-coercion repair system. Your task is to correct type violations in a model-generated output record so that it conforms to a target schema.

## INPUT
Model Output Record:
[INPUT_RECORD]

Target Schema (field name → expected type):
[TARGET_SCHEMA]

## COERCION RULES
1. For each field in the target schema, inspect the corresponding value in the input record.
2. If the value is already the correct type, keep it unchanged.
3. If the value is the wrong type, attempt coercion:
   - String to Integer: Parse numeric strings (e.g., "42" → 42). If the string is not a valid integer, flag as COERCION_FAILED.
   - String to Float: Parse decimal strings (e.g., "3.14" → 3.14). If not a valid float, flag as COERCION_FAILED.
   - String to Boolean: Accept "true", "True", "TRUE", "yes", "1" → true. Accept "false", "False", "FALSE", "no", "0" → false. All other values flag as COERCION_FAILED.
   - String to Date: Parse ISO 8601 date strings (e.g., "2024-03-15" → "2024-03-15"). Attempt common formats (MM/DD/YYYY, DD-MM-YYYY, "March 15, 2024"). If unparsable, flag as COERCION_FAILED.
   - Number to String: Convert via string representation (e.g., 42 → "42").
   - Boolean to String: Convert to lowercase "true" or "false".
4. If a field in the target schema is missing from the input record, set it to [DEFAULT_VALUE] and note MISSING_FIELD in the audit log.
5. If a field in the input record is not in the target schema, drop it and note EXTRA_FIELD_REMOVED in the audit log.

## CONSTRAINTS
- Do not invent values for COERCION_FAILED fields. Leave them as [FAILURE_PLACEHOLDER].
- Preserve the semantic meaning of the original value. Do not guess.
- If the input record is empty or unparsable, return an error object.

## OUTPUT SCHEMA
Return a JSON object with exactly these keys:
{
  "corrected_record": { ... },
  "coercion_audit_log": [
    {
      "field": "field_name",
      "original_value": "...",
      "original_type": "string",
      "coerced_value": "...",
      "target_type": "integer",
      "action": "COERCED" | "KEPT" | "COERCION_FAILED" | "MISSING_FIELD" | "EXTRA_FIELD_REMOVED",
      "notes": "Optional explanation"
    }
  ],
  "coercion_summary": {
    "total_fields_in_schema": 0,
    "fields_coerced": 0,
    "fields_kept": 0,
    "coercion_failures": 0,
    "missing_fields_filled": 0,
    "extra_fields_removed": 0
  }
}

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace [INPUT_RECORD] with the raw model output that failed type validation, and [TARGET_SCHEMA] with a JSON object mapping each expected field name to its type (e.g., {"user_id": "integer", "score": "float", "is_active": "boolean", "created_at": "date"}). Set [DEFAULT_VALUE] to the fallback for missing fields—typically null, 0, "", or false depending on downstream requirements. [FAILURE_PLACEHOLDER] should be a sentinel value your pipeline can detect and escalate, such as "__COERCION_FAILED__". Provide [EXAMPLES] as few-shot demonstrations showing correct coercion behavior for your domain's common type mismatches. Set [RISK_LEVEL] to "low", "medium", or "high" to control how aggressively the model should escalate ambiguous cases. For high-risk pipelines, add a human-review step before the corrected record enters production systems.

The Incorrect Field Type Coercion prompt is designed as a post-generation repair step, not a standalone service. It should be invoked after a primary model call produces a payload that fails schema validation due to type mismatches—for example, a string "123" where an integer is required, or a string "true" where a boolean is expected. The prompt expects three inputs: the original malformed output, the target JSON Schema, and a set of coercion rules. Wire this into your application as a synchronous repair function that runs before the payload is committed to a database, forwarded to an API, or surfaced to a user. The function should accept the raw model output and the target schema, call the coercion prompt, validate the result, and either return the repaired payload or escalate for human review.

Validation and retry logic is critical. After receiving the model's coerced output, run it through a strict JSON Schema validator. If validation passes, log the coercion audit trail (the prompt should return a coercion_log array alongside the repaired payload) and proceed. If validation fails, implement a single retry with the validation error message appended to the prompt context. Do not retry more than once—if the second attempt fails, route the record to a dead-letter queue or a human review interface. For high-throughput pipelines, consider batching up to 10 records per prompt call, but ensure each record is independently validated. Model choice: use a model with strong JSON-following capability (e.g., GPT-4o, Claude 3.5 Sonnet). Avoid smaller or older models that may hallucinate field values during coercion. Set temperature=0 to maximize deterministic behavior.

Observability and audit requirements are non-negotiable for type coercion workflows. Log every coercion event with: the original value, the coerced value, the field path, the coercion rule applied, and the timestamp. This audit trail is essential for debugging downstream data quality issues and for compliance in regulated environments. If the prompt cannot coerce a value (e.g., the string "n/a" cannot become an integer), it should return a coercion_failure entry in the audit log rather than silently dropping or fabricating data. Your application code must check for these failures and decide whether to insert a null, apply a default, or escalate. Do not use this prompt for values that require semantic interpretation—for example, converting a free-text description into a numeric score. That is a separate extraction task, not type coercion. This prompt is for mechanical type conversion only.