JSON Schema Compliance Check Prompt Template

This prompt is designed for platform engineers and test architects who need to gate LLM outputs in automated CI/CD pipelines. It validates a generated JSON payload against a target JSON Schema specification and returns a structured, machine-readable pass/fail verdict with specific violation paths. Use this when downstream systems depend on strict schema adherence and manual review of every output is not scalable. This prompt belongs in the validation stage of your AI workflow, after generation and before the output is consumed by an API, database, or user interface. It is not a generation prompt; it is an assertion prompt that acts as a quality gate.

The ideal user is someone embedding LLM calls into a production system where schema contracts are non-negotiable. For example, an ingestion pipeline that expects a specific JSON structure before writing to a database, or a microservice that will reject malformed payloads with a 4xx error. The prompt requires two inputs: the generated JSON payload to validate, and the target JSON Schema specification. It works best when the schema is explicit about required fields, types, enums, and nested object structures. Avoid using this prompt for loose structural checks or when the schema itself is ambiguous—it will flag legitimate variations as violations if the schema is not precise.

Do not use this prompt as a substitute for a deterministic JSON Schema validator in your application code. A standard library like ajv (JavaScript) or jsonschema (Python) will be faster, cheaper, and more reliable for strict syntactic validation. This prompt is appropriate when you need semantic judgment about whether a field value conforms to a schema's intent, when the schema contains natural language descriptions that require interpretation, or when you want a human-readable explanation of violations alongside the machine-readable verdict. It is also useful as a secondary check to catch issues that a deterministic validator might miss due to schema version mismatches or ambiguous type coercions.

Before deploying this prompt, prepare a small golden dataset of known-valid and known-invalid JSON payloads paired with your target schema. Run the prompt against both sets and verify that it correctly identifies all violations in the invalid set without raising false positives on the valid set. Pay special attention to edge cases: optional fields that are missing, null values where the schema allows them, empty arrays, and deeply nested objects. These are common sources of false positives. If your schema evolves, re-run your golden dataset to confirm the prompt still behaves correctly under the new version.

This template is designed to be dropped directly into your validation harness. It instructs the model to act as a strict schema validator, comparing a provided JSON output against a target JSON Schema. The prompt forces the model to return a structured report rather than a conversational answer, making it suitable for automated CI/CD gates where a machine-readable pass/fail verdict is required. Before using it, ensure you have a well-formed JSON Schema that accurately represents your contract, including required fields, type constraints, and enum values.

textCopy
You are a strict JSON Schema validator. Your task is to validate the provided [OUTPUT_JSON] against the [TARGET_SCHEMA]. Do not interpret, fix, or complete the data. Only report violations.

## Validation Rules
- Check that all required fields from the schema are present and non-null.
- Verify that the type of each value matches the schema's type definition.
- Confirm that enum fields contain only allowed values.
- Validate all nested objects and arrays recursively.
- Check for additional properties if `additionalProperties` is set to `false` in the schema.
- Report the full JSON path for every violation (e.g., `$.user.address.zip`).

## Output Format
Return ONLY a valid JSON object with the following structure. Do not include any text outside the JSON.
{
  "valid": boolean,
  "violations": [
    {
      "path": "string (JSONPath)",
      "rule": "string (e.g., 'required', 'type', 'enum', 'additionalProperties')",
      "expected": "string",
      "actual": "string",
      "message": "string (human-readable explanation)"
    }
  ],
  "summary": "string (one-line pass/fail summary)"
}

## Input Data
### Target Schema
[TARGET_SCHEMA]

### Output to Validate
[OUTPUT_JSON]

To adapt this template, replace [TARGET_SCHEMA] with your complete JSON Schema object and [OUTPUT_JSON] with the LLM-generated output you need to check. For high-risk domains such as finance or healthcare, add a [RISK_LEVEL] placeholder and a corresponding instruction to flag any violation as blocking if the risk level is critical. You can also extend the violations array with a severity field to support non-blocking warnings. After copying the template, always run it against a known set of valid and intentionally invalid outputs to confirm the model correctly identifies both passing and failing cases before wiring it into an automated pipeline.

Integrating this prompt into a production harness requires treating it as a deterministic validation step, not a conversational agent. The prompt expects a target JSON Schema and an LLM output to validate. The harness is responsible for injecting these inputs, parsing the structured pass/fail verdict, and routing the result to the appropriate gate. A typical implementation wraps the prompt in a function like validate_output_against_schema(llm_output: dict, target_schema: dict) -> ValidationVerdict. This function should be callable from a test runner, a pre-commit hook, or a CI step that blocks a deployment if the verdict is fail.

The harness must enforce a strict contract on the model's response. Configure your API call with response_format set to json_object (or the equivalent for your model provider) and provide the output schema from the prompt template as the expected JSON structure. After receiving the response, run a client-side structural validation to confirm the model returned valid JSON matching the ValidationVerdict schema before trusting the pass or fail field. If the model's own output fails to parse, the harness should treat this as a system error and trigger a retry with a simplified fallback prompt, or escalate for human review. Log every verdict, the raw model response, and the input schema version for auditability.

For high-reliability CI/CD gates, implement a two-pass strategy. First, run the prompt to get the initial verdict. If the verdict is fail, extract the violations array and feed it into a separate repair prompt from the Output Repair and Validation Prompts pillar. After repair, re-run this compliance check prompt on the repaired output. The gate should only pass if the final verdict is pass. To prevent flaky gates, run the check multiple times (n=3 or n=5) with a low temperature setting and require a unanimous or majority pass verdict. Avoid wiring this prompt directly into synchronous user-facing flows without a timeout and a circuit breaker; a slow model response should not degrade the user experience.