Absent Clause Detection Prompt for Legal Documents

This prompt is built for legal engineering teams who need to programmatically verify whether a contract contains specific provisions from a predefined checklist. The job-to-be-done is not general contract review; it is a targeted binary classification task: for each expected clause, return a presence or absence determination with a precise section citation when found, and an explicit 'not found' marker with the search scope when absent. The ideal user is a developer or legal operations engineer integrating this into a contract intake pipeline, a due diligence workflow, or a post-execution compliance check where missing clauses carry material risk.

You should use this prompt when you have a known, finite checklist of clauses to verify—such as governing law, indemnification, limitation of liability, data privacy, termination rights, or payment terms—and you need structured, auditable output per clause. The prompt requires two inputs: the full contract text and a structured checklist of expected clauses with optional descriptions to handle reworded or implied provisions. It is designed to reduce false absences by instructing the model to search for semantic equivalents, not just exact string matches, and to report the search scope when a clause is not found. This matters in production because a silent 'not found' on a reworded indemnification clause can cause a downstream risk system to flag a contract as non-compliant when the provision is actually present under different language.

Do not use this prompt when you need a full contract risk assessment, negotiation advice, or legal interpretation of clause adequacy. It does not evaluate whether a found clause is favorable, enforceable, or complete—only whether it is present or absent. Do not use it for documents where the clause checklist is unknown or unbounded; the prompt's value comes from explicit, pre-defined expectations. For high-stakes workflows, always pair this prompt with human review of any 'not found' determinations, and implement eval checks that test the model against reworded clauses, cross-referenced provisions, and clauses split across multiple sections. The next section provides the copy-ready prompt template you can adapt to your clause checklist and output schema.

This prompt template is designed to be dropped into a legal document review pipeline. It accepts a contract text and a checklist of expected clauses, then returns a structured determination for each clause: present with a supporting citation, or absent with an explicit marker and the search scope that was examined. The template uses square-bracket placeholders for all variable inputs, making it straightforward to parameterize in code before sending to the model.

textCopy
You are a legal document analyst. Your task is to review a contract and determine whether specific clauses are present or absent.

## INPUT
Contract text:
[CONTRACT_TEXT]

Clause checklist:
[CLAUSE_CHECKLIST]

## INSTRUCTIONS
For each clause in the checklist, perform the following:
1. Search the entire contract text for the clause, including reworded, implied, or distributed versions of the clause across multiple sections.
2. If the clause is found, set status to "present" and provide the exact section reference and a short verbatim quote as evidence.
3. If the clause is not found after thorough search, set status to "absent" and provide the search scope examined (e.g., "searched all sections; no governing law provision located").
4. If the clause is partially present or ambiguous, set status to "partial" and explain what is present and what is missing.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "results": [
    {
      "clause_name": "string",
      "status": "present" | "absent" | "partial",
      "citation": "string | null",
      "evidence": "string | null",
      "search_scope": "string",
      "notes": "string | null"
    }
  ],
  "summary": {
    "total_checked": number,
    "present_count": number,
    "absent_count": number,
    "partial_count": number
  }
}

## CONSTRAINTS
- Do not mark a clause as absent without first searching for reworded equivalents, synonyms, and distributed clause structures.
- For "absent" results, the citation and evidence fields must be null.
- For "present" results, the search_scope field should still describe where the clause was located.
- If the contract text is too short to contain meaningful clauses, flag this in the notes field of each result.
- Do not invent clauses that are not in the checklist.
- Do not provide legal advice or interpretation beyond presence/absence determination.

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace each square-bracket placeholder with the appropriate value for your workflow. [CONTRACT_TEXT] should contain the full text of the document under review, cleaned of artifacts but preserving section numbering and headings. [CLAUSE_CHECKLIST] should be a structured list of clause names or descriptions, ideally generated from your organization's contract standards or playbook. [RISK_LEVEL] can be set to values like high, medium, or low to adjust the model's caution; for high-risk reviews, add an explicit instruction such as 'When risk_level is high, flag any ambiguous clause as partial and recommend human review.' Before deploying, validate the output against the expected JSON schema and run eval checks for false absences on reworded clauses, which is the most common failure mode in production.

After copying the template, wire it into your application with a JSON schema validator that rejects malformed outputs and triggers a retry. For high-stakes contract review, always route absent and partial results to a human review queue before taking action. Log every determination with the model version, timestamp, and raw output for auditability. If your clause checklist exceeds 20 items, consider batching the review across multiple calls to avoid context-window truncation that silently drops clauses from the output.

The absent clause detection prompt is designed to operate as a stateless function within a larger document processing pipeline. Each invocation receives a single clause name and a document chunk, returning a structured presence/absence determination. In production, you will typically fan out multiple clause checks in parallel across a document, then aggregate results into a compliance report. The prompt's output schema—with explicit status, citation, search_scope, and confidence fields—is designed to be machine-readable first, enabling downstream filtering, scoring, and review queue routing without manual parsing.

Validation and retry logic is critical because false absences are the primary failure mode. Implement a post-processing validator that checks: (1) the status field is exactly present, absent, or ambiguous; (2) when status is present, the citation field contains a non-empty section reference and the evidence_text field contains a verbatim quote from the source; (3) when status is absent, the search_scope field describes what was searched and the confidence field is populated. If validation fails, retry the prompt once with the validation error appended as a [CORRECTION_NOTE] in the constraints. After two failures, route to a human review queue with the original document chunk, the clause name, and both failed attempts logged. For high-stakes contracts, consider requiring human sign-off on all absent determinations above a confidence threshold of 0.85.

Model choice and context window considerations: Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or equivalent. The prompt is designed to work within a single document chunk, so ensure your chunking strategy preserves complete sections and avoids splitting clauses mid-sentence. If a clause is expected to span multiple chunks, use a sliding window with overlap and deduplicate results by normalizing citation references. For documents exceeding 100 pages, consider a two-pass approach: first use a lightweight classifier to identify candidate sections, then run the absent clause detection prompt only on those sections to reduce token costs.

Logging and observability should capture: the clause name, document identifier, chunk index, model response, validation result, retry count, and final determination. This trace data is essential for debugging false absences and for producing audit evidence when the system is used in regulatory or litigation contexts. Store raw prompt-response pairs for at least 30 days to support prompt regression testing. When you update the prompt template, run the new version against a golden dataset of 50-100 clause-document pairs with known presence/absence labels, and compare false-absence rates before promoting to production.

Integration pattern: Wrap the prompt in a function with the signature check_clause(clause_name: str, document_chunk: str, context: dict) -> ClauseResult. The context dict should carry metadata like document type, jurisdiction, and governing law to help the model interpret reworded clauses. Call this function in parallel for each clause in your checklist using an async executor with a concurrency limit matching your API rate limits. Aggregate results into a compliance matrix where rows are clauses and columns include status, citation, confidence, and review flag. Route any row with review_required: true to a human-in-the-loop queue before finalizing the report.