This prompt is designed for legal operations teams that need to classify incoming documents into a controlled, predefined taxonomy before routing them to the correct matter, review queue, or storage system. It is built for production pipelines where an out-of-vocabulary classification or an invented document type will break downstream automation. Use this prompt when you have a fixed list of document types, need strict adherence to that list, and must handle ambiguous, multi-type, or unknown documents with a clear fallback strategy. This is not a prompt for open-ended document summarization or clause extraction. It is a classification control point.
Prompt
Document Type Classification Prompt for Legal Intake

When to Use This Prompt
A production control point for classifying legal documents into a strict taxonomy before routing, with clear fallbacks for ambiguity and unknowns.
The ideal user is a legal operations engineer or a product team building an AI-powered intake system. You should have a defined document taxonomy (e.g., 'Complaint', 'Summons', 'Motion to Dismiss', 'Non-Disclosure Agreement') that maps to specific routing rules or matter management workflows. The prompt expects a document's text as input and returns a structured classification object. It is designed to be wired into an application harness that validates the output against the taxonomy before any downstream action is taken. Do not use this prompt if you need the model to extract specific clauses, summarize arguments, or generate legal advice; those are separate, higher-risk workflows that require different evaluation and human-review gates.
The primary risk this prompt addresses is model drift into inventing plausible-sounding but incorrect document types. To mitigate this, the prompt explicitly instructs the model to use an 'UNKNOWN' label for documents that do not fit the taxonomy and a 'MULTI_TYPE' label when a document contains multiple distinct legal instruments. Your application harness must enforce these labels and prevent routing based on hallucinated types. Before deploying, you should test the prompt against a golden dataset that includes edge cases like scanned documents with poor OCR, documents with multiple embedded forms, and documents from jurisdictions with different naming conventions. If your legal intake process involves high-stakes matters, always include a human-in-the-loop review step for 'UNKNOWN' and 'MULTI_TYPE' classifications before the document enters a permanent record.
Use Case Fit
Where the Document Type Classification Prompt for Legal Intake delivers value and where it introduces unacceptable risk. Use these cards to decide if this prompt fits your intake pipeline before you invest in integration.
Good Fit: High-Volume, Standardized Intake
Use when: your legal operations team processes hundreds of incoming documents daily and needs consistent routing to matter types, review queues, or downstream systems. Guardrail: lock the output to your controlled document type taxonomy and reject any classification that falls outside it.
Bad Fit: Binding Legal Determinations
Avoid when: the classification triggers automatic legal deadlines, court filings, or statutory obligations without human confirmation. Guardrail: require a human-in-the-loop review step for any document type that carries jurisdictional or procedural consequences before the system acts on the label.
Required Inputs
What you must provide: the full document text (or a reliable OCR extraction), a controlled taxonomy of valid document types with definitions, and optional context such as matter type or jurisdiction. Guardrail: validate that the input text exceeds a minimum length and reject empty or near-empty submissions before calling the model.
Operational Risk: Taxonomy Drift
What to watch: your document type taxonomy changes over time as practice areas evolve, but the prompt still references an outdated enum. Guardrail: version your taxonomy alongside the prompt, run regression tests against a golden set of documents whenever the taxonomy changes, and monitor for an increase in out-of-vocabulary rejections.
Operational Risk: Multi-Type Documents
What to watch: a single document contains characteristics of multiple types (e.g., a complaint with an embedded exhibit). The model may flip between types inconsistently. Guardrail: define a tie-breaking rule in the prompt (e.g., classify by the primary legal function), return a confidence score, and flag low-confidence results for human review.
Operational Risk: Unknown or Novel Formats
What to watch: the intake pipeline receives a document format not represented in the taxonomy, and the model forces a best-guess classification instead of abstaining. Guardrail: include an explicit "UNKNOWN" or "OTHER" label in the taxonomy, instruct the model to use it when no type matches, and route those documents to a manual triage queue.
Copy-Ready Prompt Template
A production-ready prompt for classifying legal documents into a controlled taxonomy with built-in validation and abstention logic.
This prompt template is designed to be pasted directly into your system or developer message. It instructs the model to classify a legal document into a single, predefined document type from your controlled taxonomy. The prompt is structured to reject out-of-vocabulary inputs, handle multi-type documents by selecting the most specific match, and provide a confidence score to flag ambiguous cases for human review. Before using this template, you must define your specific taxonomy, output schema, and risk tolerance in the square-bracket placeholders.
textYou are a legal document classifier. Your task is to analyze the provided document text and assign exactly one document type from the controlled taxonomy below. TAXONOMY: [TAXONOMY_JSON] OUTPUT_SCHEMA: { "document_type": "string (must match a value from TAXONOMY exactly)", "confidence": "number (0.0 to 1.0)", "reasoning": "string (brief justification for the classification)", "abstention": "boolean (true if no taxonomy entry fits)" } CONSTRAINTS: - You MUST select a document_type value that exists in the TAXONOMY. Do not invent new types. - If the document contains elements of multiple types, select the most specific, legally operative type. - If the document is ambiguous or does not clearly fit any type, set abstention to true and document_type to "UNKNOWN". - If confidence is below [CONFIDENCE_THRESHOLD], set abstention to true. - Do not include any text outside the JSON output. DOCUMENT TEXT: [DOCUMENT_TEXT]
After pasting the template, replace [TAXONOMY_JSON] with your complete taxonomy as a JSON array of valid document type strings (e.g., ["Complaint", "Motion to Dismiss", "Subpoena", "Settlement Agreement"]). Replace [CONFIDENCE_THRESHOLD] with a numeric value between 0.0 and 1.0 that represents your minimum acceptable confidence for automatic processing. Documents scoring below this threshold will be flagged for human review. Replace [DOCUMENT_TEXT] with the full text of the incoming document. In production, this template should be wrapped in a validation layer that checks the output against your taxonomy schema before the result is accepted. For high-stakes legal workflows, always route abstained or low-confidence classifications to a human reviewer.
Prompt Variables
Required inputs for the Document Type Classification Prompt. Each placeholder must be populated before the prompt is sent to the model. Validation notes describe how to verify the input is well-formed before execution.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[DOCUMENT_TEXT] | The full text of the document to classify. Must be plain text with no markup or binary content. | LEASE AGREEMENT This Lease Agreement is made on... | Check that length is between 50 and 100,000 characters. Reject empty strings. Strip leading/trailing whitespace before insertion. |
[DOCUMENT_TYPE_TAXONOMY] | A controlled list of valid document types the model may output. Each entry must be a unique string label. | ["Lease Agreement", "Non-Disclosure Agreement", "Employment Contract", "Service Agreement", "Settlement Agreement", "Court Filing", "Correspondence", "Invoice", "Regulatory Filing", "Other"] | Validate that the taxonomy is a non-empty JSON array of unique strings. Reject if duplicates exist or if the array contains fewer than 2 entries. |
[TAXONOMY_DESCRIPTIONS] | Short definitions for each document type in the taxonomy to disambiguate boundary cases. | {"Lease Agreement": "A contract granting use of property for a specified term in exchange for rent.", "Non-Disclosure Agreement": "A contract restricting the sharing of confidential information between parties."} | Check that every key in [DOCUMENT_TYPE_TAXONOMY] has a corresponding description entry. Descriptions must be non-empty strings between 10 and 500 characters. |
[CONFIDENCE_THRESHOLD] | A float between 0.0 and 1.0. If the model's confidence in the top classification is below this value, the output should default to 'Uncertain' or trigger human review. | 0.75 | Parse as float. Reject values outside [0.0, 1.0]. If null or missing, default to 0.7 and log a warning. |
[MAX_TOKENS] | The maximum number of tokens the model may use for the classification response. Controls cost and latency. | 256 | Parse as integer. Must be between 50 and 4096. Reject if the value would truncate the required output schema fields. |
[OUTPUT_SCHEMA] | The JSON Schema that defines the required output structure, including fields for document_type, confidence_score, and reasoning. | {"type": "object", "properties": {"document_type": {"type": "string", "enum": [...]}, "confidence_score": {"type": "number"}, "reasoning": {"type": "string"}}, "required": ["document_type", "confidence_score"]} | Validate that the schema is valid JSON Schema draft-07 or later. Confirm that 'document_type' has an 'enum' constraint matching [DOCUMENT_TYPE_TAXONOMY]. Reject if required fields are missing. |
[FEW_SHOT_EXAMPLES] | Optional array of input-output pairs demonstrating correct classification behavior, especially for boundary cases and multi-type documents. | [{"input": "This agreement governs the employment of...", "output": {"document_type": "Employment Contract", "confidence_score": 0.92, "reasoning": "Explicitly states employment terms and conditions."}}] | If provided, validate that each example has 'input' and 'output' fields. Check that output.document_type exists in [DOCUMENT_TYPE_TAXONOMY]. Allow null if no examples are needed. |
Implementation Harness Notes
How to wire the Document Type Classification prompt into a legal intake application with validation, retries, and human review gates.
This prompt is designed to be the first step in a legal intake pipeline. It should be called synchronously after a document is uploaded and its text extracted, but before the document is routed to a review queue or matter management system. The application layer is responsible for text extraction (OCR, PDF parsing, or native text reading), passing the clean text and the controlled taxonomy into the prompt, and then validating the model's output against the taxonomy before any downstream action occurs. Do not pass raw binary files to the model; always preprocess into plain text.
The implementation harness must enforce a strict validation loop. After receiving the model's JSON response, validate that the document_type field exactly matches one of the labels in the provided taxonomy (case-sensitive, trimmed). If the confidence score is below a configurable threshold (e.g., 0.85) or the document_type is not in the taxonomy, the harness should trigger a retry with a more explicit instruction, such as: 'Your previous classification [PREVIOUS_TYPE] was invalid or low confidence. Re-evaluate and select ONLY from the provided taxonomy list.' Limit retries to a maximum of 2 attempts. If validation still fails, the document must be routed to a human review queue with the model's raw output and the extracted text attached. Never silently accept an out-of-vocabulary label.
For model choice, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is sufficient for this classification task, as it requires pattern matching against a known taxonomy rather than deep reasoning. Set temperature=0 to maximize deterministic label selection. Log every classification attempt—including the input hash, model version, raw response, validation result, and final routed destination—to an immutable audit table. This log becomes critical evidence for compliance reviews and for debugging taxonomy drift over time. The next step after a successful classification is to pass the validated document type and metadata to your document routing service, which will place the document into the correct matter folder and assign the appropriate review workflow.
Expected Output Contract
Defines the exact fields, types, and validation rules for the document classification output. Use this contract to build a post-processing validator that rejects malformed or out-of-taxonomy responses before they reach downstream intake systems.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
document_type | string | Must exactly match one label from [TAXONOMY]. Case-sensitive exact match required. Reject on partial match or synonym. | |
confidence_score | number | Must be a float between 0.0 and 1.0 inclusive. Reject if null, negative, or >1.0. If below [CONFIDENCE_THRESHOLD], flag for human review. | |
primary_type | string | Must equal the value of document_type. Used for downstream routing. Reject if mismatched with document_type. | |
secondary_types | array of strings | If present, each element must be a valid label from [TAXONOMY]. Reject if any element is not in the taxonomy. Empty array allowed. | |
abstention_flag | boolean | Must be true if confidence_score < [CONFIDENCE_THRESHOLD] or if document_type is 'UNKNOWN'. Reject if false when confidence is below threshold. | |
rationale | string | Must be a non-empty string between 20 and 500 characters. Reject if empty, whitespace-only, or exceeds length limit. Must reference specific document features. | |
source_citation | string | If present, must contain a page, section, or paragraph reference from [DOCUMENT_TEXT]. Reject if citation points to non-existent location. | |
processing_timestamp | string (ISO 8601) | Must be a valid ISO 8601 datetime string in UTC. Reject on parse failure or non-UTC timezone offset. |
Common Failure Modes
Document type classification for legal intake is brittle when the model guesses, invents labels, or mishandles edge cases. These are the most common failure modes and the guardrails that prevent them from reaching downstream systems.
Out-of-Vocabulary Label Invention
What to watch: The model assigns a document type that does not exist in the controlled taxonomy, such as 'Settlement Proposal' when only 'Settlement Agreement' is defined. This breaks downstream routing and creates dirty data. Guardrail: Post-process every classification against the canonical taxonomy list. Reject any label not present in the allowed set and trigger a fallback to 'Other' or a human review queue.
Multi-Type Document Misclassification
What to watch: A single document contains characteristics of multiple types (e.g., a contract with an embedded NDA). The model picks one type and drops the other, losing critical context for legal review. Guardrail: Design the prompt to return a primary type and an optional array of secondary types. Validate that secondary types are also in the taxonomy and flag documents with more than one high-confidence match for human confirmation.
Confidence Inflation on Ambiguous Documents
What to watch: The model returns 95% confidence for a scanned, low-quality document or a novel document format it has never seen. High confidence on ambiguous inputs leads to incorrect auto-routing. Guardrail: Require the model to output a confidence score and calibrate it with a few-shot example showing low confidence for ambiguous cases. Set a threshold below which documents are routed to manual review rather than automated workflows.
Taxonomy Drift After Schema Updates
What to watch: The legal taxonomy changes (e.g., 'Lease Agreement' is split into 'Commercial Lease' and 'Residential Lease'), but the prompt still references the old labels. The model either uses outdated types or hesitates on the new ones. Guardrail: Version the taxonomy alongside the prompt. Include the taxonomy version and last-updated date in the prompt context. Run regression tests against a golden set of documents whenever the taxonomy changes.
Context Window Truncation of Long Documents
What to watch: A 120-page contract is truncated by the context window. The model classifies based on the first 20 pages, missing a critical addendum that changes the document type. Guardrail: Implement a pre-processing step that extracts key sections (title page, table of contents, signature blocks, defined terms) and passes only those to the classifier. If the document exceeds the context budget, flag it for chunked review rather than forcing a partial classification.
Overfitting to Document Title Strings
What to watch: The model relies on the document's filename or header text ('Motion for Summary Judgment') instead of analyzing the actual content. A mislabeled file or a draft with a working title gets routed incorrectly. Guardrail: Instruct the model to base classification on the document body content, not the filename or header alone. Include a test case where the title is intentionally misleading and verify the model still classifies correctly from the body.
Evaluation Rubric
Use this rubric to test the Document Type Classification Prompt before shipping. Each criterion targets a specific failure mode observed in legal intake classification. Run these checks against a golden test set of 50-100 documents covering all taxonomy types, edge cases, and out-of-scope examples.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Taxonomy Adherence | Output label exactly matches a value in the [DOCUMENT_TYPE_TAXONOMY] enum. No extra whitespace, punctuation, or variant spellings. | Label not found in taxonomy list; label is a substring or superstring of a valid value; label is a synonym not in the controlled vocabulary. | Parse output label. Assert label ∈ [DOCUMENT_TYPE_TAXONOMY] using exact string match. Run on 100% of test set. |
Single-Type Classification Accuracy | For documents clearly belonging to one type, the predicted label matches the ground truth label with ≥95% accuracy. | Accuracy below 95% on single-type documents; systematic confusion between similar types (e.g., NDA vs. Confidentiality Agreement). | Confusion matrix on single-type test subset. Calculate precision, recall, F1 per label. Flag any label pair with >5% cross-error. |
Multi-Type Document Handling | When [ALLOW_MULTI_LABEL] is false, the prompt returns exactly one label. When true, it returns an array of labels, all valid per taxonomy. | Multiple labels returned when [ALLOW_MULTI_LABEL] is false; single label returned for a compound document when multi-label is true; array contains invalid labels. | Parameterized test: run same multi-type document with [ALLOW_MULTI_LABEL] = false and true. Assert output cardinality matches parameter. Validate all labels against taxonomy. |
Unknown Document Rejection | When [ALLOW_UNKNOWN] is true and document type is not in taxonomy, output label is exactly [UNKNOWN_LABEL_VALUE]. When false, model must not output [UNKNOWN_LABEL_VALUE]. | Model outputs a best-guess taxonomy label instead of [UNKNOWN_LABEL_VALUE] when [ALLOW_UNKNOWN] is true; model outputs [UNKNOWN_LABEL_VALUE] when [ALLOW_UNKNOWN] is false. | Test with 10 out-of-scope documents (e.g., marketing flyer, restaurant menu). Assert label equals [UNKNOWN_LABEL_VALUE] only when [ALLOW_UNKNOWN] is true. |
Confidence Score Calibration | When [INCLUDE_CONFIDENCE] is true, output includes a confidence field with a float between 0.0 and 1.0. Confidence <0.7 correlates with incorrect classifications. | Confidence field missing or null when [INCLUDE_CONFIDENCE] is true; confidence >0.9 on incorrect classifications; confidence values outside 0.0-1.0 range. | Parse confidence field. Assert 0.0 ≤ confidence ≤ 1.0. For all misclassifications, assert confidence <0.7. Run on full test set. |
Output Schema Compliance | Output is valid JSON matching the [OUTPUT_SCHEMA]. All required fields present. No extra fields. Field types match schema definitions. | JSON parse error; missing required field (e.g., document_type); extra undeclared field; string where number expected; array where string expected. | Validate output against [OUTPUT_SCHEMA] using a JSON Schema validator. Run on 100% of test set. Any validation failure is a hard fail. |
Empty or Malformed Input Handling | When [DOCUMENT_TEXT] is empty, whitespace-only, or unparseable, output includes an error field or returns [UNKNOWN_LABEL_VALUE] without crashing. | JSON parse error; model hallucinates a document type from empty input; model returns a 200-style response with a made-up classification. | Test with empty string, 500 spaces, base64 garbage, and a 1-character input. Assert valid JSON output. Assert document_type is [UNKNOWN_LABEL_VALUE] or error field is populated. |
Long Document Truncation Resilience | For documents exceeding the model's context window, classification is based on the first [MAX_TOKENS] tokens and accuracy remains within 10% of full-document accuracy. | Model refuses to classify; model classifies based on tail of document only; accuracy drops >10% compared to full-document baseline. | Select 10 long documents (>100K tokens). Truncate to [MAX_TOKENS] before sending. Compare accuracy against full-document classification (using a long-context model as ground truth). Assert accuracy delta ≤10%. |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Start with the base prompt and a hardcoded taxonomy list. Run classification on a small batch of documents and manually review results. Use a simple JSON output with document_type and confidence fields. Skip strict schema validation initially to observe natural output variance.
Prompt modification
codeClassify the following document into one of these types: [TAXONOMY_LIST]. Document: [DOCUMENT_TEXT] Return JSON: {"document_type": "...", "confidence": "low|medium|high"}
Watch for
- Model inventing types outside the taxonomy
- Inconsistent confidence language (e.g., "pretty sure" vs "high")
- Multi-type documents forced into a single label without flags

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us