Blank Form Field Detection Prompt

This prompt is designed for form processing pipeline engineers who need to programmatically determine the completion status of every field in a structured or semi-structured form. The core job-to-be-done is classifying each field as filled, empty, partially_filled, or placeholder to prevent silent data corruption downstream. The ideal user is building an automated document ingestion system where forms must be validated before their data enters a system of record, such as an insurance claim, a loan application, or a clinical intake form.

Use this prompt when you have a defined schema of expected fields and need a machine-readable completion report for each one. It is most effective when the form has clear field boundaries, such as underlined blanks, boxed input areas, or labeled sections in a digital or scanned PDF. The prompt requires you to provide the expected field list and the document text (or vision-based description of the form) as input. It is not suitable for free-form documents without a known field inventory, nor for forms where the primary challenge is handwriting recognition rather than blank detection. For those cases, pair this prompt with an OCR uncertainty scoring prompt or a layout-aware extraction prompt first.

Do not use this prompt as a substitute for a deterministic PDF parser when the form is a fillable PDF with an XFA or AcroForm data stream. In that scenario, extracting the raw field values programmatically is faster, cheaper, and perfectly accurate. This prompt adds value when the form is a scanned image, a flattened PDF, or a document where the visual representation of a blank is the only available signal. Before deploying, define your tolerance for false negatives (missing a truly blank required field) versus false positives (flagging a filled field as empty). The eval harness should include examples of intentional blanks, fields filled with 'N/A' or a dash, and fields where the text runs outside the visible box.

This prompt template is designed to be dropped into a form processing pipeline. It instructs the model to analyze a provided form image or extracted text, compare the detected fields against an expected schema, and classify each field's completion status. The output is a structured JSON object that downstream validation logic can consume directly, making it suitable for automated routing, human review queues, or database ingestion.

textCopy
You are an expert document analyst. Your task is to analyze a form and determine the completion status of every expected field.

## INPUT
- Form Content: [FORM_CONTENT]
- Expected Field Schema: [FIELD_SCHEMA]

## INSTRUCTIONS
1. For each field defined in the [FIELD_SCHEMA], locate its corresponding region in the [FORM_CONTENT].
2. Classify the field's status into exactly one of the following categories:
   - "complete": The field contains a valid, non-placeholder entry.
   - "blank": The field is visibly empty.
   - "placeholder": The field contains only placeholder text, instructions, or pre-printed examples (e.g., "First Name", "MM/DD/YYYY").
   - "illegible": The field contains content, but it cannot be read with confidence.
   - "not_found": The expected field does not appear to exist in the document.
3. For any status other than "complete", provide a brief "reason" explaining the determination.
4. If the [FIELD_SCHEMA] includes a "required" flag for a field, add a boolean "requires_review" property. Set it to `true` if a required field is not "complete".

## OUTPUT_SCHEMA
Return a single JSON object with a "fields" array. Each element must conform to this structure:
{
  "field_id": "string (from schema)",
  "status": "complete | blank | placeholder | illegible | not_found",
  "reason": "string (required if status is not 'complete')",
  "requires_review": boolean
}

## CONSTRAINTS
- Do not invent field values. Only report what is visible.
- If the entire form is blank or missing, report every field as "not_found" with an appropriate reason.
- Adhere strictly to the output schema. No additional commentary outside the JSON object.

To adapt this template, replace the [FORM_CONTENT] placeholder with the raw text, OCR output, or a structured representation of the form. The [FIELD_SCHEMA] placeholder should be replaced with a JSON array of objects, each containing at least a field_id and a required boolean. For high-stakes workflows such as legal intake or insurance claims, integrate the requires_review flag into a downstream routing rule that automatically queues non-complete required fields for human verification before the document proceeds further.

The Blank Form Field Detection Prompt is designed to sit inside a document ingestion pipeline after layout parsing and before structured data extraction. In a typical implementation, a PDF or image passes through an OCR or text extraction layer first. The extracted text and field bounding boxes are then fed into this prompt as structured context. The prompt's job is to classify each expected field as complete, partial, empty, or placeholder and return a machine-readable JSON payload. This classification step prevents downstream extraction prompts from hallucinating values for empty fields or misinterpreting placeholder text like 'N/A' or 'Enter name here' as real data. Wire this prompt as a synchronous step with a strict timeout (5-10 seconds for typical single-page forms) and a JSON schema validator immediately after the model response.

The implementation harness requires three components: a field registry, a validation layer, and a routing decision. First, maintain a field registry—a JSON or database record listing every expected field name, its required status, and acceptable completion states. Pass this registry into the prompt's [FIELD_DEFINITIONS] placeholder. After the model returns its classification, validate the output against a strict JSON schema that enforces the expected array of field objects with field_name, completion_status, confidence, and evidence keys. Reject any response that fails schema validation or contains fields not in the registry. For high-stakes workflows such as loan applications or medical intake forms, route any form where a required field is classified as empty or partial to a human review queue before allowing downstream processing. Log every classification result with the model's confidence score and the raw OCR text for auditability.

Model choice matters here. Use a model with strong instruction-following and JSON mode support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that struggle with structured output consistency. Set temperature=0 to maximize deterministic behavior. If processing high-volume forms, consider batching multiple forms into a single prompt call with clear delimiters, but keep each batch under 8,000 tokens of input context to avoid attention dilution. Implement a retry loop with exponential backoff (1s, 2s, 4s) for schema validation failures, but cap retries at 3 attempts. After the third failure, escalate the form to a human review queue with the raw OCR output and the failed model responses attached. Do not silently accept unvalidated classifications—a misclassified required field can corrupt an entire database row downstream.

Testing this prompt requires a golden dataset of forms with known completion states. Build at least 50 test forms covering: fully completed forms, intentionally blank forms, forms with placeholder text in every field, forms with partial handwriting, and forms with checkmarks or stamps that OCR may misinterpret. For each form, define the ground-truth classification per field. Run the prompt against this dataset and measure precision and recall for each completion state, with particular attention to false negatives on empty fields (the most dangerous failure mode). Add adversarial test cases: forms where 'N/A' is written in a required field, forms with watermarks that OCR picks up as text, and forms where the field label is present but the value area is blank. If your pipeline processes scanned documents, include degraded scans with varying DPI (150, 200, 300) to ensure OCR quality doesn't silently degrade classification accuracy.

Common failure modes in production include: the model classifying a faintly filled field as empty because OCR confidence was low, the model treating a handwritten 'none' as a valid entry when the field registry marks it as placeholder text, and schema mismatches where the model returns extra fields not in the registry. Mitigate the first by passing OCR confidence scores into the prompt's [OCR_METADATA] section. Mitigate the second by maintaining an explicit deny-list of placeholder strings in the [CONSTRAINTS] block. Mitigate the third with strict post-response schema validation. If your use case involves regulated documents such as tax forms or healthcare intake, add a human-in-the-loop approval step for any form where more than 20% of required fields are classified as empty or partial. This threshold prevents batch processing errors while keeping manual review load manageable.