Missing Required Field Injection Prompt Template

This prompt is for data pipeline operators and integration engineers who receive model outputs that are structurally valid but fail downstream ingestion because required fields are absent. The job-to-be-done is not to fix malformed JSON or correct wrong field names—it is to detect which required fields are missing from an otherwise correct payload and inject appropriate null, default, or computed values without disturbing the existing correct data. The ideal user has a target schema with explicit required-field definitions and needs an automated repair step that preserves an audit trail of every injected value.

Use this prompt when your model output passes structural parsing but fails schema validation specifically due to missing required fields. This is common in extraction pipelines where the model omits optional-looking fields that your database or API contract marks as NOT NULL, or when the model's output schema drifts from the downstream contract. The prompt requires three inputs: the model's output payload, the target schema with required-field annotations, and a default-value policy that specifies what to inject for each field type (null, empty string, zero, sentinel value, or a computed fallback). Do not use this prompt for repairing malformed JSON, fixing type mismatches, or removing hallucinated fields—those are separate repair workflows with different failure modes.

Before deploying this prompt into production, implement a pre-flight check that confirms the input payload is parseable and only contains missing-field errors. Wire the prompt into a validation-retry loop where schema validation runs first, the prompt fires only when required-field violations are detected, and the repaired output is re-validated before proceeding downstream. Log every injected field with its location, injected value, and timestamp to maintain an audit trail for debugging and compliance. For high-risk domains such as healthcare, finance, or legal workflows, require human review of the injection log before the repaired payload enters a system of record. The most common production failure mode is the prompt injecting values for fields that were intentionally absent due to conditional schema logic—mitigate this by including conditional field rules in your default-value policy.

The following prompt template is designed for data pipeline operators who need to repair model outputs that are missing fields required by a downstream contract. Instead of regenerating the entire payload, this prompt instructs the model to inject only the missing required fields with appropriate default, null, or computed values. The template uses square-bracket placeholders that you must replace with your specific schema, data, and constraints before use.

textCopy
You are a schema compliance repair agent. Your task is to repair a data record that is missing required fields.

## INPUT DATA
```json
[INPUT_DATA]

TARGET SCHEMA

jsonCopy
[TARGET_SCHEMA]

FIELD INJECTION RULES

For each field marked as required in the TARGET SCHEMA that is missing from the INPUT DATA:

1. If a default value is specified in the schema, use that default.
2. If no default is specified and the field type is string, inject an empty string "".
3. If no default is specified and the field type is number or integer, inject 0.
4. If no default is specified and the field type is boolean, inject false.
5. If no default is specified and the field type is array, inject an empty array [].
6. If no default is specified and the field type is object, inject an empty object {}.
7. If the field has an enum constraint, use the first allowed enum value.
8. If a computed value rule is provided in [COMPUTED_FIELDS], apply that rule instead.

COMPUTED FIELD RULES

jsonCopy
[COMPUTED_FIELDS]

CONSTRAINTS

• Do NOT modify, remove, or re-type any existing field that is already present and valid.
• Do NOT add fields that are not in the TARGET SCHEMA.
• Preserve the original values of all existing fields exactly as they appear.
• If a field exists but has the wrong type, flag it in the audit trail instead of silently coercing it.

OUTPUT FORMAT

Return a JSON object with exactly two keys:

• "repaired_record": the complete record with all required fields present.
• "injection_audit": an array of objects, each describing one injected field with keys: "field_name", "injection_reason" (one of: "default_value", "type_default", "enum_first", "computed"), "injected_value", and "rule_applied".

RISK LEVEL

[RISK_LEVEL]

If RISK_LEVEL is "high", also include a "requires_human_review" boolean field in each audit entry. Set it to true if the injected value could materially affect downstream processing.

To adapt this template, replace [INPUT_DATA] with the actual malformed record, [TARGET_SCHEMA] with your JSON Schema or a simplified field-requirement map, and [COMPUTED_FIELDS] with any business logic for derived values such as timestamps, IDs, or calculated totals. Set [RISK_LEVEL] to "high" for financial, healthcare, or compliance workflows where injected defaults must be reviewed before the record enters a system of record. Always validate the repaired record against your schema after the model responds, and log the injection audit trail for downstream observability.

This prompt is designed to sit directly after a schema validation failure in your data pipeline. When a downstream validator rejects a model output because required fields are missing, this prompt acts as a repair step—injecting null, default, or computed values for those missing fields while preserving all existing correct data. It should not be used as a general-purpose data enrichment step or to guess values the model intentionally omitted. The prompt's job is strict structural compliance, not semantic gap-filling.

Wire the prompt into your application as a post-validation repair handler. When a schema validator returns a list of missing required fields, construct the prompt's [MISSING_FIELDS] placeholder with that exact list and pass the original [MODEL_OUTPUT] alongside your [TARGET_SCHEMA]. The model will return a repaired JSON object. Immediately re-validate the output against the same schema. If validation fails again, log the failure, increment a retry counter, and either retry with a more explicit error message or escalate to a human review queue. For high-throughput pipelines, implement a circuit breaker: if the repair failure rate exceeds 5% over a rolling window, stop processing and alert the on-call engineer.

The [DEFAULT_VALUES] placeholder is your primary safety mechanism. Populate it with a dictionary mapping each required field to its safe default—use null for nullable fields, empty strings for optional text, zero for numeric counters, and explicit sentinel values like "UNKNOWN" for categorical fields that must never be silently wrong. Never let the model invent defaults. For computed fields like id or timestamp, provide a generation rule in [CONSTRAINTS] (e.g., 'generate a UUIDv4 for missing id fields' or 'set missing created_at to the current UTC ISO-8601 timestamp'). Log every injected value with the field name, injected value, and reason code (MISSING_REQUIRED) to your observability platform. This audit trail is essential for debugging downstream data quality issues and proving compliance to auditors.

Choose a model with strong JSON generation and instruction-following capabilities—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate. Avoid smaller or older models that may hallucinate field values or alter existing correct data. Set temperature=0 and use structured output modes (JSON mode or function calling) to enforce the output schema. If your pipeline processes sensitive data, run this repair step in a private deployment or use a data redaction layer before sending payloads to external model APIs. For regulated domains (healthcare, finance, legal), always route repaired outputs through a human approval step before they enter systems of record.

Test this harness with a golden dataset of intentionally incomplete outputs. For each test case, verify that: (1) all missing required fields are present in the repaired output, (2) no existing correct fields were modified, (3) injected values match the specified defaults, and (4) the output passes schema validation. Add regression tests for edge cases: empty objects, deeply nested missing fields, arrays of objects where some elements are missing fields, and outputs where the model previously hallucinated extra fields. The most common production failure mode is the repair model altering correct data while injecting defaults—your eval suite must catch this explicitly.