This prompt is for backend engineers and data pipeline builders who need model-generated JSON with guaranteed type consistency at every depth. Use it when downstream systems cannot tolerate a string where an integer is expected inside a nested object, or when an array of objects suddenly contains a bare string. The template enforces type contracts recursively through nested objects and array elements, preventing mixed-type arrays, malformed sub-objects, and depth-level type drift. It assumes you already have a target schema and need the model to produce output that survives automated validation before ingestion.

The ideal user has a defined JSON Schema or a strict type specification and needs to integrate model output directly into a typed application (e.g., a Go struct, a Rust serde model, a TypeScript interface, or a database insert). Required context includes the full target schema, example valid payloads, and a list of common failure patterns you've observed (e.g., 'the model sometimes returns a string for the count field inside nested objects'). The prompt works best when you provide explicit type rules for each field at every nesting level, not just a top-level schema reference. Include negative examples showing invalid outputs that must be rejected—this dramatically reduces type coercion errors.

Do not use this prompt when you need the model to infer or generate the schema itself, when the output format is primarily free-text with occasional structured fields, or when the schema is so large that it consumes the majority of the context window. For dynamic schema generation, use a schema-inference prompt. For hybrid text-and-JSON outputs, use a structured extraction prompt with a looser contract. If your schema exceeds roughly 60% of the available context window, consider splitting the generation into multiple calls or using a fine-tuned model that has internalized the schema. Also avoid this prompt when you need the model to creatively fill in missing fields with plausible values—this template is for strict type enforcement, not data imputation.

This prompt template is designed for backend engineers who need to guarantee that every element in a complex, nested JSON structure adheres to a strict type contract. It moves beyond flat field validation to enforce type consistency recursively through arrays and sub-objects. The core instruction forces the model to treat the provided schema as a non-negotiable contract, explicitly rejecting common failure modes like mixed-type arrays (e.g., [123, "abc"]), missing required sub-objects, or incorrect nesting depth. Use this when downstream systems will break on type mismatches, not just missing fields.

markdownCopy
You are a strict JSON generator. Your output must be a single, valid JSON object that conforms exactly to the [SCHEMA] provided below. You will be given [INPUT_DATA] to structure.

# CRITICAL CONTRACT
1.  **Recursive Type Enforcement:** Every field, sub-object, and array element must match the type defined in [SCHEMA]. If [SCHEMA] says an array contains `integer`, every element in that array must be an integer. No mixed-type arrays.
2.  **Nested Object Integrity:** Every nested object must include all its `required` fields as defined in [SCHEMA]. Do not flatten, omit, or add extra fields to nested objects.
3.  **Depth Awareness:** Maintain the exact object nesting depth specified in [SCHEMA]. Do not add or remove levels of hierarchy.
4.  **Null Handling:** Only output `null` for a field if the [SCHEMA] explicitly allows a `null` type for that field. Otherwise, an absent value must result in the omission of the field if it is not required, or a type-appropriate default if one is specified in [CONSTRAINTS].
5.  **No Schemaless Blocks:** Do not output any JSON that falls outside the [SCHEMA] definition. If data from [INPUT_DATA] doesn't fit, follow the [CONSTRAINTS] for handling missing or extra data.

# SCHEMA
```json
[SCHEMA]

INPUT DATA

jsonCopy
[INPUT_DATA]

CONSTRAINTS

[CONSTRAINTS]

OUTPUT

Generate only the final JSON object. Do not include any explanatory text, markdown fences, or code block syntax before or after the JSON.

To adapt this template, replace the square-bracket placeholders with your specific context. [SCHEMA] must be a valid JSON Schema object defining the target structure, including types for all nested arrays and objects. [INPUT_DATA] should be the unstructured or semi-structured source data. Use [CONSTRAINTS] to define behavior for edge cases, such as: 'If a required field is missing from the input, use a type-appropriate default like an empty string or zero.' or 'If an array contains elements of the wrong type, omit the offending element.' Before integrating this into a production pipeline, pair it with a post-generation validation step that parses the output against the same [SCHEMA] and rejects any response that fails validation, triggering a retry or fallback.

This prompt is designed to be the final generation step before a structured output enters your data pipeline. It should be called after you have assembled the target schema, any source documents, and the extraction or transformation instructions. The prompt's job is to enforce type consistency recursively through nested objects and array elements, preventing mixed-type arrays, malformed sub-objects, and type coercion surprises that would break downstream consumers. In a production harness, treat this prompt as a type-guarantee layer—it does not perform the initial extraction or reasoning; it validates and corrects the structural integrity of an already-formed output.

The recommended implementation pattern is a validate-then-retry loop with a strict JSON Schema validator. After the model returns its response, parse the JSON and validate it against your target schema using a server-side validator (such as ajv for JavaScript/TypeScript, jsonschema for Python, or equivalent). If validation fails, collect the specific errors (e.g., instance path /items/0/price is string, expected number) and feed them back into the prompt's [PREVIOUS_ERRORS] placeholder along with the original [OUTPUT_SCHEMA] and the model's previous attempt. Limit retries to 2–3 attempts. If validation still fails after retries, log the full failure context—including the model, prompt version, schema, input, and validator errors—and escalate to a human review queue or a dead-letter topic. For high-throughput pipelines, consider using a cheaper, faster model (e.g., GPT-4o-mini, Claude Haiku) for the initial generation and only escalating to a more capable model (e.g., GPT-4o, Claude Sonnet) on retry.

Model choice matters for depth-aware enforcement. Smaller or older models may struggle with recursive schema validation beyond 3–4 levels of nesting. Test your prompt against schemas with the maximum expected depth and array cardinality before deploying. For schemas with discriminated unions (e.g., type field determining sibling shape), add explicit [CONSTRAINTS] that call out the discriminator logic and variant-specific required fields. Always include a [RISK_LEVEL] parameter in your harness: for low-risk pipelines (internal analytics, non-customer-facing), you may accept best-effort outputs with logged warnings; for high-risk pipelines (financial records, compliance data, customer-facing APIs), enforce strict validation with no fallback and mandatory human review on failure. Wire your observability stack to track schema validation pass rates, retry counts, and depth-related failure patterns so you can detect model drift or schema changes that break the prompt's effectiveness.