Partial Compliance Detection Prompt for Multi-Requirement Tasks

This prompt is designed for evaluation leads and AI engineers who need to move beyond binary pass/fail judgments for complex, multi-requirement tasks. Its core job is to detect partial compliance: distinguishing a complete failure from a near-miss that got 4 out of 5 constraints right. You should use this prompt when a single output must satisfy a list of explicit, independently verifiable instructions—such as a generated report that must include specific sections, stay under a word limit, use a particular tone, and cite its sources. The ideal user is someone integrating an automated evaluation gate into a CI/CD pipeline or a data preparation workflow, where understanding the degree of failure is critical for deciding whether to retry, repair, or reject an output.

You need to provide a clear, structured list of requirements as the [REQUIREMENTS] input. This isn't a prompt for grading open-ended creative quality or subjective preference; it's for verifying explicit, constraint-based instructions. The prompt works best when each requirement is atomic and falsifiable (e.g., 'Output must be valid JSON' or 'Must not mention competitors'). You must also configure a [PASS_THRESHOLD], a percentage score below which the output is considered a hard failure. This threshold is your primary gating mechanism, allowing you to accept an output that missed one minor formatting rule while still rejecting a response that ignored a critical safety constraint.

Do not use this prompt for evaluating conversational quality, factual accuracy against an external knowledge base, or the logical soundness of an argument. Those tasks require different evaluators focused on groundedness, reasoning traces, or dialogue coherence. This prompt is also the wrong tool if your requirements are inherently subjective (e.g., 'The tone should be friendly') without a detailed rubric defining what 'friendly' means. For high-risk domains like healthcare or legal review, the compliance matrix this prompt produces should be treated as a diagnostic signal for a human reviewer, not as an automated decision-maker. The next step is to wire this prompt into a validation harness that can parse its structured output and trigger the appropriate action—retry, repair, or escalate.

This template is designed to be copied directly into your evaluation harness. It instructs the model to act as a compliance auditor, breaking down a multi-requirement task into individual constraints and scoring each one independently. The prompt uses square-bracket placeholders for all variable inputs—replace these with your actual task description, output to evaluate, requirements list, and scoring configuration before use. The template is structured to produce a consistent JSON output that can be parsed by downstream validation and gating logic.

textCopy
You are a compliance auditor evaluating an AI-generated output against a set of explicit requirements. Your job is to detect partial compliance: some requirements may be fully met, partially met, or not met at all.

## INPUT

**Task Description:**
[TASK_DESCRIPTION]

**Output to Evaluate:**
[OUTPUT_TO_EVALUATE]

**Requirements:**
[REQUIREMENTS_LIST]

## SCORING RULES

For each requirement, assign a compliance status and score:
- **FULLY_MET** (1.0): The output completely satisfies the requirement with no omissions or errors.
- **PARTIALLY_MET** (0.5): The output addresses the requirement but has gaps, incomplete coverage, or minor errors.
- **NOT_MET** (0.0): The output fails to satisfy the requirement or contradicts it.

## OUTPUT SCHEMA

Return a JSON object with this exact structure:
{
  "overall_compliance_percentage": <number 0-100>,
  "overall_pass": <true if overall_compliance_percentage >= [PASS_THRESHOLD]>,
  "requirements": [
    {
      "requirement_id": "<string>",
      "requirement_text": "<string>",
      "status": "FULLY_MET" | "PARTIALLY_MET" | "NOT_MET",
      "score": <0.0 | 0.5 | 1.0>,
      "evidence": "<quote or description from the output that supports this score>",
      "reasoning": "<brief explanation of why this score was assigned>"
    }
  ],
  "summary": "<one-paragraph summary of overall compliance, highlighting critical failures if any>"
}

## CONSTRAINTS

[CONSTRAINTS]

## EXAMPLES

[EXAMPLES]

## INSTRUCTIONS

1. Evaluate each requirement independently against the output.
2. Provide specific evidence from the output for every score.
3. If a requirement has sub-parts, treat partial satisfaction as PARTIALLY_MET.
4. Calculate overall_compliance_percentage as: (sum of all requirement scores / total number of requirements) * 100.
5. Apply the pass threshold of [PASS_THRESHOLD] percent to determine overall_pass.
6. If [RISK_LEVEL] is "high", flag any NOT_MET requirements in the summary with a warning.

To adapt this template, replace the square-bracket placeholders with your specific context. [TASK_DESCRIPTION] should contain the original instruction given to the model being evaluated. [OUTPUT_TO_EVALUATE] is the generated text or structured output under review. [REQUIREMENTS_LIST] should be a numbered or bulleted list of individual constraints—break compound requirements into separate items so each can be scored independently. [PASS_THRESHOLD] is an integer between 0 and 100 representing the minimum overall compliance percentage required for a pass. Use [CONSTRAINTS] to add domain-specific rules such as "requirements about legal disclaimers are weighted as critical" or "partial credit is not allowed for safety requirements." The [EXAMPLES] placeholder should contain one or two worked examples showing correct scoring for edge cases like near-misses and complete failures. Set [RISK_LEVEL] to "high" when the evaluation gates a production deployment, regulated output, or user-facing system—this activates warning flags in the summary for any NOT_MET requirements.

Before deploying this prompt, validate that your requirements list is exhaustive and non-overlapping. Overlapping requirements cause double-counting and inflate or deflate the compliance percentage. Test the prompt with known outputs that should score at 0%, 50%, and 100% compliance to verify threshold behavior. For high-risk workflows, route outputs scoring below the pass threshold to human review rather than auto-rejecting. The JSON output schema is designed for direct ingestion by a validation function—add a post-processing step that checks field presence, type correctness, and score range before the result gates any downstream action.

This prompt is designed to sit inside an automated evaluation harness, not as a one-off manual check. The typical integration pattern is: a task-under-test produces an output, that output is paired with the original multi-requirement specification, and both are sent to this prompt. The resulting compliance matrix is then parsed and fed into a gating decision. Because the prompt returns structured JSON with per-requirement scores and an overall compliance percentage, the harness can enforce pass/fail thresholds programmatically without human interpretation of free-text commentary.

Wire the prompt into your evaluation loop by constructing a request that includes the full [REQUIREMENTS] list, the [OUTPUT_TO_EVALUATE], and any [THRESHOLD_CONFIG] for partial credit scoring. Validate the response against a strict JSON schema before trusting it: check that requirements is an array, each element has id, description, score, max_score, and evidence fields, and that overall_compliance_percentage is a number between 0 and 100. If validation fails, retry once with an explicit error message appended to the prompt context. Log every compliance matrix alongside the task output and model version for traceability. For high-stakes domains such as healthcare, legal, or finance, route outputs below the threshold to a human review queue rather than auto-rejecting—the partial credit breakdown gives reviewers a precise map of what passed and what didn't.

Choose a model with strong instruction-following and structured output capabilities for this judge role. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable; avoid smaller models that may collapse partial-credit distinctions into binary pass/fail. Set temperature to 0 to maximize scoring consistency across runs. If you observe score drift over time, implement a calibration step where a subset of evaluations is spot-checked by a human rater and compared against the judge's scores. Store these calibration pairs to detect when the judge needs prompt adjustment or model upgrade. The compliance matrix this prompt produces is also an excellent input for downstream analytics—aggregate per-requirement pass rates to identify which constraints are most frequently violated, and use that data to improve your task prompts or adjust requirement wording.