Missing Signature Block Detection Prompt

This prompt is designed for document automation engineers who need to programmatically verify whether agreements have been fully executed. It detects signature blocks within a document, determines the execution status of each block (signed, unsigned, or missing entirely), and cross-references found signatures against a list of required signatories. The prompt distinguishes between wet-ink signatures, digital signature placeholders, typed names that may or may not constitute valid e-signatures, and completely absent blocks. Use this when your ingestion pipeline must route incomplete documents for human review before downstream processing, or when you need an audit trail of execution completeness. This prompt belongs in the document validation layer, after text extraction but before contract data is committed to a system of record.

Deploy this prompt when you have a known list of required signatories and need structured output that downstream systems can act on—such as a JSON payload with status fields per signatory (signed, unsigned, missing_block, ambiguous), page references, and confidence scores. It is appropriate for post-OCR text, native digital PDFs, and mixed document sets where execution completeness determines routing. The prompt expects pre-extracted document text and a signatory list as inputs. Do not use this prompt for handwriting analysis on raw image files without OCR, for documents where the list of required signatories is unknown or must be inferred, or for wet-ink verification that requires forensic image comparison. Those tasks require specialized vision models or human review.

Before wiring this into production, define your tolerance for false negatives on missing signatures. A missed unsigned block that proceeds to downstream systems can create legal exposure, while an overly aggressive flagging strategy floods the human review queue. Start by running the prompt against a golden dataset of 50–100 documents with known execution statuses, and measure precision and recall per signatory. Pay particular attention to documents where signature blocks appear on different pages than expected, where signatory names have minor variations from the required list, or where digital signature widgets are present but not yet applied. These edge cases are the most common failure modes. If your document set includes contracts with complex multi-party execution blocks, schedules signed separately, or counterparty signature pages that arrive as separate files, you will need to compose this prompt with a multi-document assembly step before execution checking.

This template is designed to be copied directly into your prompt management system or application code. It uses square-bracket placeholders for all document-specific values, allowing you to swap in the target agreement text, expected signatory list, and output format requirements without rewriting the core instruction logic. The prompt is structured to produce a machine-readable JSON output that your downstream validation and routing systems can consume directly.

textCopy
You are a document analysis engine specialized in detecting and evaluating signature blocks in executed agreements.

## INPUT
Document text extracted from [DOCUMENT_TYPE]:

[DOCUMENT_TEXT]

codeCopy

## EXPECTED SIGNATORIES
[EXPECTED_SIGNATORIES_LIST]

## OUTPUT_SCHEMA
Return a valid JSON object with this exact structure:
{
  "document_id": "[DOCUMENT_ID]",
  "signature_blocks_detected": [
    {
      "block_id": "string",
      "page_number": number or null,
      "signatory_name": "string or null",
      "signatory_title": "string or null",
      "organization": "string or null",
      "signature_type": "wet_ink | digital | typed_name | stamp | initials | illegible | absent",
      "execution_status": "signed | unsigned | unclear",
      "date_signed": "string or null",
      "block_text_excerpt": "string",
      "confidence": number (0.0 to 1.0)
    }
  ],
  "missing_required_signatories": [
    {
      "expected_name": "string",
      "expected_role": "string",
      "detection_status": "not_found | found_but_unsigned | found_but_unclear",
      "notes": "string"
    }
  ],
  "overall_execution_status": "fully_executed | partially_executed | not_executed | unclear",
  "flags": ["string"],
  "processing_notes": "string"
}

## CONSTRAINTS
1. Distinguish digital signatures (cryptographic, certificate-based) from typed names (plain text that looks like a name in a signature block). Digital signatures should have signature_type "digital". Typed names without cryptographic evidence should have signature_type "typed_name".
2. A signature block exists even if unsigned. Mark execution_status as "unsigned" when a block is present but no signature, mark, or date is visible.
3. If a signatory from EXPECTED_SIGNATORIES is not found in any detected block, include them in missing_required_signatories with detection_status "not_found".
4. If a signatory is found but their block shows execution_status "unsigned" or "unclear", include them in missing_required_signatories with the appropriate detection_status.
5. Set confidence based on text clarity, OCR quality, and ambiguity. Use confidence below 0.7 when the text is partially illegible or the signature type is ambiguous.
6. Include the raw text excerpt from the document that contains the signature block in block_text_excerpt for auditability.
7. If no signature blocks are found at all, return an empty signature_blocks_detected array, list all expected signatories in missing_required_signatories, and set overall_execution_status to "not_executed".
8. Do not infer signatory names from document headers, footers, or body text outside the signature block area.

