Document Set Gap Analysis Prompt

This prompt is designed for compliance engineers and legal operations teams who need to systematically identify missing provisions across a portfolio of documents. The core job-to-be-done is not just reading what's present, but proving what's absent. The ideal user is an AI engineer or technical operator building a compliance review pipeline who needs a structured, machine-readable gap report that can be fed into a governance, risk, and compliance (GRC) system. The required context includes a target document set, a defined inventory of expected provisions (a checklist, policy, or master agreement), and clear rules for what constitutes a 'gap' versus an intentional omission.

Use this prompt when you have a known standard or requirement against which you are auditing a document set, such as checking a vendor contract portfolio against an updated corporate data protection addendum (DPA) template, or verifying that all loan agreements in a package contain the latest regulatory boilerplate. The prompt is designed to produce a structured output with explicit 'absence evidence'—citing the sections that were searched and found to be missing—rather than a simple negative claim. This is critical for audit trails. Do not use this prompt for comparing two documents for textual differences; that is a redline comparison task. Do not use it to reconcile conflicting clauses; that is a reconciliation task. This prompt is specifically for the 'expected-but-not-found' pattern.

Before implementing, you must define your expected provisions inventory with enough precision that absence is a meaningful finding. A vague instruction like 'check for data protection clauses' will produce noisy, low-confidence results. Instead, provide a structured list of specific provisions, such as 'Data Processing Purpose Limitation clause,' 'Cross-Border Data Transfer Mechanism (e.g., SCCs),' and 'Subprocessor Notification Obligation.' The prompt's value scales with the specificity of this input. If your expected provisions are ambiguous, you will get false-positive gaps that waste reviewer time and erode trust in the system. Pair this prompt with a human review step for any gap classified as 'High' risk before it is reported to a business stakeholder.

This prompt template is designed to be dropped into your application's prompt assembly layer. It instructs the model to act as a compliance analyst, comparing a provided document set against a known inventory of required provisions. The output is a structured gap report, not a conversational summary. Every finding must be tied to a specific expected provision and supported by evidence of absence from the source documents. The template uses square-bracket placeholders for all dynamic inputs, making it safe to populate programmatically before each inference call.

textCopy
You are a compliance gap analyst. Your task is to compare a set of provided documents against a list of required provisions and identify what is missing.

## REQUIRED PROVISIONS
[REQUIRED_PROVISIONS]

## DOCUMENT SET
[DOCUMENTS]

## INSTRUCTIONS
1. For each provision in the REQUIRED_PROVISIONS list, determine if it is present in the DOCUMENT SET.
2. If a provision is present, cite the document name, section, and paragraph where it appears.
3. If a provision is absent, classify the gap severity as CRITICAL, HIGH, MEDIUM, or LOW based on [RISK_CLASSIFICATION_RULES].
4. For each gap, provide a remediation recommendation.
5. If a provision is partially addressed, explain what is covered and what is missing.
6. Do not invent provisions that are not in the REQUIRED_PROVISIONS list.
7. If a document is illegible, ambiguous, or contains conflicting information, flag it with an UNCERTAINTY note instead of guessing.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "analysis_metadata": {
    "documents_reviewed": ["string"],
    "provisions_evaluated": number,
    "gaps_found": number,
    "uncertainty_flags": number
  },
  "findings": [
    {
      "provision_id": "string",
      "provision_description": "string",
      "status": "PRESENT" | "ABSENT" | "PARTIAL",
      "source_citation": {
        "document": "string | null",
        "section": "string | null",
        "paragraph": "string | null",
        "excerpt": "string | null"
      },
      "gap_severity": "CRITICAL" | "HIGH" | "MEDIUM" | "LOW" | null,
      "gap_rationale": "string | null",
      "remediation": "string | null",
      "uncertainty_note": "string | null"
    }
  ]
}

## CONSTRAINTS
- Only use provisions from the REQUIRED_PROVISIONS list.
- Do not hallucinate document sections or paragraph numbers.
- If you cannot determine presence or absence with high confidence, set status to "PARTIAL" and include an uncertainty_note.
- For ABSENT provisions, source_citation fields must be null.
- Gap severity must follow [RISK_CLASSIFICATION_RULES].

To adapt this template, replace each placeholder with application-supplied data. [REQUIRED_PROVISIONS] should be a structured list of provision objects, each with an ID and description. [DOCUMENTS] should contain the full text of each document, prefixed with a document identifier and section markers if available. [RISK_CLASSIFICATION_RULES] should define your organization's severity taxonomy—for example, classifying the absence of a regulatory-mandated clause as CRITICAL and a best-practice recommendation as LOW. Before deploying, run this prompt against a known gap inventory to measure false-positive and false-negative rates, and implement a post-processing validator that checks every finding's provision_id against the input list to catch hallucinations.

The gap analysis prompt is designed to operate as a batch inference step within a document processing pipeline, not as a standalone chat interaction. Each invocation should receive a single document's text content, a structured list of expected provisions, and any domain-specific constraints. The prompt returns a structured gap report that downstream systems can parse, store, and route for review. Because gap analysis carries compliance risk, the implementation must include schema validation, confidence scoring, and a human review queue for any gap flagged above a configurable severity threshold.

Wire the prompt into your application using a three-stage harness: (1) Pre-processing extracts document text and normalizes the expected provisions list into the [EXPECTED_PROVISIONS] placeholder format. (2) Inference calls the model with the populated prompt template, requesting the [OUTPUT_SCHEMA] as a JSON array of gap objects. Set temperature=0 and response_format to JSON mode if your provider supports it. (3) Post-processing validates each gap object against the schema—checking that provision_name matches an entry in the expected list, absence_evidence contains a non-empty string with a document citation, and risk_classification is one of the allowed enum values. Any gap that fails validation should trigger a single retry with the validation error injected into the [CONSTRAINTS] field. If the retry also fails, route the document to a human review queue with the raw model output and validation errors attached.

For evaluation and monitoring, maintain a golden dataset of documents with known gap inventories. Run the prompt against this dataset on every prompt change and log precision, recall, and false-positive rate for gap detection. Pay special attention to false-positive gaps—where the model flags a provision as missing when it is actually present under different wording. These are the most common failure mode and erode reviewer trust. Log every gap flag to your observability platform with the document ID, provision name, risk classification, and whether the gap was confirmed or dismissed on human review. Use this feedback to calibrate the [RISK_LEVEL] threshold that determines which gaps auto-escalate. Avoid running this prompt on documents exceeding the model's context window without first chunking by section and aggregating results, as mid-document truncation produces silent false negatives.