Low-Confidence Segment Flagging Prompt for Batch Outputs

This playbook is for QA engineers and ML platform teams who receive batch outputs from upstream models and need an automated first pass to flag segments that are likely incorrect, hallucinated, or too uncertain to ship without review. Use this prompt when you have a high volume of generated text and limited human review capacity. The prompt produces a marked-up version of the original output with low-confidence spans identified, severity ratings, and a suggested review priority order. It does not fix the output; it triages it.

This prompt assumes you already have the raw model output and any available source context. It is not a replacement for a structured output schema validator or a factuality ground-truth check. It is a pre-review gating tool that reduces the surface area a human must inspect. The ideal user is a QA engineer or ML ops team member who needs to prioritize which outputs to review first, not someone looking for a final correctness guarantee. The prompt works best when you can provide the original generation context—such as the user query, retrieved documents, or system instructions—so the flagging model can compare the output against what the model should have known.

Do not use this prompt when you need a definitive factuality verdict, when the output format is strictly structured (use a schema validator instead), or when the cost of a missed error is catastrophic without human review. This prompt is a triage tool, not a safety net. In high-risk domains such as healthcare, legal, or finance, flagged outputs must still go through qualified human review. The prompt's value is in reducing the number of outputs a human must inspect from thousands to dozens, not in eliminating human review entirely.

Before implementing this prompt in production, calibrate its flagging behavior against a labeled dataset of known-good and known-bad outputs. Measure flag recall (did it catch the bad segments?) and flag precision (were the flagged segments actually bad?). Expect the prompt to be conservative—it should flag more segments than necessary rather than miss real issues. Tune the severity thresholds and review priority logic based on your team's review capacity and risk tolerance. The next section provides the copy-ready prompt template you can adapt and deploy.

This prompt template is designed to be pasted directly into your system instructions or as a user message for batch processing. It instructs the model to act as a QA reviewer, scanning provided outputs for segments where the factual grounding, logical coherence, or instruction adherence appears weak. The model must return a strict JSON structure containing the original output with inline flags, severity ratings, and a prioritized review order, making it directly ingestible by downstream automation or human review queues. Replace every square-bracket placeholder with your actual values before use.

textCopy
You are an expert QA reviewer. Your task is to analyze the provided model-generated output and identify every segment where confidence in correctness, factual grounding, or instruction adherence is low.

Input to review:
[OUTPUT_TO_REVIEW]

Original generation context and instructions:
[GENERATION_CONTEXT]

For each low-confidence segment you identify, apply the following severity definitions:
- CRITICAL: Factually wrong, logically impossible, or violates a core safety/instruction constraint.
- HIGH: Likely wrong, contradicts provided context, or makes an unsupported claim.
- MEDIUM: Ambiguous, vague, or missing necessary qualification.
- LOW: Minor stylistic or formatting issues that do not affect correctness.

Return a single JSON object with this exact structure:
{
  "reviewed_output": "The full original output with low-confidence spans wrapped in <flag severity='LEVEL' note='BRIEF_REASON'>...</flag> tags.",
  "flags": [
    {
      "id": "flag-001",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "span_text": "The exact text flagged.",
      "start_char": 0,
      "end_char": 0,
      "reason": "Specific reason for the flag, referencing the generation context if applicable.",
      "suggested_action": "REWRITE|VERIFY|REMOVE|ESCALATE"
    }
  ],
  "review_priority_order": ["flag-003", "flag-001"],
  "overall_assessment": "A one-sentence summary of output quality."
}

Constraints:
- Do not flag text that is correct and well-supported.
- If no low-confidence segments exist, return an empty flags array and state 'No low-confidence segments identified.' in the overall_assessment.
- The reviewed_output string must contain the complete original text with inline XML flags inserted.
- Ensure the JSON is valid and parseable.

To adapt this template, replace [OUTPUT_TO_REVIEW] with the raw text from your model and [GENERATION_CONTEXT] with the original prompt, retrieved documents, or system instructions that produced it. The severity definitions can be tuned to match your organization's risk tolerance. For high-stakes domains like healthcare or finance, always route CRITICAL and HIGH severity flags to a human review queue before any downstream action. The inline XML flag format (<flag>) is chosen to be easily strippable for display while remaining machine-readable for log parsers and monitoring dashboards.

This prompt is designed to run as a post-generation step in a batch processing pipeline. After your primary model produces a set of outputs, each output is sent to this flagging prompt for confidence assessment. The harness should call the model API with the prompt template, parse the JSON response, and route flagged segments to a review queue. Model choice matters: use a model with strong instruction-following and JSON output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller or older models that may hallucinate severity ratings or miss subtle low-confidence indicators. Set temperature=0 or very low (0.1 max) to ensure consistent flagging behavior across batches.

Validation and retry logic: Parse the JSON response immediately and validate against the expected schema. Check that flagged_segments is an array, each segment has required fields (segment_text, start_index, end_index, confidence_score, severity, reason), and severity is one of the allowed enum values (low, medium, high, critical). If validation fails, retry once with the same input and an explicit error message appended to the prompt: Your previous response failed schema validation. Ensure all required fields are present and severity is one of: low, medium, high, critical. If the second attempt also fails, log the failure and route the entire output to human review with a validation_failure tag. Do not retry more than twice—diminishing returns and latency costs accumulate quickly.

Human review routing: Flagged segments with severity of high or critical should be routed to a review queue immediately. Segments with medium severity can be batched for periodic review. low severity segments can be logged for trend analysis but typically don't require immediate human attention. Include the original output, the flagged segment, the confidence score, and the reason in the review payload. For audit trails, store the full prompt response alongside the original output and the reviewer's eventual decision. This creates a feedback loop: reviewer corrections can be used to calibrate future flagging thresholds or fine-tune the flagging model.

Performance considerations: Batch processing with this prompt adds latency proportional to output length. For high-throughput systems, consider parallelizing flagging calls across multiple outputs using async API calls. Monitor flagging rate—if more than 20% of outputs are flagged as high or critical, investigate whether the primary generation model is underperforming or the flagging thresholds are too sensitive. Set up dashboards tracking: flag rate by severity, validation failure rate, retry rate, and reviewer confirmation rate (how often human reviewers agree with the flag). These metrics will tell you whether the gating is working or needs recalibration.

What to avoid: Don't use this prompt as the sole quality gate for regulated or safety-critical outputs without human review of flagged segments. Don't skip schema validation—malformed JSON from the flagging model can silently drop segments from review. Don't ignore the reason field in review routing; it's the most valuable signal for reviewers to quickly assess whether a flag is actionable. Finally, don't treat confidence scores as absolute—they are model self-assessments and should be calibrated against human judgments periodically using the eval checks described in the testing section of this playbook.