Required Field Enforcement Prompt for JSON Schema

This prompt is for prompt architects and platform engineers who need to guarantee that a language model's JSON output contains every required field defined in a target schema. Use this prompt when downstream systems will reject payloads with missing keys, when null values in required fields are unacceptable, and when you need the model itself to perform the validation check before responding. This prompt embeds the required field list, type constraints, and cross-field rules directly into the generation instructions. It is designed for pipelines where output validity is non-negotiable and where a post-generation repair loop is either too slow or too expensive.

The ideal user has a concrete JSON Schema or a well-defined record contract and can enumerate every required field, its expected type, and any cross-field dependencies. The prompt works best when the model has sufficient context from the provided [INPUT] and [CONTEXT] to populate all required fields. In production, you should pair this prompt with a deterministic post-validation step that checks for key presence, correct types, and non-null values before the payload reaches any downstream system. Log every validation failure with the raw model output and the specific missing or invalid fields to drive prompt iteration.

Do not use this prompt for open-ended creative generation, for schemas with hundreds of optional fields where strictness harms recall, or when the model lacks the context to populate every required field from the provided input. If the input data is incomplete, the model may hallucinate values to satisfy the requirement, which is worse than a missing field. In those cases, prefer a schema with optional fields and a separate completeness check, or route incomplete records to a human review queue. For high-risk domains such as finance, healthcare, or legal workflows, always require human approval on outputs where required fields were populated with low-confidence inferences.

This prompt template is designed to be pasted directly into your system instructions or as the first user message in a conversation. It instructs the model to treat the provided JSON Schema as a strict contract, ensuring that every required field is present, populated with the correct type, and non-null where specified. The template uses square-bracket placeholders that you must replace with your specific schema, input data, and operational constraints before sending.

textCopy
You are a structured data extraction engine. Your sole task is to produce a single, valid JSON object that strictly conforms to the provided JSON Schema. You must not include any explanatory text, markdown fences, or conversational filler outside the JSON object.

### OUTPUT SCHEMA
You must generate output that validates against this exact JSON Schema:
```json
[OUTPUT_SCHEMA]

CRITICAL RULES

1. Required Fields: Every field listed in the schema's required array MUST be present in your output.
2. Non-Null Constraints: If a field is required, its value MUST NOT be null. If a field is optional but present, it should conform to its defined type.
3. Type Strictness: You must match the exact type specified for each property (e.g., "string", "integer", "number", "boolean", "array", "object"). Do not use a string where a number is expected.
4. Enum Adherence: If a field has an enum constraint, the value MUST be one of the listed options exactly.
5. No Additional Properties: Unless the schema explicitly sets additionalProperties to true, do not invent new fields.
6. Missing Information: If the [INPUT] does not contain information for a required field, you must use a sensible, type-correct default value as specified in [DEFAULT_RULES] rather than omitting the field or using null.

INPUT DATA

[INPUT]

DEFAULT VALUE RULES

[DEFAULT_RULES]

CROSS-FIELD VALIDATION

[CROSS_FIELD_RULES]

To adapt this template, replace [OUTPUT_SCHEMA] with your complete JSON Schema definition. The [INPUT] placeholder should be replaced by the source text or data the model needs to parse. Crucially, you must define [DEFAULT_RULES] to instruct the model on how to handle genuinely missing data for required fields—for example, "use an empty string for missing names" or "set quantity to 0 if not found." The optional [CROSS_FIELD_RULES] section allows you to embed logic that spans multiple fields, such as "if status is 'shipped', then tracking_number is required." After pasting, test the prompt with inputs that are missing required data to ensure the default rules and validation logic produce a valid object every time.

To use this prompt in a production pipeline, wrap it in a validation loop that treats the model's JSON response as untrusted input until proven otherwise. After sending the prompt to the model, parse the JSON response and validate it against [JSON_SCHEMA] using a server-side JSON Schema validator such as ajv (JavaScript) or jsonschema (Python). This validation must check that every required field is present, non-null where specified, and correctly typed. Do not rely on the model's self-reported compliance; always validate programmatically. For high-throughput pipelines, cache the compiled schema validator function and run it synchronously before the response is returned to the client, so invalid outputs never reach downstream systems.

When validation fails, log the specific missing fields, type mismatches, and null violations along with a hash of the input and the full model response for prompt debugging. Then decide whether to retry or escalate. For retries, append the validation error message to the original prompt and resubmit, giving the model a concrete description of what was wrong. Set a maximum retry count of 2 to avoid infinite loops on genuinely unanswerable inputs. If both retries fail, route the request to a human review queue with the input, the failed responses, and the validation errors attached. This pattern prevents silent data corruption while keeping latency predictable for the majority of requests that succeed on the first attempt.

For observability, instrument every validation failure with structured log entries that include the input hash, the missing or invalid fields, the retry count, and whether the request ultimately succeeded, failed permanently, or was escalated. This data is essential for identifying prompt weaknesses, such as fields the model consistently omits under certain input conditions. Use these logs to refine the prompt's field descriptions, add stronger constraint language, or adjust the schema itself. Avoid the temptation to silently default missing fields in application code; doing so masks prompt failures and makes it impossible to distinguish between intentional nulls and generation gaps. Instead, treat every validation failure as a signal that the prompt or schema needs attention.