Missing Required Field Injection Prompt

This prompt is designed for integration engineers and backend developers who are building automated pipelines that consume structured output from a large language model. The specific job-to-be-done is to recover a valid payload when a downstream JSON Schema validator has rejected a model's response because a required field is absent. Instead of discarding the entire response or retrying the original, expensive generation task, this prompt surgically repairs the output by injecting the missing field. It uses the surrounding context of the provided data, the field's schema description, and explicit instructions to infer a plausible value or insert a typed null with a missing-field flag, strictly avoiding hallucination of unsupported data.

The ideal user is an engineer who has already implemented a validation layer (e.g., using Ajv, Pydantic, or a similar library) that can identify the exact path and reason for a schema violation. You should use this prompt when the cost or latency of a full regeneration is unacceptable, and the missing field can be reasonably inferred from the existing, valid data. For example, if a full_name field is missing but first_name and last_name are present, the injection is straightforward. It is also appropriate when a field has a sensible default defined in your business logic or schema, such as setting a missing status field to `

pending"`."

Do not use this prompt when the missing field is a critical, non-inferable piece of information that requires external evidence or user input, such as a unique transaction ID or a legal entity identifier. In these cases, injection would be hallucination. This prompt is also unsuitable for repairing fundamental semantic misunderstandings or multiple, cascading structural errors; a broader retry or a full Self-Correction Loop Prompt for Structured Output is more appropriate for those scenarios. The prompt is a precision instrument for a single, well-defined failure mode: a valid object that is missing one or more required keys.

Before wiring this into your application, you must define a clear [INFERENCE_RULES] map that links each potentially missing field to a safe inference strategy or an explicit null flag. The prompt's value is in its constraints: it is told to change nothing else in the payload and to always signal its actions. Your next step is to pair this prompt with a post-repair validation check to confirm the output is now schema-compliant, and to log every injection event for auditability and drift analysis.

This prompt template is designed to be invoked by an application harness immediately after a structured output validation step fails with a 'missing required field' error. Instead of asking the model to regenerate the entire payload from scratch—which risks introducing new errors or altering correct data—this prompt isolates the repair to the single missing field. It provides the model with the original partial output, the field definition from the schema, and the surrounding context to infer a value or safely insert a null flag.

textCopy
You are a structured output repair agent. Your task is to fix a single missing required field in a JSON object.

## INPUT
- Original Partial Output: [PARTIAL_OUTPUT]
- Target Schema for the missing field:
  - Field Name: [FIELD_NAME]
  - Description: [FIELD_DESCRIPTION]
  - Type: [FIELD_TYPE]
  - Constraints: [FIELD_CONSTRAINTS]
- Surrounding Context (the original prompt and any retrieved evidence used to generate the output): [SURROUNDING_CONTEXT]

## INSTRUCTIONS
1. Analyze the Surrounding Context to determine if a plausible value for the missing field can be inferred.
2. If a value can be inferred with high confidence, inject the field into the Original Partial Output at the correct location and set its value.
3. If no value can be inferred, inject the field with an explicit null value and add a sibling field named "[FIELD_NAME]_missing_flag" set to true.
4. Do not modify any other fields or values in the Original Partial Output.
5. Do not hallucinate data that is not supported by the Surrounding Context.

## OUTPUT FORMAT
Return ONLY the complete, valid JSON object with the missing field injected. Do not include any explanatory text outside the JSON.

To adapt this template, replace the square-bracket placeholders with data from your application's validation layer. [PARTIAL_OUTPUT] is the raw string that failed validation. [FIELD_NAME], [FIELD_DESCRIPTION], [FIELD_TYPE], and [FIELD_CONSTRAINTS] should be extracted directly from your JSON Schema, Pydantic model, or type definition. [SURROUNDING_CONTEXT] is critical for inference quality—include the user's original request and any RAG-retrieved documents, as this is the evidence the model uses to decide between inferring a value and flagging the field as missing. For high-risk domains, ensure the calling application logs the original output, the injected value, and the _missing_flag state for auditability. The next step after receiving the repaired output is to re-run your full schema validator to confirm the fix before forwarding the payload downstream.

The Missing Required Field Injection Prompt is designed to sit inside a structured output repair loop, not as a standalone prompt. It should be invoked only after a primary generation step has produced a payload that fails schema validation specifically due to absent required fields. The harness must first parse the raw validation errors to identify which fields are missing and extract the field definitions (type, description, constraints) from the target schema. These become the [MISSING_FIELDS] and [FIELD_SCHEMA] inputs to the injection prompt. Do not call this prompt for type mismatches, enum violations, or malformed syntax—those failures should route to the Data Type Mismatch Repair Prompt or JSON Schema Validation Retry Prompt instead.

A production-grade implementation requires a retry budget and an escalation path. Wrap the injection prompt in a loop that attempts repair up to a configurable maximum (typically 2–3 attempts). After each attempt, re-validate the repaired output against the full schema. If the output passes validation, return it with a repair_metadata object that records which fields were injected, the confidence level for each injection, and the attempt count. If validation still fails after the retry budget is exhausted, route the partial output and accumulated error context to the Escalation Threshold Prompt for Unrepairable Output to decide whether to salvage, request human review, or return a structured error to the caller. Log every injection decision—field name, injected value, confidence, and surrounding context—so operators can audit repair quality over time.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or very low (0.0–0.1) to minimize variance in injection decisions. If your application cannot tolerate any hallucinated field values, configure the prompt to inject explicit null with a missing_reason flag rather than inferring plausible values. For high-risk domains (healthcare, finance, legal), always require human review of injected fields before the payload is consumed downstream. Wire the injection prompt into your observability stack so that injection frequency, field-level confidence distributions, and escalation rates are visible on dashboards and trigger alerts if repair quality degrades after a model or schema change.