Conversion Prompt for Messy Model Responses

This prompt is designed for integration teams who are bridging two AI systems: an upstream model that produces unstructured or semi-structured text (prose summaries, bulleted lists, narrative descriptions) and a downstream application that requires a strict, typed schema. The core job-to-be-done is normalization. You already have the target information, but it is trapped in an unpredictable format that your database, API, or UI cannot ingest. This prompt acts as a translator, taking that messy text and forcing it into a predefined [OUTPUT_SCHEMA] while attaching a confidence score to each extracted field. The ideal user is a backend engineer or AI pipeline builder who needs to make two models talk to each other reliably without manual data entry.

Do not use this prompt for initial extraction from raw documents such as PDFs, images, or unprocessed web pages. That task requires a dedicated extraction prompt that can handle layout parsing, OCR noise, and long-context retrieval. This prompt assumes the source text already contains the target information but in an unpredictable format. It is also not a substitute for a validation or repair prompt; while it includes confidence annotations, it does not perform schema repair on its own output. If the upstream model is prone to hallucinating fields that were never present in the source, this prompt will not prevent that—it will only flag low confidence. For high-stakes domains like finance or healthcare, always pair this prompt with a downstream validation step and human review before ingestion.

Before using this prompt, ensure you have a well-defined [OUTPUT_SCHEMA] with explicit types, nullability rules, and enum constraints. The prompt works best when the schema is unambiguous and the source text is a single coherent block. If the source text is extremely long or contains multiple entities, consider chunking it first. After implementing, test for the two most common failure modes: hallucinated fields (where the model invents data not present in the source) and dropped entities (where valid information is silently omitted). Your eval suite should measure both precision and recall against a golden dataset of messy inputs paired with their correct structured outputs.

This prompt template is designed to sit in the system or developer message of your API call. It instructs the model to act as a structured data extraction layer, consuming the raw, potentially malformed output of a previous model call and converting it into a clean, predictable JSON payload. The core job is to bridge the gap between a fluent but unstructured generation and a downstream parser, database, or API that requires a strict contract. Use this when you have a 'messy' source—like a prose summary, a bulleted list, or a semi-structured log—and you need to reliably extract specific fields, entities, and their relationships.

Below is the copy-ready template. It uses square-bracket placeholders for all dynamic inputs. The [INPUT] placeholder receives the messy text. The [OUTPUT_SCHEMA] placeholder should be replaced with a detailed JSON schema definition, including field names, types, descriptions, and constraints. The [CONSTRAINTS] placeholder allows you to inject specific rules, such as enum values, date formats, or required fields. The [EXAMPLES] placeholder is for few-shot demonstrations of the conversion task, which is critical for handling ambiguous cases. The [RISK_LEVEL] placeholder should be set to 'high', 'medium', or 'low' to control the model's behavior around uncertainty and the use of the confidence field.

textCopy
You are a precise data extraction and normalization engine. Your sole function is to convert the provided input text into a structured JSON object that strictly conforms to the specified output schema.

## Input Text
[INPUT]

## Output Schema
You must produce a single JSON object that matches this schema exactly. Do not include any keys that are not defined here. If a required field's value cannot be determined, use `null`.
[OUTPUT_SCHEMA]

## Constraints
Adhere to the following rules without exception:
[CONSTRAINTS]

## Confidence Annotation
For every extracted field, you must include a `confidence` score between 0.0 and 1.0 in a parallel `_confidence` object. A score of 1.0 means the value was explicitly stated. A score of 0.0 means the value is a complete guess or was filled with a default. If the [RISK_LEVEL] is 'high', you must also include a `rationale` string for any field with a confidence score below 0.9.

## Examples
Follow the pattern demonstrated in these examples:
[EXAMPLES]

## Final Instruction
Output only the valid JSON object. Do not wrap it in markdown code fences or add any explanatory text before or after the JSON.

To adapt this template for production, start by hardening the [OUTPUT_SCHEMA]. Define every field with a JSON Schema-like precision, specifying type, description, and any enum restrictions directly in the prompt text. For the [CONSTRAINTS] section, explicitly state rules like 'dates must be in ISO 8601 format' or 'currency values must be numbers without symbols.' The [EXAMPLES] section is your most powerful lever for improving accuracy; include at least one example where a field is missing from the input and the output correctly uses null with a low confidence score. Before deploying, run this prompt against a golden dataset of 50-100 messy inputs and validate the output JSON against your application's schema. Log any instance where the model hallucinates a field not in the schema or drops a required entity, as these are the primary failure modes to monitor.

This prompt is designed to sit inside a post-processing pipeline, not as a standalone chat interaction. After your primary model produces a messy response (prose, bullet lists, semi-structured text), feed that output into this conversion prompt along with your target schema. The prompt acts as a structured extraction layer that normalizes the unstructured input into a predictable JSON contract. Treat this as a deterministic transformation step: same input schema, same output contract, every time.

Validation is mandatory before the output reaches any downstream system. Parse the model's JSON response and validate it against your target schema immediately. Check for missing required fields, type violations (string where number expected), and enum mismatches. If validation fails, do not silently accept the output. Instead, construct a retry payload that includes the original messy text, the target schema, and the exact validation error message. Feed this back to the model with a retry instruction like: 'The previous output failed validation with the following errors: [ERRORS]. Produce a corrected JSON object that satisfies the schema.' Implement a retry budget of 2-3 attempts. If the output still fails after the budget is exhausted, log the failure, capture the partial output, and escalate to a human review queue or a fallback structured output path.

Pay close attention to the confidence annotations the prompt is instructed to produce. Each extracted field should include a confidence score. Your application harness should define a threshold (e.g., 0.7) below which a field is flagged for human review. Do not silently accept low-confidence extractions for high-stakes fields like monetary amounts, identifiers, or legal entities. For fields flagged as low confidence, either route the entire record to a review queue or present the uncertain field to a human operator with the original source text for verification. Log every conversion attempt—including the raw input, the model's output, validation results, retry count, and final confidence scores—to build an audit trail and enable prompt debugging over time.

Model choice matters here. This prompt benefits from models with strong instruction-following and structured output capabilities. If your primary model is a smaller or less capable model that produced the messy output, consider routing this conversion step to a more capable model (e.g., a frontier model with strong JSON mode). The conversion step is a reliability checkpoint, not a cost-optimization opportunity. If you must use the same model tier, enable structured output mode (JSON mode, function calling with a schema) rather than relying solely on the prompt text to enforce format. Finally, never expose the raw conversion output to end users without validation—this prompt is infrastructure, not a user-facing feature.