Automation Gate Decision Prompt for Extracted Records

This prompt is designed for downstream ingestion engineers and pipeline operators who need a final, programmatic gate check before extracted records are committed to a system of record. Its job is to consume a batch of extracted records—each with per-field confidence scores and a source document reference—and produce a deterministic accept, reject, or escalate decision for every record. The ideal user is integrating this prompt into an automated ETL or data ingestion harness where a human is not reviewing every row, but where the cost of a false acceptance (e.g., corrupting a financial ledger or patient record) is unacceptably high.

Use this prompt when you have already completed field extraction and confidence annotation, and you now need a consistent, auditable policy enforcement layer. The prompt requires structured inputs: a [RECORDS] array where each object contains extracted fields, per-field confidence scores, a schema compliance flag, and a [SOURCE_CONTEXT] snippet. You must also supply a [THRESHOLD_CONFIG] that defines the minimum acceptable confidence per field and a [RISK_TIER] mapping that classifies fields as low, medium, or high risk. The output is a strict [DECISION_PAYLOAD] containing a decision enum (ACCEPT, REJECT, ESCALATE), a justification string, and a list of violating fields. This is not a prompt for performing the extraction itself, nor is it for calibrating confidence scores; it assumes those upstream steps are complete and focuses solely on the gating logic.

Do not use this prompt when the extraction schema is still in flux, when confidence scores are unavailable or unreliable, or when the business logic for acceptance is too nuanced for a threshold-based rules engine. In those cases, a full human review workflow or a more sophisticated multi-factor evaluation prompt is required. Before deploying this prompt, you must validate its decisions against a golden dataset of pre-labeled accept/reject cases to prevent threshold misconfiguration and ensure that high-risk fields are never auto-accepted below their strict threshold. The next section provides the copy-ready template you will adapt and wire into your ingestion pipeline.

The following prompt template is designed to act as the final automation gate before extracted records are ingested into systems of record. It evaluates each record against a configurable confidence threshold, checks for schema compliance, and produces a structured decision with justification. The template uses square-bracket placeholders that you must replace with your specific extraction payload, schema definition, confidence thresholds, and business rules before use.

textCopy
You are an automation gate decision engine for extracted records. Your job is to evaluate each record and decide whether it should be accepted for automated ingestion, rejected outright, or escalated for human review.

## INPUT
You will receive an extracted record and its associated metadata.

[EXTRACTED_RECORD]

## SCHEMA DEFINITION
The expected schema for a valid record is defined below. Each field includes its type, nullability, and criticality level.

[SCHEMA_DEFINITION]

## CONFIDENCE THRESHOLDS
The following thresholds determine the decision path for each field and the overall record.

[CONFIDENCE_THRESHOLDS]

## BUSINESS RULES
Apply these rules when evaluating the record.

[BUSINESS_RULES]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "decision": "accept" | "reject" | "escalate",
  "overall_confidence": <0.0-1.0>,
  "justification": "<concise explanation of the decision>",
  "per_field_assessment": [
    {
      "field_name": "<string>",
      "value_extracted": "<string | null>",
      "confidence": <0.0-1.0>,
      "meets_threshold": <boolean>,
      "schema_compliant": <boolean>,
      "issues": ["<string>"]
    }
  ],
  "recommended_action": "<specific next step for the pipeline or reviewer>",
  "escalation_context": {
    "reason": "<primary reason for escalation, if applicable>",
    "priority": "low" | "medium" | "high" | "critical",
    "reviewer_queue": "<suggested queue name, if applicable>"
  }
}

## CONSTRAINTS
- Do not accept a record if any critical field is below its threshold or missing.
- Do not reject a record solely because optional fields are missing.
- If confidence for any field is below its threshold but above a minimum floor, escalate rather than reject.
- If the record structure does not match the schema definition, reject with a clear explanation.
- Justifications must cite specific fields, confidence scores, and threshold comparisons.
- Never invent or assume values for missing fields.

To adapt this template, replace each placeholder with your concrete definitions. The [EXTRACTED_RECORD] should be the JSON output from your extraction step. The [SCHEMA_DEFINITION] should enumerate every expected field with its type, whether it is required or optional, and its criticality level (e.g., critical, important, optional). The [CONFIDENCE_THRESHOLDS] should specify per-field minimum confidence scores for acceptance and a floor below which rejection occurs. The [BUSINESS_RULES] section is where you encode domain-specific logic, such as regulatory requirements that mandate human review for certain field types regardless of confidence, or cross-field validation rules that cannot be expressed in the schema alone.

Before deploying this prompt, test it against a golden dataset of records with known correct decisions. Pay particular attention to boundary cases where confidence scores sit exactly at the threshold, records with a mix of high-confidence and low-confidence fields, and malformed inputs that violate the schema. If your pipeline handles regulated data, ensure that the escalation path includes a mandatory human review step and that the justification field provides sufficient detail for audit trails.

The Automation Gate Decision Prompt is not a standalone script; it is a decision node inside a larger extraction pipeline. The typical integration pattern places this prompt after field extraction and confidence scoring, but before records are committed to a system of record. The harness should receive a batch of extracted records, each with per-field confidence scores, source spans, and the target schema. The prompt returns an accept/reject/escalate decision per record. The application layer must enforce that decision: accepted records proceed to ingestion, rejected records are logged and discarded (or routed to a dead-letter queue), and escalated records enter a human review workflow with the full context payload attached.

Validation is the first line of defense after the model responds. The harness must validate that every record in the input batch has a corresponding decision in the output, that each decision is one of the three allowed enum values (accept, reject, escalate), and that escalated records include a non-empty escalation_reason and reviewer_context object. If the output fails structural validation, retry once with the same prompt plus the validation error message appended as a [VALIDATION_ERROR] block. If the retry also fails, escalate the entire batch to a human operator with the raw model output and validation failure details. Never silently ingest records that failed gate validation.

Model choice matters for consistency. Use a model with strong instruction-following and structured output support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are reasonable defaults. Set temperature=0 to minimize decision variance across identical inputs. If your pipeline processes high-volume batches, consider caching gate decisions for records with identical field-confidence profiles to reduce cost and latency, but invalidate the cache if the confidence threshold configuration changes. Log every gate decision with the record ID, input confidence vector, model decision, and timestamp for auditability. For regulated domains, require a human sign-off on the first N escalated records each day to detect threshold drift before it becomes a systemic problem.

The escalation path must be concrete. When the prompt returns escalate, the harness should construct a review task containing the original source text, the extracted fields with confidence annotations, the model's escalation reason, and a structured response schema for the reviewer (accept, correct, or reject with corrected values). Route this task to the appropriate review queue based on the field types that triggered escalation—financial fields to the finance review queue, PII fields to the data governance queue, and so on. Track review turnaround time and reviewer decisions to feed back into confidence threshold tuning. If reviewers consistently override escalations to accept, your thresholds may be too conservative; if they frequently reject what the model accepted, your gate is too permissive.

Avoid wiring this prompt directly into a synchronous user-facing flow. Gate decisions should be asynchronous wherever possible. If a user is waiting for an extraction result, show the accepted fields immediately but hold escalated records in a pending state with a clear status indicator. Never block a user interface on a human review cycle without explaining the delay and providing a fallback. For batch ingestion pipelines, process gate decisions in parallel with a concurrency limit matching your model API rate limits, and use a dead-letter queue for any records that fail after the retry budget is exhausted.