Duplicate Key Resolution Prompt for JSON Objects

This prompt is for integration engineers and backend developers who receive model-generated JSON objects containing duplicate keys—a common hallucination pattern where a model repeats a field name with different values inside the same object. The job-to-be-done is straightforward: take a malformed JSON object, apply a resolution strategy, and return a clean single-key object with an audit trail showing what was merged or discarded. You need this when your pipeline ingests JSON from LLMs, downstream parsers reject or silently overwrite duplicate keys, and you cannot control the model's output format at generation time.

Use this prompt when you have a specific JSON object that failed parsing or validation due to duplicate keys, and you need a deterministic repair before the payload enters your application logic. The ideal user has the raw model output, knows which resolution strategy applies—LAST_WINS, MERGE_VALUES, or FLAG_CONFLICT—and can feed both into the prompt. Do not use this prompt for general JSON repair (missing commas, bracket imbalances), for schema validation failures, or for objects where duplicate keys are intentional in a non-JSON context. This is a targeted surgical tool, not a general-purpose JSON fixer.

Before wiring this into production, define your resolution strategy per field. LAST_WINS is safest for idempotent values where later occurrences override earlier ones. MERGE_VALUES works when duplicate keys should combine into arrays or concatenated strings. FLAG_CONFLICT is appropriate for high-risk fields where automated resolution is unsafe and human review is required. You should also decide whether the merge audit—the record of what was changed—gets logged, stored alongside the output, or discarded. In regulated workflows, keep the audit trail for traceability. Next, copy the prompt template and adapt the placeholders to your object structure and resolution policy.

This prompt template is designed to be copied directly into your application's prompt layer. It instructs the model to accept a JSON object containing duplicate keys—a common hallucination pattern in model-generated structured output—and resolve them according to a specified strategy. The prompt requires the malformed JSON input and a resolution strategy, and it produces a clean, single-key object along with a structured audit of every merge decision made.

textCopy
You are a precise JSON repair system. Your task is to resolve duplicate keys in a JSON object.

## INPUT
You will receive a JSON object that may contain duplicate keys. This is the object to repair:
```json
[INPUT_JSON]

RESOLUTION STRATEGY

Apply the following strategy to resolve each set of duplicate keys: [RESOLUTION_STRATEGY]

Where [RESOLUTION_STRATEGY] is one of:

• LAST_WINS: Keep only the last occurrence of the key and its value. Discard all earlier occurrences.
• MERGE_VALUES: Combine all values for the duplicate key into a JSON array. The order of values in the array must match the order of occurrence in the original object.
• FLAG_CONFLICT: Replace the value with a conflict marker object {"__conflict__": true, "values": [<all values in order>]} and append an entry to the audit log.

OUTPUT SCHEMA

Return a valid JSON object with exactly two top-level keys:

1. repaired_object: The JSON object with all duplicate keys resolved. No keys are duplicated.
2. merge_audit: An array of objects, each describing one resolution. Each object has:
   • key: The duplicate key that was resolved.
   • strategy_applied: The strategy used (LAST_WINS, MERGE_VALUES, or FLAG_CONFLICT).
   • original_occurrences: The number of times the key appeared.
   • kept_value: The final value assigned to the key in repaired_object.
   • discarded_values: An array of values that were discarded or merged (empty for LAST_WINS when only one value is kept).

CONSTRAINTS

• Do not modify any key names or values except as required by the resolution strategy.
• Do not reorder keys in the repaired object; preserve the original key order, using the position of the first occurrence for merged or flagged keys.
• The output must be strictly valid JSON with no trailing commas, no comments, and no markdown fences.
• If the input contains no duplicate keys, return the object unchanged and an empty merge_audit array.

To adapt this template, replace [INPUT_JSON] with the malformed payload from your model's output. Since standard JSON parsers will reject or silently drop duplicate keys, you must capture the raw text response before parsing. Set [RESOLUTION_STRATEGY] to the strategy that matches your downstream tolerance: use LAST_WINS for simple API payloads where the last value is likely the correction, MERGE_VALUES when all occurrences may carry distinct data (e.g., multiple tags or categories), and FLAG_CONFLICT when ambiguity requires human review. After receiving the model's response, validate that repaired_object parses successfully and that every key in merge_audit corresponds to an actual duplicate in the input. If the model fails to produce valid JSON, retry with stricter formatting instructions or fall back to a deterministic post-processing script.

The Duplicate Key Resolution prompt is designed to sit inside a post-generation repair loop—after a model produces JSON but before that JSON reaches a downstream parser, database, or API client. Most JSON parsers will either reject duplicate keys outright or silently keep only the last occurrence, which means the model's intent is lost without a controlled resolution step. This harness intercepts the raw model output, detects duplicate keys via a pre-pass scanner, and only invokes the LLM repair prompt when duplicates are actually present. This avoids unnecessary latency and cost for clean outputs.

Wire the prompt into your application as a conditional repair stage. First, parse the raw model output string with a streaming JSON scanner that tracks key occurrences without full deserialization. If no duplicate keys are detected, pass the output through unchanged. If duplicates are found, construct the prompt with the full raw JSON string as [INPUT_JSON] and the chosen strategy (MERGE_VALUES, KEEP_LAST, KEEP_FIRST, or FLAG_CONFLICT) as [RESOLUTION_STRATEGY]. The model returns a JSON object with two fields: resolved_json (the clean single-key object) and merge_audit (an array of objects documenting each duplicate key, the conflicting values, and the resolution action taken). Validate the response by confirming resolved_json parses without errors and contains no duplicate keys. If validation fails, retry once with the validation error message appended as additional context. After two failures, log the incident and route to a human review queue rather than looping indefinitely.

For model choice, prefer a fast, instruction-following model with strong JSON output discipline—GPT-4o-mini or Claude 3.5 Haiku work well for this bounded task. Set temperature=0 to maximize deterministic behavior, since duplicate key resolution should follow the stated strategy consistently. The merge_audit field is critical for observability: persist it alongside the resolved JSON so that downstream consumers and auditors can see exactly what the repair stage changed. In high-stakes pipelines (financial records, healthcare data, legal documents), require a human to approve any resolution where FLAG_CONFLICT was the strategy or where the audit shows value-level conflicts that couldn't be cleanly merged. Never silently drop conflicting data without an audit trail.