Human Approval Request Prompt for Extraction Payloads

This prompt is for workflow engineers who need to generate a structured human approval request when an extraction pipeline produces a record that requires sign-off before downstream ingestion. The core job-to-be-done is converting a machine-readable extraction payload, complete with confidence metadata and risk context, into a reviewer-ready artifact that demands a clear decision. The ideal user is an engineer or operator integrating a human-in-the-loop gate into an automated document processing system, where the cost of an incorrect extraction—financial, regulatory, or operational—exceeds the cost of human review.

Use this prompt only after an extraction attempt has been made and confidence scores are available. The required context includes the raw extraction output, per-field or record-level confidence scores, the source text spans, and any pre-defined risk classifications for the fields in question. The prompt is designed to be wired into a pipeline stage that fires when a confidence threshold gate returns an 'escalate' decision. It is not a real-time chat interface, nor is it a replacement for the extraction model itself. Do not use this prompt to perform the initial extraction or to make an automated accept/reject decision; its sole purpose is to package information for a human reviewer.

Before implementing, ensure your pipeline can supply the [EXTRACTION_PAYLOAD], [CONFIDENCE_METADATA], and [RISK_CONTEXT] placeholders with structured data. The output is a formatted approval request, not a final database record. The next step after a human responds is to parse their decision and route the approved, rejected, or corrected payload back into the ingestion flow. Avoid using this prompt for low-risk, high-volume records where a simple confidence threshold gate is sufficient, as introducing unnecessary human review creates a bottleneck and adds operational cost without proportional benefit.

This template is the core instruction set for an LLM to act as a workflow gatekeeper. Its job is to take a raw extraction payload—complete with field values, confidence scores, and source context—and format it into a strict, human-readable approval request. The output is designed to be parsed by a downstream review queue system, so the response schema must be rigidly followed. Copy the block below, replace every square-bracket placeholder with your live data, and inject it into your model's system or user prompt.

textCopy
You are an extraction review gatekeeper. Your task is to generate a structured human approval request for the following extracted record. Do not modify the extracted values. Your only job is to format the request and set the correct decision options.

## INPUT DATA
- Extracted Record: [EXTRACTION_PAYLOAD_JSON]
- Source Document ID: [DOCUMENT_ID]
- Source Text Span: [SOURCE_TEXT]
- Extraction Timestamp: [TIMESTAMP]
- Pipeline Run ID: [RUN_ID]

## CONFIDENCE THRESHOLDS
- High Confidence: >= [HIGH_THRESHOLD]
- Medium Confidence: >= [MEDIUM_THRESHOLD]
- Low Confidence: < [MEDIUM_THRESHOLD]

## OUTPUT SCHEMA (Strict JSON)
{
  "approval_request": {
    "request_id": "string (generate a unique ID)",
    "document_id": "string",
    "timestamp": "string",
    "overall_confidence": "string (High | Medium | Low)",
    "fields_for_review": [
      {
        "field_name": "string",
        "extracted_value": "string or null",
        "confidence_score": "number (0.0-1.0)",
        "confidence_level": "string (High | Medium | Low)",
        "source_evidence": "string (exact quote from source)",
        "risk_note": "string (explain why this field needs review, if applicable)"
      }
    ],
    "reviewer_instructions": "string (concise summary of what the reviewer must verify)",
    "decision_options": {
      "approve": "boolean (set to true)",
      "reject": "boolean (set to true)",
      "correct": "boolean (set to true)",
      "corrected_value_schema": {
        "field_name": "string",
        "corrected_value": "string"
      }
    }
  }
}

## CONSTRAINTS
- Only include fields in `fields_for_review` where `confidence_score` < [HIGH_THRESHOLD].
- If no fields require review, set `fields_for_review` to an empty array and `reviewer_instructions` to "All fields meet high-confidence threshold. No review required."
- The `risk_note` must cite the specific ambiguity or missing data from the source.
- Do not hallucinate any values. If the source evidence is missing, state "Source span not provided."

After pasting this template, the critical adaptation step is wiring your upstream extraction pipeline's output into the [EXTRACTION_PAYLOAD_JSON] placeholder. This payload should already be a structured JSON object containing the raw field names, values, and per-field confidence scores. The template assumes your pipeline has already performed the extraction; it does not re-extract or re-interpret the source text. For high-risk domains, ensure the [SOURCE_TEXT] is the exact, unredacted span so the human reviewer can validate the evidence without pulling the original document. The [HIGH_THRESHOLD] and [MEDIUM_THRESHOLD] values should match your organization's accepted risk tolerance—typically 0.95 and 0.80, respectively, for financial or clinical data.

This prompt is designed to sit at the boundary between automated extraction and human review. It should be invoked only after an extraction attempt has been made and the system has determined—via a confidence threshold check—that the record requires human sign-off. The prompt expects a structured extraction payload, including per-field confidence scores and source spans, and produces a complete approval request ready for a review queue. Do not call this prompt for records that pass automated confidence gates; doing so wastes review capacity and introduces unnecessary latency.

Wire the prompt into your pipeline as a post-extraction step within the escalation branch. The input to this prompt should be assembled from the upstream extraction output: the raw extracted fields, their confidence scores, the source document identifier, and any ambiguity flags. Validate the prompt's output against a strict schema before routing to the review queue. At minimum, confirm that the approval_request object contains a non-empty summary, a confidence_details block with per-field scores, a risk_notes array, and a response_options object with approve, reject, and correct actions. If validation fails, retry once with a more explicit instruction to fill missing fields; if it fails again, log the malformed output and escalate to an on-call engineer rather than routing a broken payload to a reviewer.

For production use, pair this prompt with a model that supports structured output (e.g., GPT-4o with response_format or Claude with tool-use for the approval schema). Set temperature to 0 to maximize consistency in the generated approval payload. Log every approval request and the reviewer's eventual decision to build a feedback loop: compare the model's confidence assessment against actual reviewer corrections to detect calibration drift. Avoid using this prompt for high-volume, low-risk fields where the cost of human review exceeds the cost of an occasional error—reserve it for compliance-sensitive, financial, or safety-critical extractions where an incorrect automated decision carries real consequences.