Multi-Constraint Instruction Adherence Grading Prompt

This prompt is designed for evaluation engineers and AI platform teams who need to verify that a model's output satisfies multiple simultaneous constraints—not just one or two. The job-to-be-done is automated, structured grading of a single output against a list of independent requirements, such as word limits, format rules, exclusion lists, tone guidelines, and mandatory inclusions. The ideal user is someone building an evaluation harness into a CI/CD pipeline, a regression test suite, or a pre-release quality gate where partial compliance is still a failure. You need a clear list of constraints, the candidate output to grade, and a defined output schema for the compliance report before using this prompt.

This prompt is not a general-purpose quality scorer. Do not use it when you need a single holistic score without per-constraint traceability, when constraints are vague or subjective without clear pass/fail criteria, or when the output requires human judgment for nuanced trade-offs. It is also not a substitute for schema validators—if you are checking JSON structure, field types, or enum values, use a deterministic parser first and reserve this prompt for semantic and behavioral constraints that require language understanding. The prompt works best when each constraint is stated as a discrete, verifiable condition with an unambiguous expected behavior. For example, 'Output must be under 200 words' is a good constraint; 'Output should be helpful' is not.

Before deploying this prompt in production, define your constraint weighting and conflict resolution strategy. When two constraints contradict each other—such as a word limit and a mandatory inclusion that pushes the output over that limit—the prompt needs explicit precedence rules. The harness described in the implementation section supports weight configuration and conflict detection, but you must decide your organization's policy: does a format violation override a content requirement, or vice versa? Start with a small, curated set of 10–20 test cases where you know the expected per-constraint results, and calibrate the prompt's judgments against human reviewers before scaling to automated pipelines.

This prompt template is designed to be dropped into an evaluation harness where a single model output must be checked against several independent constraints at once. Unlike a simple pass/fail check, this prompt instructs the judge model to evaluate each constraint separately, flag partial compliance where a constraint is mostly but not fully met, and then produce a weighted summary judgment. The square-bracket placeholders let you swap in your own constraints, weighting scheme, output schema, and conflict-resolution rules without rewriting the core grading logic.

textCopy
You are an expert evaluation judge. Your task is to grade a single AI-generated [OUTPUT_TYPE] against multiple constraints simultaneously. You must evaluate each constraint independently, detect partial compliance, and produce a structured compliance report.

## INPUT

### Output to Evaluate

[OUTPUT]

codeCopy

### Constraints to Check
Evaluate the output against each constraint below. For each constraint, determine whether the output PASSES, FAILS, or is PARTIALLY COMPLIANT. Partial compliance means the output mostly meets the constraint but has a minor deviation that does not fully break it.

[CONSTRAINTS]

### Constraint Weights
Use these weights to calculate the overall compliance score. Weights must sum to 1.0.

[WEIGHTS]

### Conflict Resolution Rules
If two constraints appear to conflict, apply these precedence rules to determine which constraint takes priority:

[CONFLICT_RULES]

## INSTRUCTIONS

1. Evaluate each constraint independently. Do not let one constraint's failure influence another constraint's grade unless a conflict rule explicitly requires it.
2. For each constraint, provide:
   - **Verdict**: PASS, FAIL, or PARTIAL
   - **Confidence**: 0.0 to 1.0
   - **Evidence**: Quote the specific part of the output that supports your verdict.
   - **Explanation**: One to two sentences explaining your reasoning.
3. If you mark a constraint as PARTIAL, explain exactly what was met and what was missed.
4. Calculate the **Weighted Compliance Score** as: sum of (constraint weight × score) where PASS = 1.0, PARTIAL = 0.5, FAIL = 0.0.
5. Produce a **Summary Judgment**: PASS if weighted score >= [PASS_THRESHOLD], FAIL otherwise.
6. If any constraint marked FAIL is a [CRITICAL_CONSTRAINT], the Summary Judgment must be FAIL regardless of the weighted score.
7. Flag any constraints that appear to conflict with each other and explain how you resolved the conflict.

