Schema Validation Pass/Fail Prompt

This prompt is for API developers and platform engineers who need a reliable, binary gate to enforce structured output contracts before a model response reaches downstream parsers, databases, or client applications. The job-to-be-done is strict schema conformance checking: given a JSON Schema and a model-generated payload, the prompt must return a definitive valid or invalid verdict with field-level error identification. It is designed for production CI/CD pipelines, release automation, and any system where a malformed JSON object is a hard failure, not a cosmetic issue.

Use this prompt when you have a known JSON Schema and need to catch type mismatches, missing required fields, enum constraint violations, or structural errors before they corrupt application state. The ideal user is an engineering lead or developer who already has a schema definition and wants to replace brittle regex or hand-written validators with an LLM-based check that can explain why a payload failed. You must provide the schema, the payload, and any additional constraints such as strict mode or coercion rules. Do not use this prompt for free-form quality evaluation, semantic correctness, or business logic validation—it is a format contract enforcer, not a content reviewer.

Before wiring this into a production harness, confirm that you have a well-defined JSON Schema and a clear policy for handling invalid outputs. The prompt works best as a pre-save or pre-response gate. If your application can tolerate partial outputs or needs to repair malformed JSON, pair this with an Output Repair prompt instead of relying on pass/fail alone. For high-risk domains where a false negative could cause data loss or regulatory exposure, always log the full validation trace and consider a human review step for edge cases involving ambiguous type coercion or schema version mismatches.

The following prompt template is designed to be copied directly into your application or evaluation harness. It accepts a JSON payload and a JSON Schema, then produces a structured verdict. The model acts as a strict schema validator, not a lenient interpreter. It must reject missing required fields, type mismatches, enum violations, and structural errors. Use this template when you need a deterministic, machine-readable pass/fail signal—not a human-friendly suggestion.

textCopy
You are a strict JSON Schema validator. Your job is to check whether the provided JSON payload conforms exactly to the provided JSON Schema. You must produce a binary pass/fail decision with field-level error identification.

## INPUT
JSON Payload to validate:
```json
[INPUT_PAYLOAD]

JSON Schema to validate against:

jsonCopy
[SCHEMA]

CONSTRAINTS

• Reject any payload that does not match the schema exactly.
• Flag missing required fields, incorrect types, values outside enum lists, pattern mismatches, and structural violations.
• Do not coerce types (e.g., string "123" is not integer 123).
• Do not ignore extra fields unless the schema explicitly allows additionalProperties.
• If the payload is not valid JSON, return a single error indicating the parse failure.

OUTPUT_SCHEMA

Return a JSON object with the following structure: { "valid": boolean, "errors": [ { "field": "string (JSON path to the invalid field, e.g., $.user.address.zip)", "constraint": "string (the schema rule violated, e.g., 'required', 'type', 'enum', 'pattern')", "expected": "string (what the schema requires)", "actual": "string (what the payload provided)" } ] }

If valid is true, errors must be an empty array.

To adapt this prompt, replace [INPUT_PAYLOAD] with the JSON string you need to validate and [SCHEMA] with your JSON Schema definition. For high-throughput production use, consider pre-parsing the payload to catch malformed JSON before calling the model—this saves tokens and latency. If your schema is large, place it in the system prompt or a cacheable prefix to reduce per-request cost. For regulated domains, always log the full prompt, response, and schema version to maintain an audit trail. When validation fails, route the error array to a repair prompt or a human review queue rather than silently discarding the payload.

The Schema Validation Pass/Fail Prompt is designed to sit directly behind an API endpoint or inside a data processing pipeline where structured output contracts must be enforced before downstream systems consume the payload. The prompt receives a JSON payload and a JSON Schema definition, then returns a binary valid/invalid verdict with field-level error identification. This harness is appropriate for synchronous validation gates in API gateways, asynchronous batch validation in ETL pipelines, and pre-commit checks in CI/CD workflows that generate structured data. Do not use this prompt as a substitute for deterministic JSON Schema validators when the schema is simple and the payload is machine-generated—traditional validators are faster, cheaper, and deterministic for that use case. Reserve this prompt for scenarios where the payload is AI-generated, human-written, or contains semantic ambiguities that require language understanding beyond structural validation, such as detecting when a null value means "intentionally absent" versus "forgotten field."

Wire the prompt into your application with a validation wrapper that handles three concerns: pre-processing, post-processing, and fallback. In the pre-processing layer, normalize the input payload by resolving encoding issues, stripping BOM characters, and converting known type coercion edge cases (e.g., string "123" where an integer is expected) into a canonical form before sending to the model. Pass the schema as a compact JSON Schema draft-2020-12 definition alongside the payload using the [SCHEMA] and [PAYLOAD] placeholders. In the post-processing layer, parse the model's JSON response and extract the valid boolean and errors array. Map each error object's instancePath, schemaPath, and message fields into your application's error reporting format. If the model returns malformed JSON, implement a single retry with a repair-focused follow-up prompt that includes the raw output and asks for corrected JSON only. If the retry also fails, log the raw response and escalate to a dead-letter queue for human review rather than silently accepting or rejecting the payload.

For production observability, log every validation decision with the following fields: timestamp, schema_version, payload_hash, valid, error_count, model_id, latency_ms, and retry_count. Track the false-positive and false-negative rates by periodically sampling validated payloads and having a human reviewer confirm the model's verdict against the schema. Pay special attention to three known failure modes: type coercion edge cases where the model incorrectly flags string-to-number conversions as invalid, enum constraint violations where the model misses valid enum values that appear in unusual casing, and missing required fields where the model fails to distinguish between a field that is genuinely absent and a field that contains an explicit null. Build eval suites for each of these categories and run them before deploying schema changes. If the validation gate sits in a latency-sensitive path such as an API response stream, set a strict timeout of 2-3 seconds and configure a circuit breaker that falls back to a deterministic structural validator when the model is unavailable or too slow.

When the validation decision blocks a payload, return a structured error response to the caller that includes the instancePath for each violation, a human-readable message, and the relevant schemaPath constraint that was violated. This allows API consumers to fix their outputs without guessing what went wrong. For high-risk domains such as healthcare data ingestion or financial transaction processing, always require human review for any payload that the model marks as valid but contains fields the model flagged with low confidence—the prompt can be extended with a [CONFIDENCE_THRESHOLD] parameter that surfaces ambiguous cases. Finally, version your schemas and track which schema version was used for each validation decision so that audit trails remain coherent when schemas evolve.