Legal Clause Categorical Assignment Prompt Template

This prompt is designed for legal operations teams and contract review pipelines that need to classify extracted clauses into a controlled taxonomy at scale. Use it when you have already extracted clause text from a contract and need to assign it to categories such as indemnification, limitation of liability, termination, or governing law. The ideal user is an engineer or legal ops specialist integrating this prompt into an automated document processing system where consistent, auditable classification is required before downstream routing, summarization, or obligation tracking.

The prompt requires two concrete inputs: the raw clause text and a predefined taxonomy list. It returns a primary category, a confidence score, and a verbatim source citation. Do not use this prompt for drafting new clauses, providing legal advice, or making risk determinations. It is a classification tool, not a legal analysis engine. Human review is mandatory for low-confidence assignments and for any downstream decisions based on the classification output. In production, you should implement a confidence threshold gate—typically routing assignments below 0.85 to a human review queue—and log every classification with its source citation for auditability.

Before deploying, validate that your taxonomy is stable and mutually exclusive. Ambiguous or overlapping categories will degrade classification accuracy and produce inconsistent routing. Test the prompt against a golden dataset of at least 50 pre-labeled clauses covering edge cases like cross-referenced provisions, amended sections, and clauses with multiple potential categories. If your pipeline handles contracts from multiple jurisdictions, ensure your taxonomy accounts for jurisdictional variation in clause naming and structure. The next section provides the copy-ready prompt template you can adapt with your specific taxonomy and output schema.

This prompt template is designed to be pasted directly into your system instructions for a legal clause classification task. It expects that you have already extracted clause text from a contract and now need to assign it to a predefined taxonomy. The template uses square-bracket placeholders that you must replace with your specific taxonomy, clause text, and output schema before sending to the model. The prompt enforces strict output formatting, requires source text citation, and includes a confidence flag to support downstream human review workflows.

textCopy
You are a legal document classifier. Your task is to assign a single category from the provided taxonomy to the given clause text. You must also provide a confidence flag and cite the specific text that supports your classification.

## TAXONOMY
[TAXONOMY]

## CLAUSE TEXT
[CLAUSE_TEXT]

## OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "category": "string (must be one of the taxonomy values)",
  "confidence": "high|medium|low",
  "rationale": "string (brief explanation of why this category was chosen)",
  "source_citation": "string (exact quote from the clause text that supports the classification)",
  "alternative_categories": ["string (other taxonomy values that were considered but rejected)"]
}

## CONSTRAINTS
- Assign exactly one category from the taxonomy. Do not invent new categories.
- If the clause text is ambiguous or could fit multiple categories, choose the best fit and list others in alternative_categories.
- Set confidence to "low" if the clause text is ambiguous, incomplete, or could reasonably fit multiple categories.
- The source_citation must be a verbatim excerpt from the provided clause text.
- If the clause text does not clearly match any taxonomy category, set category to "other" and confidence to "low".
- Do not include any text outside the JSON object.

To adapt this template for your pipeline, replace [TAXONOMY] with your specific list of legal clause categories (e.g., indemnification, limitation_of_liability, termination, confidentiality, governing_law). Replace [CLAUSE_TEXT] with the extracted clause text your upstream process has already isolated. For high-risk legal workflows, always route low-confidence classifications to a human review queue. Before deploying, validate the output against your schema and test with edge cases such as ambiguous clauses, novel clause types not in your taxonomy, and clauses that span multiple categories.

This prompt is designed to operate as a single step within a larger contract processing pipeline. The typical integration pattern involves: (1) a document chunker that isolates individual clauses from a full contract, (2) this classification prompt applied to each clause chunk, and (3) a downstream aggregator that assembles classified clauses into a structured contract summary. The prompt expects a single clause text as [CLAUSE_TEXT] and a predefined taxonomy as [TAXONOMY]. The taxonomy should be injected as a JSON array of category objects, each with a category name and description field to guide the model's assignment logic. Do not rely on the model's internal knowledge of legal clause types—always provide the taxonomy explicitly to ensure consistency across contract types and jurisdictions.

Validation is the most critical part of the harness. The model's JSON output must be validated against a strict schema before it enters your database. At minimum, check that: the assigned_category field matches exactly one of the provided taxonomy entries (case-sensitive string match), the confidence field is a float between 0.0 and 1.0, the rationale field is a non-empty string, and the source_citation field contains a verbatim substring that can be located in the original [CLAUSE_TEXT]. If the source citation cannot be found via exact or fuzzy substring match, flag the output for human review regardless of confidence score. Implement a retry loop with a maximum of 2 additional attempts if validation fails. On each retry, append the specific validation error to the prompt as a [PREVIOUS_ERRORS] field so the model can self-correct. If the third attempt still fails validation, route the clause to a human review queue with all attempts logged.

For model selection, use a model with strong instruction-following and JSON mode support. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable. Avoid smaller or older models for this task because legal clause boundaries can be ambiguous, and misclassification of a limitation-of-liability clause as an indemnification clause carries material risk. Set temperature to 0 or as close to 0 as the model API allows to maximize deterministic assignment. Enable structured output or JSON mode if the provider supports it. If your pipeline processes high volumes, consider batching clauses into a single request with a JSON array output to reduce API overhead, but keep batch sizes small (5-10 clauses) to avoid the model confusing clause boundaries. Log every classification attempt with: input clause hash, assigned category, confidence score, validation status, retry count, and final disposition (accepted, escalated, failed). This audit trail is essential for legal ops teams who need to demonstrate review diligence.

The human review integration point is the confidence threshold. Set a configurable threshold (start at 0.85) below which classifications are automatically routed to a review queue. Additionally, any clause where the model assigns confidence below 0.95 but above the auto-escalation threshold should be surfaced in a 'low-confidence' dashboard for periodic spot-checking. The review interface should display the original clause text, the model's assigned category and rationale, and a dropdown of all valid taxonomy categories for the reviewer to confirm or override. Store the reviewer's decision alongside the model's output to build a labeled dataset for future fine-tuning or few-shot example curation. Never auto-approve clauses where the model flags confidence below your threshold—legal classification errors compound downstream in obligation tracking and risk analysis.

Finally, treat the taxonomy as a versioned artifact. When your legal team updates category definitions, splits a category, or adds a new clause type, version the taxonomy and track which taxonomy version was used for each classification. This prevents silent drift where old classifications become incomparable to new ones. Implement a backfill process that reclassifies previously processed clauses against the new taxonomy version if consistency is required. The prompt template's [TAXONOMY] placeholder should be populated from this versioned source, not hardcoded. Wire the taxonomy version into your logs and review dashboards so auditors can trace every classification decision to the exact category definitions in effect at the time of review.