Legal Clause Extraction Prompt for M&A Contracts

This prompt is designed for legal operations teams and contract analysts who need to extract structured clause records from merger and acquisition agreements. It targets the high-stakes workflow of M&A due diligence, where missing a material adverse change clause or misidentifying a termination right can carry significant financial and legal consequences. Use this prompt when you need a machine-readable inventory of key provisions, complete with full clause text, categorization, risk flags, and page citations. It is built for integration into a document processing pipeline where a human reviewer will validate outputs before they reach a decision-maker.

The ideal deployment context is a batch or streaming document ingestion system where each agreement is chunked, processed, and the extracted clauses are written to a review queue. The prompt expects a single, self-contained contract section as input—do not pass an entire 200-page purchase agreement in one call. You must provide a defined taxonomy of clause types (e.g., 'Material Adverse Change,' 'Termination Rights,' 'Indemnification') and a risk taxonomy (e.g., 'Unilateral Termination,' 'Uncapped Liability') as part of the [CONSTRAINTS] or [OUTPUT_SCHEMA] placeholder. The prompt will return a JSON array of clause objects, each with clause_type, full_text, risk_flags, page_citation, and a confidence score. A human reviewer must confirm or reject each extracted record before it enters a deal summary or risk matrix.

Do not use this prompt for generating legal advice, interpreting clause meaning, or making deal recommendations. It is an extraction tool, not a replacement for legal judgment. It will not catch novel or highly bespoke clause structures that fall outside the provided taxonomy. If a standard clause is missing from the document, the prompt will flag it as status: 'missing' rather than hallucinating text. Always pair this prompt with a validation layer that checks for schema compliance, missing required fields, and low-confidence extractions before routing records to human review. In regulated or litigation-sensitive contexts, ensure every extracted record retains its source page citation for auditability.

This template is the core instruction set for an AI model to act as a precise legal clause extraction engine. It is designed to be strict: it demands verbatim text, rejects summarization, and requires the model to explicitly handle missing clauses and cross-references. The placeholders—[AGREEMENT_TEXT], [CLAUSE_TAXONOMY], [RISK_FLAG_TAXONOMY], and [OUTPUT_SCHEMA]—are the dynamic inputs your application must supply at runtime. Do not treat this as a conversational prompt; it is a machine-to-machine contract where the output must be valid, parseable JSON that conforms to the provided schema.

textCopy
Extract the following M&A contract clauses from the provided agreement text. Return a valid JSON object with a `clauses` array. For each clause found, include the clause category, a unique clause identifier, the full verbatim text of the clause, the starting page number, and any risk flags from the provided taxonomy. If a standard clause category is not present in the agreement, include it in a `missing_standard_clauses` array with a note. If a clause references another section, capture that cross-reference. Do not summarize or paraphrase clause text. Do not invent clauses not present in the source. If the text is ambiguous, set a `confidence` score between 0.0 and 1.0 and add an `ambiguity_note`.

[AGREEMENT_TEXT]

[CLAUSE_TAXONOMY]

[RISK_FLAG_TAXONOMY]

[OUTPUT_SCHEMA]

To adapt this template, start by defining your [CLAUSE_TAXONOMY] as a structured list of categories like ["Representations and Warranties", "Indemnification", "Material Adverse Change (MAC)"]. The [RISK_FLAG_TAXONOMY] should be a similar list of flags such as ["Uncapped Liability", "Double Materiality Trigger", "Survival Period > 18 Months"]. The [OUTPUT_SCHEMA] placeholder is critical for downstream reliability; replace it with a strict JSON Schema definition that includes required fields, types, and enum constraints for categories and risk flags. This ensures the model's output can be validated programmatically before it ever touches your database.

Before deploying, test this prompt against a golden dataset of 20-30 annotated M&A agreements. Measure extraction recall (did it find all clauses?), precision (did it hallucinate any?), and schema compliance (is the JSON valid?). A common failure mode is the model paraphrasing long clauses instead of extracting them verbatim; if you observe this, strengthen the constraint by adding a line: You will be penalized for paraphrasing. The 'clause_text' field must be a character-perfect substring of the source. Always log the raw model output and the final validated JSON for auditability, especially in legal workflows where provenance is non-negotiable.

This prompt is designed for a document processing pipeline, not a conversational interface. The agreement text should be pre-processed to extract clean text with page markers before reaching the model. Use a structured output API (such as OpenAI's response_format with a JSON schema or a tool call with a strict schema) to enforce the output contract. After receiving the model response, validate the JSON against your schema. Check that every page field contains a number present in the source text. Check that every clause_text is a substring of the source agreement (or flag it for human review).

Log every extraction with the model version, prompt version, and agreement identifier. Route extractions with confidence below 0.8 to a human review queue. Never insert extracted clauses into a database or clause library without human approval. This is a high-stakes domain where errors can affect deal terms. Consider implementing a two-pass architecture: first extract clause candidates, then run a second verification pass that confirms each extraction against the source text and adjusts confidence scores.

For production deployment, implement retry logic with exponential backoff for transient API failures. Cache the pre-processed agreement text to avoid re-processing on retry. Monitor extraction completeness by tracking the ratio of expected clause types found versus missing. Set up alerts for schema validation failures, which often indicate prompt drift or model behavior changes. Always version your prompts and run regression tests against a golden set of agreements before deploying changes.