Format Compliance Gate for JSON Output

This prompt is a binary gate for API developers and platform engineers who need to enforce machine-readable output contracts before an AI-generated payload reaches a downstream parser, database, or client. It is designed for production pipelines where a malformed JSON object is a hard failure, not a cosmetic issue. Use this prompt when you need a clear compliant/non-compliant decision, the exact location of a parse error, type mismatch details, and schema violation paths. It is built for nested object validation, array constraint checking, and encoding issue detection. This is not a prompt for generating JSON; it is a prompt for judging whether an already-generated JSON payload meets a strict specification.

The ideal user is an engineering lead or platform developer integrating an LLM into a system that expects structured data. Required context includes the raw JSON string to validate and a complete JSON Schema definition. The prompt expects a strict output format: a boolean compliant field, a parse_error object with line, column, and message for syntax failures, a type_mismatches array detailing expected vs. actual types at specific paths, and a schema_violations array listing constraint failures and their schema paths. This structure allows your application to branch on compliant and log detailed diagnostics for non-compliant payloads without parsing unstructured text.

Do not use this prompt when you need to generate JSON, repair malformed JSON, or evaluate the semantic quality of the content inside a valid JSON structure. This gate only checks syntactic validity and schema conformance. It will not catch factual errors, logical inconsistencies, or inappropriate content within correctly typed fields. For those concerns, pair this gate with a separate content evaluation prompt. Also avoid this prompt if your tolerance for latency is near-zero and you can perform client-side schema validation in your application code; a deterministic JSON Schema validator will be faster and cheaper for purely structural checks. Use this prompt when the validation logic requires reasoning about ambiguous cases, such as distinguishing between a missing field and a null field, or when you need a human-readable explanation of why a payload failed that can be logged for debugging.

This prompt template implements a strict format compliance gate. It receives a JSON output and a target schema, then returns a deterministic binary verdict: compliant or non-compliant. Unlike a simple linter, this prompt is designed to be used as an LLM judge within an evaluation harness, capable of explaining why a failure occurred in terms a developer can act on immediately. You should use this when you need to automate the validation of structured outputs from other models in a CI/CD pipeline or an agent workflow where malformed JSON would break downstream parsers.

codeCopy
You are a strict JSON format compliance judge. Your only job is to check whether the provided JSON output matches the required schema and constraints.

## INPUT
**Target Schema:**
```json
[OUTPUT_SCHEMA]

JSON Output to Validate:

jsonCopy
[OUTPUT_TO_VALIDATE]

CONSTRAINTS

[CONSTRAINTS]

INSTRUCTIONS

1. Parse the JSON Output to Validate. If it is not valid JSON, immediately return a non-compliant verdict with the parse error.
2. Compare the parsed output against every field, type, and constraint in the Target Schema.
3. Check for extra fields not defined in the schema if the schema has additionalProperties: false.
4. Validate all nested objects and arrays recursively.
5. Check for non-UTF-8 encoding issues or unescaped control characters.

OUTPUT FORMAT

Return ONLY a valid JSON object with the following structure. Do not include any text outside the JSON object.

jsonCopy
{
  "verdict": "compliant" | "non-compliant",
  "errors": [
    {
      "error_type": "PARSE_ERROR" | "TYPE_MISMATCH" | "MISSING_REQUIRED" | "CONSTRAINT_VIOLATION" | "EXTRA_FIELD" | "ENCODING_ERROR",
      "location": "$.path.to.field",
      "expected": "string describing what was required",
      "actual": "string describing what was found",
      "message": "A concise, actionable description of the violation."
    }
  ]
}

If the verdict is compliant, the errors array must be empty.

To adapt this template, replace [OUTPUT_SCHEMA] with your full JSON Schema definition. The [OUTPUT_TO_VALIDATE] placeholder should be dynamically populated with the raw string output from the model you are testing. Use the [CONSTRAINTS] block to add domain-specific rules that go beyond standard JSON Schema validation, such as "all date fields must be in ISO 8601 format" or "the id field must be a valid UUID." For high-risk applications where a false negative could corrupt a database, always pair this gate with a deterministic JSON Schema validator in your application code as a second layer of defense. The LLM judge provides the explanation; the code validator provides the hard enforcement.

This prompt acts as a pre-response gate in an API serving layer. After your primary model generates a JSON payload, route it through this compliance check before returning it to the client. The gate produces a binary compliant/non_compliant verdict along with a structured error report. If compliant, forward the original payload. If non-compliant, you have three options: retry with repair instructions, fall back to a safe default response, or return a controlled error to the caller. The choice depends on your latency budget and the downstream impact of malformed JSON.

Validation harness: Wrap the prompt in a function that accepts [EXPECTED_SCHEMA] (a JSON Schema object), [MODEL_OUTPUT] (the raw string or object to validate), and [SCHEMA_CONSTRAINTS] (additional rules like "no additional properties" or "enforce array minItems"). The prompt returns a JSON object with compliant (boolean), errors (array of objects with path, expected, found, message), and encoding_issues (array of strings for non-UTF8 or BOM problems). In your application code, parse this verdict first. If compliant is false, log the full error array to your observability stack and increment a format_gate_failure metric tagged by error_type and schema_version. This metric is your primary signal for prompt drift or model regression.

Retry logic: On failure, construct a repair prompt that includes the original [MODEL_OUTPUT], the errors array from the gate, and the [EXPECTED_SCHEMA]. Instruct the model to fix only the reported violations and return the corrected JSON. Set a maximum of 2 repair attempts. After the final attempt, if the gate still fails, return a 502 Bad Gateway with a structured error body containing the last errors array and a repair_exhausted: true flag. Never return raw, unvalidated model output to API consumers. For high-throughput systems, consider caching schema validation results when [EXPECTED_SCHEMA] is static—the gate prompt itself can be skipped if you pre-validate with a deterministic JSON Schema validator and only invoke the LLM gate for ambiguous cases like type coercion edge cases or enum intent mismatches.

Model choice and latency: Use a fast, cheap model for the gate (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model). The gate is a classification task with structured output, not a generation task. Keep the prompt under 500 tokens of instruction plus the schema and output. If your p99 latency budget is tight, run the gate in parallel with a deterministic structural validator (like ajv for Node.js or jsonschema for Python). If the deterministic validator passes, skip the LLM gate entirely. If it fails, use the LLM gate to produce the human-readable error report. This hybrid approach gives you speed for clean outputs and rich diagnostics for failures.

Observability and evals: Log every gate invocation with schema_id, model_id, compliant verdict, error count, and latency. Build an eval set of 50-100 known outputs covering: valid outputs, missing required fields, wrong types, extra properties, empty arrays where minItems is set, encoding errors, and near-miss enum values. Run this eval suite on any prompt or model change. A regression is defined as any previously-passing case now failing, or any error message that becomes less specific. If you're in a regulated domain, store the gate verdict and error report alongside the model output in your audit log. This creates a compliance artifact showing that every response was checked before delivery.