Narrative Response to Typed Record Prompt Template

This prompt is a post-generation repair step for API developers and data pipeline engineers who receive prose or narrative text from a model when they expected structured JSON. Instead of discarding the response or writing brittle regex, use this prompt to extract typed objects, normalize enums, and flag low-confidence fields. It belongs in a repair loop that activates after primary structured output generation fails validation—not as your first attempt at getting structured data.

The ideal user has already attempted schema-first prompting or function calling and received a correct but unstructured answer. For example, a model might return 'The user's name is Jane Doe, ID 44521, status active' instead of {"name": "Jane Doe", "id": 44521, "status": "active"}. This prompt converts that narrative into a valid application payload with field-level confidence flags, enum normalization (e.g., 'active' → ACTIVE), and type coercion. It requires you to supply the expected output schema, the raw narrative text, and any domain-specific enum mappings or constraints.

Do not use this prompt as your primary structured output strategy. Prefer schema-first prompting, function calling with strict JSON mode, or tool-use APIs for initial generation. Reserve this prompt for repair loops where validation has already failed, the model's answer is semantically correct, and the cost of re-generation is higher than the cost of extraction. In high-risk domains such as finance, healthcare, or legal, always route low-confidence extractions to human review rather than silently accepting repaired output. Wire this prompt into your application with a validation gate, a retry budget, and structured logging that tracks how often repair was needed—high repair rates signal that your primary generation strategy needs improvement.

This prompt template is designed for the repair step in your pipeline—when a model returns prose, markdown, or a semi-structured blob instead of the JSON object your application expects. It forces the model to extract, normalize, and type every field against a schema you define, and to flag any value it cannot confidently resolve. Use this when a primary structured-output generation attempt has failed and you need a reliable fallback that produces a machine-readable payload.

textCopy
You are a strict data extraction engine. Your only job is to convert the provided narrative text into a single, valid JSON object that matches the output schema exactly.

## INPUT NARRATIVE
[INPUT]

## OUTPUT SCHEMA
You must produce a JSON object with exactly these fields. Do not add, omit, or rename any field.
[OUTPUT_SCHEMA]

## EXTRACTION RULES
1. For each field in the schema, locate the corresponding value in the narrative. If the value is present, extract it and coerce it to the correct type.
2. If a value is ambiguous, choose the most likely interpretation and set a `confidence` flag for that field to `"low"`.
3. If a value is entirely missing from the narrative, set the field to `null` and set its `confidence` flag to `"absent"`.
4. Normalize all enums to the exact values listed in the schema. If the narrative uses a synonym, map it to the canonical enum value and set `confidence` to `"medium"`.
5. Normalize all dates to ISO 8601 format (YYYY-MM-DD). If only a partial date is available, use the earliest possible date in the implied range and set `confidence` to `"low"`.
6. Do not invent, infer, or hallucinate any value not supported by the narrative text.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Return ONLY a valid JSON object. Do not wrap it in markdown code fences. Do not include any explanatory text before or after the JSON. The JSON object must have this structure:
{
  "record": { ... },
  "field_confidence": {
    "field_name": "high" | "medium" | "low" | "absent"
  }
}

To adapt this template, replace [INPUT] with the raw narrative text your model produced. Replace [OUTPUT_SCHEMA] with a JSON Schema fragment or a plain-text description of each field, its type, and its allowed enum values. Use [CONSTRAINTS] to add domain-specific rules—for example, 'amount must be a positive number with two decimal places' or 'status must be one of: active, pending, closed.' After the prompt runs, validate the output against your schema in application code before accepting it. If the field_confidence map shows any absent or low flags for required fields, route the record for human review or log it for later inspection.

The Narrative Response to Typed Record prompt is a repair tool, not a primary generation prompt. It should be invoked only when your primary model fails to produce valid structured output and returns prose, markdown, or semi-structured text instead. The harness described here assumes you have already attempted structured generation (e.g., JSON mode, function calling, or strict schema instructions) and received a non-conforming response. Do not use this prompt as your first attempt at structured output—it is a recovery mechanism for production pipelines where retrying the primary model is too costly or has already failed.

Wire this prompt into a post-generation validation pipeline. Call the primary model, validate its output against your expected schema, and on failure, invoke this repair prompt with the raw response as [NARRATIVE_INPUT]. Parse the repair output as JSON, validate field types and required field presence, and check the _confidence flags. If any required field has _confidence below 0.7, route the record for human review. Log every repair invocation with the original output, the repaired record, and the confidence scores for observability. Set a maximum of one repair attempt per record to avoid infinite loops. For high-throughput pipelines, batch narratives and process asynchronously.

Model choice matters for repair reliability. Use a model with strong instruction-following and JSON output capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid smaller or older models that may hallucinate fields not present in the narrative or fail to respect the output schema. If your pipeline processes sensitive data, ensure the repair model runs in the same trust boundary as your primary model and that narratives do not contain PII that would violate data residency requirements. The repair prompt itself includes confidence flags, but you should also implement independent validation: check that extracted values appear in or are reasonably inferred from the source narrative, verify enum values match your allowed set, and confirm numeric fields parse correctly.

Observability is critical because repair is a fallback path that masks upstream failures. Log the following for every repair invocation: the original model output that triggered repair, the full repaired JSON record, per-field confidence scores, and whether the record passed or was routed to human review. Use structured logging so you can query repair rates by endpoint, model version, or schema. If repair rates exceed 5% of requests, investigate your primary prompt's structured output instructions or consider switching to a model with native structured output support. High repair rates indicate a systemic problem, not a normal operational condition.

For human review routing, build a simple queue or flagging mechanism. Records with low-confidence required fields should be surfaced with the original narrative, the repaired record, and the specific fields that failed the confidence threshold. Reviewers should be able to accept, correct, or reject the repair. Track reviewer corrections to improve your schema descriptions, field definitions, and few-shot examples in the primary prompt. Over time, patterns in human corrections will reveal where your extraction logic is weakest—use this data to refine both your primary generation prompt and your repair prompt's instructions.