## RISK_LEVEL
[HIGH] - False negatives (missing an unsigned required signatory) can cause legal and compliance exposure. When uncertain, flag for human review rather than marking as signed.

To adapt this template, replace each square-bracket placeholder with your document-specific values. [DOCUMENT_TYPE] should describe the agreement type (e.g., "Master Services Agreement", "Employment Contract") to help the model apply domain-appropriate expectations. [EXPECTED_SIGNATORIES_LIST] should be a structured list of names and roles that must sign for the document to be considered fully executed. If you don't have an expected signatory list, replace the entire EXPECTED SIGNATORIES section with an instruction to detect all signatories present and skip the missing_required_signatories check. [DOCUMENT_ID] should be a unique identifier from your document management system for traceability in logs and audit trails.

Before deploying this prompt to production, validate the output against your schema using a JSON schema validator. Run the prompt against a golden dataset of at least 20 documents with known signature statuses, including edge cases: documents with digital signatures, documents with typed names only, documents with illegible signature blocks, documents with no signature blocks, and documents where signatories signed in non-standard locations. Measure false negative rate on unsigned required signatories as your primary success metric. If the false negative rate exceeds your risk tolerance, add few-shot examples to the prompt showing ambiguous cases and the correct determination, or implement a human review step for all documents where overall_execution_status is not "fully_executed".

The Missing Signature Block Detection Prompt is designed to operate as a post-extraction validation step in a document processing pipeline. It should run after layout-aware text extraction and form field detection have already identified candidate signature regions on the page. The prompt expects structured input describing each candidate block's visual position, text content, and any detected annotations or stamps. Do not feed raw page images or unstructured OCR output directly to this prompt—pre-process the document to isolate signature-relevant regions first. The prompt's job is to classify execution status, not to perform layout analysis or OCR.

Wire this prompt into your pipeline as a gated validation stage. After the model returns its classification for each signature block, apply a post-processing validator that checks: (1) every required signatory from the document's expected signatory list has a corresponding block in the output, (2) no block is classified as signed without an explicit signature indicator (wet ink trace, digital certificate metadata, or /Sig PDF annotation), and (3) typed names without cryptographic evidence are never classified as signed. If the validator catches a mismatch, log the discrepancy with the document ID, page number, block coordinates, model classification, and validator rejection reason. For high-stakes agreements, route any unsigned or missing classification for a required signatory to a human review queue before the document proceeds downstream. Use a structured logging format (JSON) so your observability stack can track false-positive and false-negative rates over time.

For model choice, prefer a model with strong instruction-following and structured output capabilities. The prompt's output schema is strict, so enable structured output mode (JSON mode or function calling with a typed response schema) rather than relying on free-text parsing. Set temperature=0 to minimize classification variance. Implement a retry policy with up to two retries if the output fails schema validation; if validation still fails, escalate the entire document for human review rather than silently accepting a malformed classification. For documents with digital signature fields (e.g., DocuSign, Adobe Sign), integrate a pre-check that reads the PDF's digital signature dictionary before invoking the prompt—cryptographically verified signatures can bypass the model entirely, reserving the prompt for wet-ink and image-based signature detection where visual judgment is required.

Build your eval harness before deploying. Create a golden dataset of at least 50 signature blocks spanning: wet-ink signatures, digital signatures with visible stamps, typed names without signatures, blank signature lines, and cropped or partially visible blocks. Measure precision and recall per class (signed, unsigned, missing), with special attention to false signed classifications—these are the highest-risk errors because they can cause unsigned contracts to proceed as if executed. Run the eval suite on every prompt or model version change. If your pipeline processes scanned documents with degraded quality, include low-resolution and noisy samples in your eval set to catch regression on real-world inputs.