Malformed Contact JSON Repair Prompt Template

This prompt is for integration engineers and backend developers who receive contact records from an LLM that are semantically correct but structurally broken. The job-to-be-done is repairing a JSON payload that has failed downstream validation due to common model-generated errors: missing required fields, type mismatches (e.g., a phone number stored as an integer), nested structure corruption, or encoding artifacts. The ideal user has a known target schema for a contact object and needs a reliable, automated repair step before the data enters a CRM, CDP, or customer data platform. The required context is the malformed JSON string and the expected schema definition.

Use this prompt when a model's output is close to correct but fails a strict schema validator. It is designed for post-generation repair loops, not for initial structured output generation. If you need the model to produce valid JSON on the first attempt, use a schema-first prompting strategy from the Structured Output and Schema Control pillar instead. This prompt is appropriate when the cost of discarding the output is high, such as in batch processing pipelines where partial failure recovery is critical. It is not a substitute for fixing the root cause of malformed generation in your primary prompt.

Do not use this prompt for repairing outputs that contain hallucinated contact data. If the model invented names, emails, or phone numbers, this prompt will faithfully coerce them into a valid schema, creating a dangerous false positive. For hallucination issues, use the Contact Record Hallucination Detection Prompt Template from this pillar first. Additionally, if the malformed JSON contains PII that should not be logged or processed, ensure your pipeline redacts sensitive fields before they reach this repair step. The next section provides the copy-ready template you can adapt with your specific schema and coercion rules.

This prompt template is designed to be dropped into a repair loop after your primary model generates a contact JSON that fails validation. It accepts the broken payload, the expected schema, and a set of coercion rules, then returns a repaired object that conforms to your downstream contract. The template uses square-bracket placeholders so you can inject the specific inputs your application already has—no manual rewriting required.

textCopy
You are a contact record repair system. Your job is to take a malformed or invalid contact JSON object and repair it so that it strictly conforms to the provided schema and coercion rules.

## INPUT
[MALFORMED_JSON]

## EXPECTED SCHEMA
[EXPECTED_SCHEMA]

## COERCION RULES
[COERCION_RULES]

## CONSTRAINTS
- Do not invent or hallucinate values for fields that are missing and cannot be inferred from the input. Use null for missing optional fields and flag required fields that cannot be repaired.
- If a field value is present but has the wrong type, coerce it according to the coercion rules. If coercion is impossible, set the field to null and add an entry to the repair_log.
- Normalize all identifiers (email, phone, URL) according to the rules specified in the coercion rules.
- Remove any fields that are not present in the expected schema.
- If the input contains nested objects that should be flattened, flatten them according to the schema.
- If the input is truncated or contains encoding artifacts, repair what you can and flag what you cannot.

## OUTPUT FORMAT
Return a valid JSON object with exactly two top-level keys:
- "repaired_contact": the repaired contact object conforming to the expected schema
- "repair_log": an array of objects, each describing one repair action taken, with fields: "field", "original_value", "repaired_value", "action" (one of: coerced, defaulted, removed, inferred, could_not_repair), and "reason"

## EXAMPLES
[REPAIR_EXAMPLES]

Repair the input now.

Adapting the template: Replace [MALFORMED_JSON] with the broken payload your model produced. [EXPECTED_SCHEMA] should contain your target JSON schema with field names, types, and required/optional markers. [COERCION_RULES] is where you specify type conversion rules (e.g., "string to number: strip non-numeric characters and parse"), normalization rules for identifiers, and field-specific defaults. [REPAIR_EXAMPLES] should include 2-3 before/after pairs showing correct repair behavior for common failure modes in your pipeline. If your contact schema is large, consider splitting the coercion rules into a separate reference block and referencing it by name to keep the prompt manageable. Always test with at least 20 known-broken examples before wiring this into a production repair loop.

This prompt is designed to sit inside a post-generation repair loop, not as a standalone service. The typical integration pattern is: (1) receive a model-generated contact JSON payload, (2) validate it against your target schema, (3) if validation fails, invoke this repair prompt with the original payload and the validation error details, (4) validate the repaired output, and (5) either accept it, retry, or escalate. Do not call this prompt on every output—only on outputs that fail schema validation. This keeps latency and cost low for the majority of clean responses.

Validation harness: Before calling the repair prompt, run the raw output through a JSON schema validator (such as ajv for JavaScript, jsonschema for Python, or your API gateway's schema enforcement layer). Capture the specific validation errors—missing required fields, type mismatches, pattern violations, and unexpected keys. Pass these errors into the [VALIDATION_ERRORS] placeholder as structured text. The repair prompt uses these errors to target its fixes rather than guessing what's broken. After receiving the repaired output, run the same validator again. If the output still fails, increment a retry counter and include the new errors in the next repair attempt.

Retry and escalation logic: Implement a bounded retry loop—typically 2-3 attempts maximum. On each retry, include the accumulated validation errors and the previous repair attempt in the [PREVIOUS_ATTEMPTS] placeholder so the model can see what it already tried. If the output still fails after the retry budget, escalate to a human review queue rather than silently accepting a broken record. For high-volume pipelines, log the failure with the original payload, all repair attempts, and the final validation errors. This log becomes your dataset for improving the prompt or identifying systemic model failure patterns.

Model choice and temperature: Use a model with strong JSON generation and instruction-following capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 or very low (0.0-0.1) to maximize deterministic repair behavior. This is not a creative task—you want the model to apply mechanical fixes, not invent alternative contact representations. If your pipeline uses a smaller or faster model for initial generation, it's acceptable to route repair calls to a more capable model since repair volume should be a small fraction of total traffic.

Field coercion rules and safe defaults: The prompt includes a [COERCION_RULES] placeholder where you define how to handle ambiguous fields. For example: "If phone is a number type, convert it to a string with E.164 formatting. If email contains spaces, remove them. If name is null but first_name and last_name exist, construct name from the components." Define these rules based on your downstream system's tolerance. Never allow the model to invent missing required fields—if email is required and absent, the repair should flag it as null or a sentinel value like "MISSING_REQUIRED_FIELD" rather than guessing. Your application layer should decide whether to reject, enrich, or accept records with missing required fields.

Logging and observability: Instrument every repair call with the original payload hash, validation error count, repair attempt number, and final outcome (success, retry, escalation). This data feeds your prompt observability dashboard and helps you detect drift—for example, if repair rates suddenly spike from 2% to 15% of outputs, your upstream model or input data may have changed. Track the most common validation errors being repaired; if the same field breaks repeatedly, consider improving your initial generation prompt or adding pre-processing rather than relying on post-hoc repair.