Array Validation-Aware Prompt Template with Error Objects

This prompt is designed for AI platform engineers and backend developers building self-validating generation pipelines that must produce arrays of homogeneous records. The core job-to-be-done is generating a bulk record set where every record is accompanied by a validation status, a structured error object for records that fail schema checks, and actionable fix suggestions. This is not a simple list generation prompt; it is a production-grade template for systems that must handle partial success gracefully, allowing a downstream application to ingest valid records immediately while routing invalid records to a repair queue or human review step.

Use this prompt when your pipeline must survive schema violations without failing the entire batch. Ideal scenarios include bulk data ingestion from user uploads, ETL processes where source data quality is unpredictable, and API endpoints that must return a mix of valid and invalid records with clear error provenance. Required context includes a strict target schema (preferably a JSON Schema), a set of validation rules, and a definition of what constitutes a repairable versus non-repairable error. The model is expected to self-evaluate its own output against the provided schema and produce an errors array for each record, containing field, message, severity, and fix_suggestion keys.

Do not use this prompt when you need a simple, flat array of records with no error handling, or when downstream systems cannot process a mixed response payload. If your application layer already has robust validation and repair logic, embedding this logic in the prompt adds token overhead and latency without benefit. Similarly, avoid this prompt for real-time, low-latency streaming scenarios where the self-validation step introduces unacceptable delay. For high-risk domains such as finance or healthcare, the generated error objects and fix suggestions must be treated as advisory only; a human reviewer or a deterministic post-processing validator must confirm every repair before data is committed to a system of record.

This template is designed for AI platform engineers building self-validating generation pipelines where partial success is expected. Instead of failing the entire batch when some records don't conform, the prompt instructs the model to produce a structured envelope containing both valid records and detailed error objects for invalid ones. This enables retry targeting, downstream quarantine logic, and audit trails without losing the records that did pass validation.

textCopy
You are a structured data generator operating in a validation-aware pipeline. Your task is to produce an array of records from the provided [INPUT] that conform to the target schema defined in [OUTPUT_SCHEMA]. Not all input items may be valid or complete. For each record, you must assess whether it passes schema validation and include that assessment in your output.

## Output Envelope
Return a single JSON object with the following structure:
{
  "records": [],
  "errors": [],
  "summary": {
    "total_processed": 0,
    "total_valid": 0,
    "total_invalid": 0
  }
}

## Records Array
Each element in `records` must conform exactly to [OUTPUT_SCHEMA]. Only include records that pass validation. Do not include partial or repaired records here unless [REPAIR_MODE] is set to `true`.

## Errors Array
For each input item that fails validation, include an error object in the `errors` array with:
- `index`: the zero-based position of the failed item in the input
- `input_snippet`: a truncated representation of the failed input for traceability
- `validation_errors`: an array of specific field-level failures, each containing:
  - `field`: the field path that failed (use dot notation for nested fields, e.g., "address.zip")
  - `rule`: the validation rule that was violated (e.g., "required", "type_mismatch", "enum_violation", "pattern_mismatch")
  - `expected`: what the schema requires
  - `received`: what the input provided (or "null" if missing)
- `fix_suggestion`: a human-readable suggestion for how to correct the record, or "cannot_suggest" if the input is too ambiguous
- `retry_priority`: one of [HIGH, MEDIUM, LOW] indicating whether this record is likely fixable with a targeted retry

## Validation Rules
Apply the following checks in order, stopping at the first failure for each field:
1. Required field presence: all fields listed in [REQUIRED_FIELDS] must exist and not be null
2. Type conformance: each field must match the type specified in [OUTPUT_SCHEMA] with no coercion
3. Enum constraints: fields restricted to [ENUM_VALUES] must contain only allowed values
4. Pattern constraints: fields with [PATTERN_RULES] must match the specified regex
5. Custom constraints: apply any additional rules in [CUSTOM_VALIDATION_RULES]

