Missing Field Detection in Compliance Documents Prompt Template

This prompt is designed for document processing pipeline teams who need to programmatically identify what is not present in a compliance document. The core job is to detect absent required fields, incomplete sections, redacted content, and illegible regions, and to produce explicit, machine-readable null or absence records. The ideal user is an engineering lead or developer integrating this prompt into an automated ingestion system where a silent missing value is a critical failure that can propagate into regulatory reports, audit trails, or downstream analytics.

Use this prompt when your system must distinguish between 'the field is present and empty,' 'the field is redacted,' 'the section is entirely missing,' and 'the text is illegible.' This is a high-stakes classification task, not a general extraction task. The prompt requires a pre-defined schema of required fields and sections, the full document text, and a clear severity classification policy. It is not suitable for open-ended document Q&A, summarization, or extracting values that are present. Do not use this prompt when you only need positive extraction; it is specifically designed to find and classify gaps.

Before implementing, ensure you have a strict, version-controlled schema of required elements, a human review queue for high-severity findings, and an eval set that includes documents with known missing, redacted, and illegible fields to test for false negatives. The primary failure mode is the model overlooking an absent field and returning no record, which is far more dangerous than a false positive that a human can dismiss. Always pair this prompt with a post-processing validator that checks whether every required field in your schema received an explicit status in the output.

This prompt template is designed to be dropped into a document processing pipeline where the goal is not just extraction, but explicit detection of absence. It instructs the model to scan a compliance document against a known schema and produce a structured record of what is present, what is missing, what is redacted, and what is illegible. The output is a list of field-level findings with severity classifications and location references, enabling downstream systems to route documents for human review or automated remediation without silent failures.

textCopy
You are a compliance document auditor. Your task is to compare the provided document against a required field schema and identify every instance of missing, incomplete, redacted, or illegible information.

## INPUT
Document: [DOCUMENT_TEXT]
Required Schema: [REQUIRED_SCHEMA]

## INSTRUCTIONS
1. Parse the document and locate every field defined in the Required Schema.
2. For each field, determine its status using these categories:
   - PRESENT: The field exists and contains a valid, legible value.
   - MISSING: The field is entirely absent from the document.
   - INCOMPLETE: The field exists but the value is truncated, partial, or fails to meet the schema's completeness rules.
   - REDACTED: The field or its value has been intentionally obscured, blacked out, or replaced with placeholder text (e.g., "[REDACTED]", "XXXX", black bars).
   - ILLEGIBLE: The field value cannot be read due to scan quality, handwriting, image artifacts, or corrupted text.
3. For every field that is not PRESENT, provide:
   - The exact field name from the schema.
   - The status (MISSING, INCOMPLETE, REDACTED, ILLEGIBLE).
   - A severity classification: CRITICAL, HIGH, MEDIUM, or LOW, based on [SEVERITY_RULES].
   - A location reference: page number, section heading, paragraph number, or approximate position where the field should have appeared.
   - A brief evidence snippet: the surrounding text or visual description that confirms the absence.
4. If a field is PRESENT, include it in the output with status PRESENT, the extracted value, and a location reference.
5. If the entire document is unreadable or appears to be the wrong document type, return a single top-level finding with status DOCUMENT_REJECTED and a reason.

## OUTPUT SCHEMA
Return a JSON object with this structure:
{
  "document_id": "[DOCUMENT_ID]",
  "audit_timestamp": "[TIMESTAMP]",
  "findings": [
    {
      "field_name": "string",
      "status": "PRESENT | MISSING | INCOMPLETE | REDACTED | ILLEGIBLE",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "location": {
        "page": "number or null",
        "section": "string or null",
        "paragraph": "number or null",
        "approximate_position": "string"
      },
      "extracted_value": "string or null",
      "evidence_snippet": "string"
    }
  ],
  "summary": {
    "total_fields": "number",
    "present_count": "number",
    "missing_count": "number",
    "incomplete_count": "number",
    "redacted_count": "number",
    "illegible_count": "number",
    "critical_findings": "number"
  }
}

