Signature Presence Detection Prompt

This prompt is designed for engineering teams building e-signature verification, document completeness, and automated intake pipelines. Its primary job is to detect the presence of signatures on a document page, classify their type (wet ink, digital, or stamp), and return their location with a confidence score. The ideal user is a developer or ML engineer who needs a reliable, binary detection step before routing a document for further processing or human review. You should use this prompt when the goal is to answer 'Is there a signature here, and what kind?' rather than validating the signature's legal authenticity or comparing it against a known sample.

The prompt requires a clear image of a document page as input, along with a defined output schema and a confidence threshold for flagging uncertain results. It is built to handle common production challenges: distinguishing real signatures from printed signature images, ignoring decorative elements and logos, and correctly identifying stamps that overlap with text. However, it is not a replacement for cryptographic signature validation or forensic handwriting analysis. Do not use this prompt to verify the identity of a signatory or to make legally binding determinations about a document's execution status without a human review step.

Before integrating this prompt, define your tolerance for false positives on logos, initials, and printed text that mimics a signature. The accompanying evaluation harness should include test cases for these specific failure modes. If your pipeline processes multi-signature pages, ensure your implementation can handle multiple detection boxes in a single response. For high-stakes workflows, always route low-confidence detections to a human review queue and log the model's raw output alongside the final decision for auditability.

This prompt template is designed for integration into document processing pipelines that need to determine whether a signature is present on a page, where it is located, and what type of signature it is. The template uses square-bracket placeholders that must be replaced with actual values at runtime. The core instruction set is self-contained and can be copied directly into your application's prompt layer. The model is instructed to perform a strict binary detection task, avoiding false positives on logos, initials, and decorative elements, which are the most common failure modes in production.

textCopy
You are a document analysis system specialized in signature detection. Your task is to analyze the provided document page and determine if a signature is present.

## INPUT
[INPUT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "page_number": integer,
  "signatures": [
    {
      "signature_id": "string",
      "present": boolean,
      "type": "wet_ink" | "digital" | "stamp" | "unknown",
      "bounding_box": {
        "x": number,
        "y": number,
        "width": number,
        "height": number,
        "unit": "pixel" | "normalized"
      },
      "confidence": number (0.0 to 1.0),
      "evidence": "string describing visual evidence for the classification"
    }
  ],
  "false_positive_risks": [
    {
      "region": "string describing the region",
      "risk": "logo" | "initials" | "printed_text" | "decorative" | "other",
      "reason": "string explaining why this region is not a signature"
    }
  ]
}

## INSTRUCTIONS
1. Scan the entire page for any marks that could be signatures.
2. For each candidate region, classify it as a signature or a false-positive risk.
3. A signature is a hand-drawn mark representing a person's name or mark of approval. It is typically cursive, stylized, and placed in a designated signature block.
4. Do NOT classify the following as signatures: typed names, initials in text fields, company logos, decorative borders, checkmarks, or printed signature images that are clearly part of the document template.
5. If a printed signature image is present, classify it as "digital" only if it appears to be an applied signature (e.g., a scanned wet-ink signature or a cryptographic digital signature representation). If it is part of the pre-printed form, flag it as a false-positive risk with risk type "printed_text".
6. For each detected signature, provide a bounding box in the unit specified by [COORDINATE_UNIT].
7. Confidence should reflect the certainty of the detection. Reduce confidence when signatures overlap with text, are partially obscured, or are very faint.
8. If no signatures are found, return an empty `signatures` array and populate `false_positive_risks` with any regions that might be mistaken for signatures.

## EXAMPLES
[EXAMPLES]

To adapt this template for your pipeline, replace the placeholders as follows: [INPUT] should contain the document page image or extracted text and layout data, depending on your model's modality. [CONSTRAINTS] can be used to inject domain-specific rules, such as "Signatures are only valid in the designated signature block on page 4" or "A valid document must have exactly two signatures." [EXAMPLES] should include one-shot or few-shot examples of your specific document type, showing both positive and negative cases. [COORDINATE_UNIT] should be set to "pixel" if your downstream system uses pixel coordinates, or "normalized" (0.0 to 1.0) for resolution-independent processing. If your application requires a specific risk level, add a [RISK_LEVEL] placeholder to the constraints section to adjust the model's sensitivity. For high-stakes workflows such as legal admissibility or financial transactions, always route low-confidence detections (confidence < 0.85) to a human review queue and log the evidence field for auditability.

The Signature Presence Detection Prompt is designed to operate as a single step within a larger document processing pipeline, not as a standalone application. It expects a pre-processed image of a document page or signature block region, typically extracted by an upstream layout analysis or field boundary detection step. The prompt returns a structured JSON payload containing binary presence, location coordinates, type classification, and confidence scores. This output should be consumed by a downstream validation layer before any business logic acts on the result.

Wire the prompt into your application using a standard model invocation pattern with structured output constraints. For OpenAI-compatible APIs, set response_format to json_schema and provide the expected output schema. For other providers, include the schema inline in the prompt's [OUTPUT_SCHEMA] placeholder and enforce JSON mode. Implement a validation wrapper that checks the returned JSON against the schema, verifies bounding box coordinates fall within page dimensions, and confirms confidence scores are in the 0.0–1.0 range. If validation fails, retry once with the validation error message appended to the prompt context. After a second failure, route the page to a human review queue with the raw model output and error details attached.

Model choice matters for this task. Use a vision-capable model with strong spatial reasoning—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are appropriate starting points. Avoid text-only models that require pre-extracted OCR descriptions of the signature region; the prompt relies on direct visual inspection to distinguish wet ink from printed images. For high-throughput pipelines processing thousands of pages, consider a two-stage architecture: a fast, cheaper model for initial binary presence detection, followed by the full prompt only on pages that trigger a positive signal. Log every invocation with the input image hash, model version, raw response, validated output, and routing decision. This trace is essential for debugging false positives on logos, initials, and decorative elements—the most common production failure mode.

The eval harness for this prompt should include a golden dataset of at least 200 labeled page images covering wet ink signatures, digital signatures, stamps, printed signature images, initials, logos, blank signature blocks, and multi-signature pages. Run the prompt against this dataset on every model version change and prompt revision. Track precision and recall separately for each signature type, and set a minimum precision threshold of 0.95 for binary presence before allowing automatic routing. Pages with confidence scores between 0.5 and 0.8 should always route to human review, not to automated acceptance or rejection. Do not use the model's confidence score as a direct pass/fail gate without calibration against your eval dataset—raw confidence scores from vision models often require per-document-type calibration to align with actual accuracy.