Output Schema Compliance Check Prompt

This prompt is for integration engineers and developers who need to validate that a language model's structured output conforms to a strict contract before that output touches a database, API, or downstream service. The job-to-be-done is automated, per-field compliance auditing: you provide the expected JSON schema and the model's raw output, and the prompt produces a machine-readable report identifying every violation, its exact location, and a suggested repair. This is not a prompt for generating structured data; it is a post-generation quality gate that sits between the model and your application logic.

Use this prompt when your pipeline requires structured outputs (JSON, typed objects, enums) and you cannot afford silent schema drift. It is appropriate for CI/CD regression suites, real-time API response validation, and batch auditing of model outputs. The ideal user is an engineer wiring a model into a production system who needs a deterministic, reviewable compliance signal. Required context includes the full expected schema, the raw model output string, and any field-level constraints such as required keys, enum values, or format patterns. Do not use this prompt for free-text quality evaluation, semantic similarity checks, or rubric-based scoring—those are separate evaluation workflows.

Avoid this prompt when the output schema is ambiguous, still under design, or when the model's output is expected to vary in structure by design. It is also the wrong tool for evaluating factual accuracy or reasoning quality. In high-risk domains—such as healthcare, finance, or legal compliance—the repair suggestions this prompt generates are diagnostic hints, not authoritative fixes. Always route suggested repairs through human review or a validated repair pipeline before accepting them into a system of record. The next step after reading this section is to prepare your schema, gather representative model outputs, and wire the prompt into a validation harness that logs every compliance report for auditability.

This prompt template is designed to be dropped into a post-generation validation step. It takes a model's raw output and an expected JSON schema, then produces a structured compliance report. The report identifies type mismatches, missing required keys, invalid enum values, and structural violations at the exact field path where they occur. Use this when you need deterministic, machine-readable validation results before the output reaches downstream consumers.

textCopy
You are a strict JSON schema validator. Your task is to compare the provided [MODEL_OUTPUT] against the expected [OUTPUT_SCHEMA] and produce a compliance report.

## Input
[MODEL_OUTPUT]

## Expected Schema
[OUTPUT_SCHEMA]

## Instructions
1. Parse the model output as JSON. If parsing fails, report a top-level parse error and stop.
2. Walk every field in the expected schema. For each field, check:
   - Presence (required fields must exist)
   - Type (string, number, boolean, array, object, null)
   - Format constraints (date-time, email, URI, regex pattern)
   - Enum membership (value must be one of the allowed options)
   - Nested object and array item compliance (recurse into sub-schemas)
3. Do not report extra fields present in the output but absent from the schema unless [STRICT_MODE] is true.
4. For each violation, record the exact JSON path (e.g., $.user.address.city), the expected constraint, the actual value found, and a suggested repair.

## Output Format
Return a JSON object with this exact structure:
{
  "valid": boolean,
  "violations": [
    {
      "path": "$.field.path",
      "constraint": "type: string | required: true | enum: [A, B]",
      "actual": "value found or 'missing'",
      "suggestion": "human-readable repair hint"
    }
  ],
  "parse_error": null or "error message if JSON is unparseable"
}

## Constraints
- Do not hallucinate violations. Only report real deviations.
- If the output is fully compliant, return valid: true with an empty violations array.
- Do not add commentary outside the JSON report.

Adapt this template by replacing [MODEL_OUTPUT] with the raw string from your generation step, and [OUTPUT_SCHEMA] with your target JSON Schema (draft-07 or later). Set [STRICT_MODE] to true if extra fields should be treated as violations—useful when downstream parsers reject unknown properties. For high-risk domains such as healthcare or finance, always route violations to a human review queue before automated repair is attempted. Pair this prompt with a retry loop that feeds the violation report back to the generation model for self-correction, but cap retries at three attempts to avoid infinite loops.

The Output Schema Compliance Check Prompt is designed to sit inside a post-generation validation loop, not as a standalone manual review tool. After your primary generation prompt produces a structured output, pass both the raw output and the expected JSON schema to this compliance check prompt. The prompt returns a per-field compliance report with specific violation locations and repair suggestions, which your application can parse to decide whether to auto-repair, retry, or escalate. This pattern works best when the expected schema is stable and the compliance check runs before the output reaches any downstream consumer, database, or API.

Wire the prompt into your application as a validation step with a clear decision tree. First, parse the compliance report's top-level valid boolean. If true, pass the output through. If false, iterate through the violations array and check the severity field. For ERROR-level violations on required fields or type mismatches, trigger a repair prompt that includes the original output, the violation details, and the schema. For WARNING-level issues like extra fields or enum deviations, apply programmatic fixes where possible—strip unknown fields, coerce types, or map near-miss enum values using a lookup table. Implement a retry counter: after two repair attempts, if violations persist, log the full compliance report and route the case to a human review queue. Use structured logging to capture the model, prompt version, input context, raw output, compliance report, and final disposition for every validation run.

Model choice matters for this workflow. The compliance check itself is a classification and comparison task that benefits from models with strong instruction-following and structured output capabilities. Use a fast, cost-effective model for the check step and reserve more capable models for the repair step when violations are complex. If your primary generation model already supports structured output modes or JSON mode, run the compliance check as a secondary verification rather than relying solely on the model's built-in guarantees. For high-risk domains where schema violations could cause downstream data corruption or compliance issues, always require human review for any output that fails the compliance check after one repair attempt. Never silently drop violations or auto-accept repaired outputs without logging the full repair chain.