Output Accept/Reject Decision Prompt with Justification

This prompt is a production-grade binary gate for API developers and ML engineers who need a single, defensible accept/reject decision on an AI-generated output before it reaches a downstream system or user. It is not a general quality scorer, a multi-factor rubric, or a content generation tool. The core job-to-be-done is to take a candidate output and its original input context, then produce a structured verdict with a detailed, auditable justification. Use this when your pipeline requires a hard stop based on specific failure criteria—such as factual inaccuracies, schema violations, or safety policy breaches—rather than a nuanced quality score.

The ideal user already has a candidate output from an upstream model and needs an automated, evidence-based gating mechanism. This prompt assumes you are not generating the output here; you are judging it. Required context includes the original user input or source material, the candidate output, and a clearly defined set of acceptance criteria or constraints. Do not use this prompt for real-time chat moderation where latency is measured in milliseconds, as the detailed justification adds token overhead. It is also unsuitable for ranking multiple candidate outputs against each other; for that, use a pairwise comparison or LLM judge prompt from the evaluation rubric pillar.

Before wiring this into a production harness, ensure your acceptance criteria are unambiguous and testable. Ambiguous policies like 'the output must be high quality' will produce inconsistent decisions. Instead, define concrete, falsifiable checks: 'the output must not contain a hallucinated date not present in the source text' or 'the output must be valid JSON matching the provided schema.' The prompt is designed to cite specific failure points and suggest remediation steps, making it ideal for pipelines that log decisions for audit trails or route rejected outputs to a repair queue. If your primary need is to normalize confidence scores across different models, use the Confidence Score Extraction and Normalization Prompt instead.

A common anti-pattern is using this prompt as a substitute for deterministic validation. If a failure mode can be caught with a JSON schema validator, a regex, or a simple business rule, apply those checks before invoking the LLM. Reserve this prompt for semantic and contextual failures that require reasoning—such as detecting subtle hallucinations, policy violations, or logical inconsistencies that static validators miss. This keeps costs down and ensures the LLM is focused on high-value decisions that justify its latency and token spend.

This prompt template implements a binary gating decision for model outputs. It is designed to be placed in the user role of your LLM request, with a simple system prompt such as 'You are an expert output quality auditor. You make binary decisions with clear justifications.' The template expects the original output to evaluate, the context or source material it should be grounded in, and any domain-specific quality criteria. All placeholders use square brackets and must be replaced with concrete values before sending the request.

textCopy
You are evaluating an AI-generated output against quality criteria and source material.

## OUTPUT TO EVALUATE
[OUTPUT]

## SOURCE MATERIAL (if applicable)
[SOURCE_CONTEXT]

## QUALITY CRITERIA
[QUALITY_CRITERIA]

## CONSTRAINTS
- [CONSTRAINT_1]
- [CONSTRAINT_2]
- [CONSTRAINT_3]

## RISK LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
1. Assess the output against each quality criterion.
2. Check all claims against the source material where applicable. Flag any unsupported claims.
3. Determine whether the output meets the minimum acceptable threshold.

## OUTPUT FORMAT
Return a JSON object with exactly this structure:
{
  "decision": "ACCEPT" | "REJECT",
  "confidence": <float between 0.0 and 1.0>,
  "criteria_results": [
    {
      "criterion": "<criterion name>",
      "passed": <true | false>,
      "evidence": "<specific evidence from the output>"
    }
  ],
  "failure_points": [
    "<specific description of each failure>"
  ],
  "unsupported_claims": [
    "<claim not found in source material>"
  ],
  "justification": "<detailed explanation of the decision>",
  "remediation": "<suggested fixes if REJECT, otherwise null>"
}

If the decision is ACCEPT, failure_points and unsupported_claims must be empty arrays, and remediation must be null.
If the decision is REJECT, at least one failure_point or unsupported_claim must be present.

To adapt this template, replace each square-bracket placeholder with concrete values. [OUTPUT] should contain the full text or structured payload you are evaluating. [SOURCE_CONTEXT] should include the reference material, retrieved documents, or ground truth that the output must be faithful to—leave it empty only if you are evaluating format or style alone. [QUALITY_CRITERIA] should list the specific dimensions you care about, such as factuality, completeness, tone, or schema compliance. [CONSTRAINT_1] through [CONSTRAINT_3] are hard rules the output must not violate. [RISK_LEVEL] should be set to LOW, MEDIUM, HIGH, or CRITICAL to help the model calibrate its strictness. For high-risk domains, always route REJECT decisions to a human reviewer and log the full justification payload for audit trails.

The Output Accept/Reject Decision Prompt is designed to sit at a critical gating point in your pipeline—after the primary model generates output but before that output reaches a downstream system, database, or user. The harness must treat this prompt as a deterministic decision node with a clear contract: it receives an output payload and a set of acceptance criteria, and it returns a binary decision with structured justification. Wire this into your application as a post-generation hook that runs synchronously before any state mutation occurs. If the decision is reject, the downstream write or display must be blocked. The harness should never silently drop a rejection; it must route the rejected output to a dead-letter queue, a retry loop, or a human review interface depending on the severity and context.

Validation and retry logic is essential because the prompt itself can produce malformed JSON, missing fields, or ambiguous decisions. Implement a strict output validator that checks for the required schema: decision (enum: accept | reject), justification (non-empty string), failure_points (array of strings, empty on accept), and remediation (string or null). If validation fails, retry the prompt once with the validation error message appended to the [CONSTRAINTS] block. After two failed attempts, escalate to a human reviewer and log the raw response for debugging. For high-throughput systems, add a circuit breaker: if the rejection rate exceeds a configured threshold (e.g., 40% over a rolling 5-minute window), pause automated gating and alert the operations team. This prevents a prompt regression or model drift from silently blocking all traffic.

Logging and audit trail requirements are non-negotiable for this prompt. Every decision must be logged with: the input output payload, the acceptance criteria used, the model and prompt version, the raw decision response, the validation result, the final routed action, and a timestamp. Store these in a structured format (JSON) in your observability platform, not as unstructured text logs. This audit trail serves three purposes: debugging false positives/negatives, demonstrating compliance for regulated workflows, and providing training data for future threshold calibration. For high-risk domains (healthcare, finance, legal), require a human reviewer to sign off on the first N rejections after deployment and periodically sample accepted outputs to verify the gate isn't drifting. Wire the justification field directly into your review UI so the human reviewer sees exactly why the model recommended rejection without needing to re-analyze the output from scratch.

Model selection and latency budgeting matter here because this prompt adds overhead to every output. Use a fast, cost-effective model for the gating decision—this is a classification and justification task, not a generation task. Models like GPT-4o-mini, Claude Haiku, or a fine-tuned small model work well. Set a strict timeout (e.g., 2-5 seconds) and treat timeouts as reject with a TIMEOUT reason code to avoid hanging your pipeline. If your primary generation model already produces a confidence score, pass it into the [CONTEXT] block to reduce the gating model's workload. Avoid running this prompt on outputs that are already validated by deterministic schema checks—use it for semantic quality, safety, and policy compliance decisions that can't be expressed as regex or JSON Schema rules. The next step after implementing this harness is to run a calibration exercise: compare the prompt's decisions against human judgments on a labeled dataset to tune your acceptance criteria and measure false-positive/false-negative rates before going live.