## OUTPUT SCHEMA

Return ONLY valid JSON matching this schema:

[OUTPUT_SCHEMA]

## EXAMPLES

[EXAMPLES]

Adaptation guidance: Replace [CONSTRAINTS] with a numbered list of constraints, each with a unique ID, a clear description, and a critical boolean flag. Replace [WEIGHTS] with a mapping of constraint IDs to numeric weights. Replace [CONFLICT_RULES] with explicit precedence statements such as "Constraint A overrides Constraint B when both apply." Replace [OUTPUT_SCHEMA] with your target JSON schema, typically including constraint_results (array of per-constraint objects), weighted_score (float), summary_judgment (string), and conflict_notes (array). Replace [EXAMPLES] with at least two worked examples showing a clear PASS case and a case with partial compliance or conflict. Set [PASS_THRESHOLD] to a value between 0.7 and 0.9 depending on your tolerance for partial compliance. List any constraint IDs that are dealbreakers in [CRITICAL_CONSTRAINT]. For high-stakes domains such as healthcare or finance, add a [RISK_LEVEL] placeholder that gates whether the summary judgment requires human review before acceptance.

This prompt is designed to be called programmatically as a grading step inside an evaluation harness, not as a one-off manual check. The typical integration pattern is: (1) your system generates an output from a candidate prompt or model, (2) you pass the original instruction set and the generated output into this grading prompt, and (3) you parse the structured compliance report to decide whether the output passes, fails, or requires human review. The grading prompt itself should be treated as a deterministic evaluation function—use low temperature (0.0–0.2), disable sampling where possible, and always request structured output (JSON) to avoid parsing ambiguity.

Validation and retry logic must be built around the grader's output. After receiving the JSON compliance report, validate that all expected fields are present (per_constraint_results, summary_judgment, overall_score, conflict_flags). If the grader returns malformed JSON or missing fields, retry up to two times with the same input. If retries are exhausted, log the failure and escalate to a human review queue. For high-stakes domains (healthcare, legal, finance), configure the harness to require human approval whenever the overall_score falls below your defined threshold or when conflict_flags indicate the model had to choose between contradictory instructions. This prevents silently accepting outputs where the grader itself was uncertain about trade-off quality.

Weighting and threshold configuration should live in your application layer, not in the prompt. Store a configuration object that maps each constraint ID to a weight (0.0–1.0) and a minimum acceptable score. After the grader returns per-constraint results, your harness computes the weighted overall score and compares each constraint against its threshold. This separation lets you tune weights without changing the grading prompt and supports A/B testing different threshold profiles. For constraint conflict detection, configure a conflict_pairs list in your harness that defines which constraints are known to conflict (e.g., 'be concise' vs. 'include all details'). When the grader flags a conflict between a pair not in your known-conflict list, treat it as a prompt design bug that needs investigation.

Model choice matters for the grader itself. Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid using the same model family for both generation and grading when evaluating for production—this can mask systematic failures that both models share. For cost-sensitive pipelines, you can use a smaller model for the grader (GPT-4o-mini, Claude Haiku) but validate calibration against a larger judge on a golden dataset first. Log every grading result with the grader model version, timestamp, and input hash for auditability. When grading outputs that will be shown to users, store the compliance report alongside the output so you can trace why an output was accepted or rejected during incident review.

What to avoid: Do not use this prompt as a real-time guard in a user-facing chat loop—the latency and cost of running a full constraint audit on every turn is prohibitive. Instead, use it for offline evaluation, pre-deployment testing, and periodic sampling of production outputs. Do not treat the grader's output as ground truth without periodic human calibration; schedule monthly reviews where human evaluators grade the same outputs and compare against the automated scores to detect grader drift. Finally, do not skip the conflict detection step—multi-constraint prompts often contain hidden contradictions that only surface when you systematically check for them, and ignoring conflict flags leads to silently degraded outputs.