Wrong Field Name Mapping Prompt Template

This prompt is designed for integration engineers and data pipeline operators who receive model-generated JSON outputs that are structurally valid but use semantically equivalent field names that don't match the target canonical schema. The core job-to-be-done is mapping near-miss field names—such as customer_name to fullName, or purchase_amount to transactionTotal—to their correct canonical counterparts using a provided field dictionary, without altering the underlying values or structure. This is a post-generation repair step, not a schema design tool. You should use this prompt when your model consistently produces outputs with recognizable but incorrectly named fields, and you have a defined, authoritative mapping dictionary to enforce.

The ideal user has already validated that the model output is parseable JSON and that the mismatch is limited to field name semantics, not missing required fields, incorrect types, or hallucinated values. You must supply the prompt with three concrete inputs: the malformed model output, the target canonical schema with field definitions, and a field mapping dictionary that explicitly pairs expected canonical names with common near-miss variants. The prompt works best when the mapping dictionary is comprehensive and includes synonyms, abbreviations, and case variants that your specific model tends to produce. Do not use this prompt when the output is missing required fields entirely—use the Missing Required Field Injection Prompt Template instead. Do not use it when the model invents fields with no semantic relationship to the schema—use the Extra Hallucinated Field Removal Prompt Template.

This prompt is not a substitute for improving your upstream schema instructions or few-shot examples. If your model consistently produces wrong field names, first attempt to fix the generation prompt by providing explicit field name requirements and examples. Reserve this repair prompt for cases where the model's field name choices are unpredictable despite good instructions, or when you're consuming outputs from a model you don't control. The prompt includes an explicit instruction to preserve all values, nesting, and array structures unchanged—only field names are remapped. For high-stakes pipelines where incorrect mapping could corrupt financial, clinical, or legal data, always pair this prompt with a post-repair validation step that diffs the original and repaired outputs and flags any value changes for human review.

This prompt template is designed to be dropped directly into your repair pipeline when a model output contains field names that are semantically correct but don't match your canonical schema. It takes the malformed output, your target schema definition, and a field-mapping dictionary as inputs, then returns a corrected payload with all field names aligned to the canonical form. The template is structured to handle ambiguous mappings by requiring explicit resolution instructions rather than guessing.

textCopy
You are a schema correction engine. Your task is to map field names in the provided [INPUT_PAYLOAD] to the canonical field names defined in [TARGET_SCHEMA]. Use the [FIELD_MAPPING_DICTIONARY] to resolve near-miss and semantic-equivalent field names.

## INPUT PAYLOAD
```json
[INPUT_PAYLOAD]

TARGET SCHEMA

jsonCopy
[TARGET_SCHEMA]

FIELD MAPPING DICTIONARY

jsonCopy
[FIELD_MAPPING_DICTIONARY]

INSTRUCTIONS

1. For each field in the input payload, find its canonical equivalent using the mapping dictionary.
2. If a field name is already canonical, keep it unchanged.
3. If a field has no mapping in the dictionary and does not match the target schema, place it in an _unmapped_fields object in the output.
4. If a mapping is ambiguous (multiple possible canonical targets), place the field in an _ambiguous_fields array with the original field name, its value, and the candidate canonical names.
5. Preserve all field values exactly as they appear in the input. Do not coerce types or modify values.
6. Do not add fields that are not present in the input payload.
7. Do not remove fields that are present in the input payload, even if they are not in the target schema.

OUTPUT FORMAT

Return a JSON object with this structure:

jsonCopy
{
  "corrected_payload": {},
  "_unmapped_fields": {},
  "_ambiguous_fields": [],
  "_mapping_summary": {
    "total_input_fields": 0,
    "mapped_fields": 0,
    "already_canonical_fields": 0,
    "unmapped_fields": 0,
    "ambiguous_fields": 0
  }
}

CONSTRAINTS

• Do not invent field mappings. Only use the provided dictionary.
• Do not modify field values, types, or nesting structure.
• If the input payload is empty or not valid JSON, return an error object with "error": true and a "message" field.

To adapt this template for your pipeline, replace the three square-bracket placeholders with your actual data. The [FIELD_MAPPING_DICTIONARY] should be a flat JSON object where keys are the non-canonical field names your model commonly produces and values are the canonical field names from your schema. For example: {"customer_name": "fullName", "cust_email": "emailAddress"}. The [TARGET_SCHEMA] can be a full JSON Schema definition or a simplified list of canonical field names with their expected types. The _unmapped_fields and _ambiguous_fields outputs are critical for observability—log these in your repair pipeline so you can expand your mapping dictionary over time and catch schema drift before it causes downstream failures.

The Wrong Field Name Mapping Prompt is designed to sit inside a post-generation repair loop, not as a standalone one-shot call. After your primary model produces an output that fails schema validation due to near-miss field names, this prompt acts as a targeted correction step. You should invoke it only when validation errors are specifically about unrecognized field names—not missing required fields, type mismatches, or structural issues. Routing the right errors to this prompt prevents unnecessary retries and keeps your repair pipeline efficient.

Wire the prompt into your application as a validation-triggered repair step. When your schema validator returns errors containing unknown field names, extract the offending field names and the full model output. Pass both into the prompt template along with your canonical field dictionary. The prompt returns a corrected payload. Immediately re-validate the corrected output against your schema. If validation still fails, log the residual errors and either escalate to a human review queue or fall back to a default payload, depending on your risk tolerance. For high-throughput pipelines, implement a circuit breaker: if more than 5% of outputs require field-name repair within a rolling window, investigate whether your primary prompt or model has drifted and needs updating.

For observability, log every repair invocation with the original field names, the mapped field names, and the canonical dictionary version used. This audit trail is essential for debugging mapping failures—especially when the model uses a field name that is semantically close to multiple canonical names. Add an eval step that samples repaired outputs and checks mapping accuracy against a golden set of known near-miss-to-canonical pairs. If your field dictionary changes, re-run the eval suite before deploying. Avoid using this prompt for fields that carry regulated data or compliance significance without human review of the mapping decision.