## CONSTRAINTS
- Do not hallucinate field values. If a field is MISSING, extracted_value must be null.
- Do not guess at redacted content. If a field is REDACTED, extracted_value must be null and evidence_snippet must describe the redaction, not speculate about the hidden value.
- For ILLEGIBLE fields, do not attempt OCR repair. Report the illegibility and provide the approximate location.
- Every finding must include a location reference, even if approximate.
- If the document contains the field but in an unexpected format or location, still classify it as PRESENT and note the format deviation in evidence_snippet.
- Apply [SEVERITY_RULES] to determine severity. If no rules are provided, default to HIGH for missing required fields and MEDIUM for incomplete or illegible fields.

## EXAMPLES
[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your specific inputs. [DOCUMENT_TEXT] should contain the full extracted text of the compliance document, including any OCR output with confidence markers if available. [REQUIRED_SCHEMA] should be a structured list of field names, expected types, and completeness rules—this can be a JSON schema, a simple list, or a reference to a regulatory standard. [SEVERITY_RULES] defines which missing fields are critical versus low priority; for example, a missing "Filing Date" on an SEC submission might be CRITICAL while a missing "Optional Contact Email" might be LOW. [EXAMPLES] should include one or two few-shot demonstrations showing correct classification of missing, redacted, and illegible fields with appropriate severity assignments. If you are processing documents in a regulated domain, always route CRITICAL and HIGH severity findings for human review before taking automated action.

This prompt is designed to sit inside a document processing pipeline after text extraction and before structured data ingestion. The typical flow is: raw compliance document → text extraction (OCR or native PDF parsing) → chunking by section → this prompt applied to each section → output aggregation → validation → downstream system. The prompt expects pre-extracted text for a single document section, along with a list of required fields for that document type. Do not pass raw PDF bytes or entire multi-section documents in a single call; the model performs best when it can focus on one logical section at a time with a clear field checklist.

Wire the prompt into your application with a retry-and-escalate pattern. On the first call, request structured JSON output with response_format or equivalent tool-calling constraints. Validate the output immediately: check that every required field from the input checklist appears in the response with an explicit status (present, missing, redacted, illegible, or uncertain). If validation fails—missing fields in the output, malformed JSON, or status values outside the allowed enum—retry once with the same input plus the validation error message appended as context. If the second attempt also fails, route the section to a human review queue with the raw text, the field checklist, and both failed outputs attached. Log every attempt, validation result, and escalation decision for auditability.

For high-stakes compliance workflows, add a confidence threshold gate. The prompt returns a confidence score per field. Set a minimum threshold (start with 0.85 and tune based on your eval results) below which fields are automatically flagged for human review even if the model returned a status. This catches cases where the model reports a field as present but with low confidence, which often indicates borderline legibility or ambiguous formatting. Store the raw model response, the parsed output, and the human reviewer's final determination as a training artifact for future fine-tuning or few-shot example selection.

Model choice matters here. Use a model with strong instruction-following and structured output support—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that are more likely to silently drop fields from the output or hallucinate presence when text is ambiguous. If you must use a smaller model for cost or latency reasons, add a post-processing check that compares the number of fields in the output to the number in the input checklist and escalates any mismatch. Never assume a missing field in the output means the field is absent in the document; it may mean the model failed to process it.

When deploying this prompt into a production pipeline, build eval suites that specifically test for false-negative missing field detection—cases where a field is present in the document but the model reports it as missing. Create a golden dataset of compliance document sections with known field presence/absence, including edge cases like fields split across page breaks, fields in footnotes, fields referenced by acronym, and fields in scanned handwritten annotations. Run these evals on every prompt or model change before releasing. The most dangerous failure mode is silent null handling where the model omits a field entirely rather than explicitly marking it as missing, so your eval harness must detect output fields that are absent from the response rather than present with a missing status.