## Constraints
- Do not invent data to fill missing required fields unless [DEFAULT_MAP] is provided and the field is listed there
- Do not coerce types: "123" is a string, not an integer
- If [RISK_LEVEL] is HIGH, flag any record where you have less than [CONFIDENCE_THRESHOLD] confidence in the extraction as invalid
- Preserve the original input ordering in the errors array
- The `records` array may be empty if no input items pass validation
- The `errors` array may be empty if all input items pass validation

## Input
[INPUT]

## Output Schema
[OUTPUT_SCHEMA]

## Examples
[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your specific configuration. [OUTPUT_SCHEMA] should contain your target JSON Schema or a plain-text description of field names, types, and constraints. [REQUIRED_FIELDS] should list the fields that cannot be null or absent. [ENUM_VALUES] should map field names to their allowed value sets. [PATTERN_RULES] should specify regex patterns for fields like emails or phone numbers. [CUSTOM_VALIDATION_RULES] can include business logic checks such as "end_date must be after start_date." [DEFAULT_MAP] is optional but useful when you want the model to populate safe defaults for missing optional fields rather than flagging them as errors. [EXAMPLES] should include at least one valid record and one error object to anchor the model's output shape. [REPAIR_MODE] controls whether the model attempts to fix minor issues (like whitespace normalization) and include repaired records in the records array. Set [RISK_LEVEL] to HIGH for regulated domains where false positives in the valid set are unacceptable; this activates the confidence threshold check. [CONFIDENCE_THRESHOLD] should be a value between 0.0 and 1.0 that reflects your tolerance for extraction uncertainty.

Before deploying this prompt, test it with inputs that include at least one fully valid record, one record with a missing required field, one with a type mismatch, and one with an enum violation. Verify that the error objects contain actionable fix_suggestion values and correct retry_priority assignments. In production, always validate the output envelope structure before processing the records array—a malformed envelope should trigger a full retry, not partial ingestion. Wire the errors array into a retry queue that can feed individual failed records back through a repair prompt or a human review interface.

This prompt is designed for a self-validating generation pipeline where the model produces both an array of records and a parallel array of error objects. The implementation harness must treat the model's output as a candidate payload, not a trusted result. After receiving the response, the application layer should parse the JSON, iterate over the records array, and cross-reference each record against its corresponding entry in the errors array using the shared index or record_id. Records with a valid: false flag or a non-empty errors object should be routed to a repair queue, while valid records proceed directly to the downstream system. This design allows partial success: a batch of 100 records where 7 fail validation can still deliver 93 clean records without blocking the entire pipeline.

Validation and Retry Logic: The harness must implement a strict post-processing validator that checks the model's output against the expected schema before trusting the model's self-reported valid flags. A common failure mode is the model marking a record as valid: true while the record still contains a type mismatch or missing required field. Your validator should re-validate every record against the target JSON Schema, regardless of the model's self-assessment. For records that fail, extract the fix_suggestion string from the error object and feed it back into a targeted retry prompt that includes only the failed record and its specific error context—not the entire batch. Limit retries to 2 attempts per record to avoid infinite loops. If a record still fails after retries, log it to a dead-letter queue with the full error object and original input for human review.

Model Choice and Tool Use: This prompt works best with models that have strong JSON mode or structured output capabilities (e.g., GPT-4o with response_format: { type: "json_object" }, Claude 3.5 Sonnet with tool use, or any model supporting constrained decoding). Do not rely on the prompt alone to enforce schema compliance—always pair it with a JSON Schema validator in your application code. For high-throughput pipelines, consider batching records into groups of 20–50 to balance context window usage against retry granularity. If your use case involves regulated data (finance, healthcare, legal), add a human review step for any record where the model's confidence score falls below a configurable threshold or where the error object indicates ambiguity. Log every generation with the prompt version, model ID, input hash, output payload, validation results, and retry count for auditability and prompt regression testing.