Nested Object Array Prompt for Complex Schemas

Use this prompt when your application requires an LLM to generate an array of records where each record contains nested objects, arrays of sub-objects, optional branches, and multiple levels of depth. This is the correct tool when your target schema includes constructs like user.addresses[].geo.lat or order.line_items[].discounts[].code—structures where a missing field three levels deep will break downstream JSON Schema validation, database inserts with nested JSON columns, or configuration generators that expect complete, deeply structured output. The prompt is designed to enforce field presence at every level, propagate null values according to explicit rules, and populate defaults so that no record arrives with a mismatched type or a missing required sub-field.

The ideal user is a backend engineer, API developer, or AI platform engineer integrating model outputs directly into a production pipeline. You should have a well-defined JSON Schema or TypeScript interface that describes the target structure, including required fields, nullable properties, and default value maps. The prompt template expects placeholders for [OUTPUT_SCHEMA], [DEFAULT_VALUE_MAP], and [NULL_PROPAGATION_RULES]—these are not optional. If you cannot provide a complete schema with nesting rules, the model will guess at the structure, and the output will be unreliable. This prompt also assumes you have a validation harness ready to check every record against the schema before the data enters your system of record.

Do not use this prompt for flat record lists or simple key-value pairs. If your schema has only one level of nesting—for example, an array of objects where every field is a scalar—use the Strict Schema Array Prompt for API Payloads instead. If you need to extract structured data from unstructured text like invoices or contracts, use the JSON Array Extraction Prompt for Unstructured Documents, which includes confidence scores and source citation. This prompt is also not suitable for streaming partial JSON chunks; for that, see the Streaming JSON Array Chunk Prompt for Real-Time Output. Finally, if your use case involves generating synthetic data with controlled statistical distributions rather than deterministic schema compliance, the Bulk Record Generation Prompt for Synthetic Data is a better fit.

This prompt template is the core instruction set you'll send to the model. It is designed to produce a single, valid JSON array where every element—and every nested object or array within those elements—conforms to a strict, user-provided schema. The prompt explicitly instructs the model to act as a recursive validator, checking types, required fields, enum constraints, and null propagation rules at every level of the object tree before writing the final output. Use this template as your starting point; replace the square-bracket placeholders with your specific schema, defaults, and context to create a production-ready prompt.

textCopy
You are a precise data generation engine. Your sole task is to produce a single, valid JSON array of objects based on the provided context and constraints. You must act as a recursive schema validator during generation.

## OUTPUT SCHEMA
You must generate a JSON array where every element conforms to the following schema. Validate every field, nested object, and nested array recursively against these rules before outputting.

[OUTPUT_SCHEMA]

## DEFAULT VALUES
If a field is missing from the input context but is required by the schema, you must populate it with the default value specified below. If no default is specified for a required field, use `null` and set the `"_validationStatus"` for that record to `"MISSING_REQUIRED"`.

[DEFAULT_VALUE_MAP]

## INPUT CONTEXT
Generate the array using the following information. If the context is insufficient to populate a required field and no default is provided, follow the null propagation rule above.

[INPUT_CONTEXT]

## CONSTRAINTS
- Output ONLY the raw JSON array. Do not wrap it in markdown code fences or add any explanatory text.
- Every object in the root array must be a valid JSON object.
- Recursively check all nested objects and arrays for schema compliance.
- For any field with an `enum` constraint, you must choose a value ONLY from the provided list.
- Do not coerce types. A string field must never contain a number.
- If the schema defines a field as `"nullable": false`, you must not output a `null` value for that field.
- Add a top-level `"_validationSummary"` object to the output array containing a `"totalRecords"` count and an array of `"errors"` for any records that failed validation.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing [OUTPUT_SCHEMA] with your complete JSON Schema definition. This is non-negotiable; the model's ability to perform recursive validation depends on a precise, machine-readable contract. Next, populate [DEFAULT_VALUE_MAP] with a JSON object mapping field paths (e.g., "address.street") to their default values. This map is your primary tool for controlling null propagation and ensuring downstream type safety. The [INPUT_CONTEXT] placeholder should be replaced with your source data, which could be a list of entities, a set of documents, or a structured brief. Finally, set the [RISK_LEVEL] to "LOW", "MEDIUM", or "HIGH". For "HIGH" risk, you must implement a human review step in your harness before any generated data enters a system of record. The _validationSummary object in the output is your first line of defense; always log it and set up an alert if the "errors" array is not empty.

The Nested Object Array Prompt is designed for high-stakes integration points where a malformed object deep inside an array can silently corrupt a downstream database or break an API contract. The implementation harness must treat the prompt as a component within a larger validation and retry loop, not as a standalone text generator. The primary job of the harness is to enforce the target JSON Schema at every nesting level, ensuring that optional branches are correctly populated or omitted, nulls propagate according to explicit rules, and default values are applied before the data reaches any consuming service.

Wire the prompt into an application function that accepts a strict JSON Schema definition as a required parameter. Before calling the model, construct the prompt by injecting the schema, a set of [DEFAULT_VALUE_RULES], and a [NULL_PROPAGATION_POLICY] into the template. After receiving the model's response, immediately parse the output with a streaming JSON parser to catch syntax errors early. Then, validate the entire array against the provided schema using a library like ajv (JavaScript) or jsonschema (Python). Do not rely on the model's claim of validity. If validation fails, classify the error: for type mismatches or missing required fields, execute a targeted retry by appending the specific validation error messages to the prompt context. For structural failures like incorrect nesting depth, increase the temperature slightly and retry once before falling back to a simpler, flattened schema. Log every validation failure, the retry count, and the final schema compliance status to your observability platform for drift detection.

For high-risk domains such as finance or healthcare, insert a mandatory human review step before the validated array is committed to a system of record. The harness should serialize the validated output, attach the schema, the validation report, and any retry logs into a review packet. Only after explicit approval should the data flow into a database insert or API response. Avoid the temptation to silently drop invalid records; instead, quarantine them into a dead-letter queue with the original prompt context for later debugging. This ensures that the system degrades gracefully and that every record in your production database has a verifiable audit trail back to the model's generation step.