Document Type Enum Classification Prompt Template

This prompt is designed for document ingestion pipelines that need reliable, auditable type detection before downstream processing. It classifies a document's full text or a representative sample into a predefined, controlled enumeration (such as contract, invoice, report, nda, or resume) and returns a confidence score. Use this when your system must route documents to different parsers, storage tiers, review queues, or compliance workflows based on their type. The prompt handles ambiguous documents by returning a primary type, a list of secondary types, and a rationale, making it suitable for operational systems where misclassification has a real cost.

The ideal user is an integration engineer or platform developer building a document processing pipeline. You should have a fixed, governed taxonomy of document types that changes infrequently. The prompt expects a [DOCUMENT_TEXT] input and a [TYPE_ENUM] list of allowed values. It returns a structured JSON object with a primary_type, confidence_score (0.0 to 1.0), secondary_types array, and a rationale string. This output contract is designed to be machine-readable and auditable, so you can log every classification decision and trigger alerts when confidence falls below a configurable threshold. For high-stakes workflows like legal hold routing or financial report filing, you should pair this prompt with a human review step when confidence is below 0.85 or when the primary and secondary types conflict.

Do not use this prompt for open-ended topic discovery, free-text tagging, or when the document type taxonomy is unstable and changes daily. It is not a clustering or unsupervised learning replacement. If you need to discover new document categories from a corpus, this prompt will force every document into your existing enum, masking novel patterns. Similarly, if your documents are extremely short (e.g., single-sentence snippets) or contain no structural signals, the classifier will degrade to guessing. In those cases, you need a different approach—likely a content-based classifier or a human labeling queue. Use this prompt when you have a stable taxonomy, need consistent machine-readable output, and can invest in eval sets that measure classification accuracy against your specific document distribution.

This template provides a complete system prompt for document type classification. It enforces a strict output schema, handles ambiguous or multi-type documents, and requires confidence annotations. Replace the square-bracket placeholders with your specific taxonomy, constraints, and risk thresholds before deploying. The prompt is designed to be used as system-level instructions with the document text passed as the user message.

textCopy
You are a document classification system. Your task is to analyze the provided document text and classify it into exactly one document type from the controlled taxonomy below. You must also provide a confidence score and handle edge cases explicitly.

## TAXONOMY
[DOCUMENT_TYPE_ENUM_LIST]
Example: ["contract", "invoice", "report", "email", "meeting_notes", "proposal", "policy", "other"]

## CLASSIFICATION RULES
1. Select the single best-matching type from the taxonomy.
2. If the document contains characteristics of multiple types, select the dominant type and note the secondary types in the `secondary_types` field.
3. If the document does not clearly match any type, use the [FALLBACK_TYPE] (e.g., "other" or "unclassified").
4. Base your classification on structural signals (headings, tables, signatures), lexical signals (domain terminology), and purpose signals (the document's apparent function).
5. Do not classify based on the document's topic alone. A contract about software is still a contract.

## CONFIDENCE SCORING
- **high (0.9-1.0):** Clear structural and lexical markers match a single type unambiguously.
- **medium (0.7-0.89):** Strong indicators for one type but some ambiguity or missing expected elements.
- **low (0.5-0.69):** Weak or conflicting signals; best-guess classification.
- **unreliable (<0.5):** Insufficient information to classify. Use [FALLBACK_TYPE] and flag for human review.

## AMBIGUITY HANDLING
- If the document is a hybrid (e.g., a contract that also serves as an invoice), set the primary type to the dominant function and list the secondary type.
- If the document is a cover email transmitting another document, classify the transmitted document if its content is present; otherwise classify as "email".
- If the document is too short or fragmentary, set confidence to "unreliable" and flag `needs_human_review: true`.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with this exact structure:
{
  "document_type": "string (from taxonomy)",
  "confidence_score": float (0.0 to 1.0),
  "confidence_tier": "high" | "medium" | "low" | "unreliable",
  "secondary_types": ["string (from taxonomy)"],
  "rationale": "string (brief explanation of classification signals)",
  "needs_human_review": boolean
}

## CONSTRAINTS
- Do not include any text outside the JSON object.
- Do not invent types outside the taxonomy.
- If the document text is empty or contains only whitespace, return `document_type: "[FALLBACK_TYPE]"`, `confidence_score: 0.0`, `confidence_tier: "unreliable"`, and `needs_human_review: true`.
- For [REGULATED_DOMAIN] documents, always set `needs_human_review: true` when confidence_tier is "low" or "unreliable".

## INPUT
Document text to classify:
[INPUT]

To adapt this template for your pipeline, replace [DOCUMENT_TYPE_ENUM_LIST] with your actual taxonomy as a JSON array of strings. Set [FALLBACK_TYPE] to your preferred catch-all label, such as "other" or "unclassified". If you operate in a regulated domain like finance, healthcare, or legal, set [REGULATED_DOMAIN] to true to enforce human review on low-confidence classifications. The [INPUT] placeholder should be replaced at runtime with the document text. Wire the output through a JSON validator before ingestion—malformed JSON or missing required fields should trigger a retry or fallback to human review. For high-throughput pipelines, consider caching classifications for duplicate or near-duplicate documents to reduce cost and latency.

The Document Type Enum Classification prompt is designed to sit at the front of a document ingestion pipeline, acting as a routing gate before extraction, parsing, or storage. In production, this prompt is not a standalone chatbot interaction—it is an API call inside a processing job. The application layer is responsible for providing the document text, the controlled enum list, and any contextual hints (such as filename or source system) via the [INPUT], [ENUM_OPTIONS], and [CONTEXT] placeholders. The model's response must be parsed as structured JSON containing at least document_type, confidence_score, and alternative_types. The application should never trust the raw string output; it must validate the JSON schema, confirm the returned type is a member of the provided enum, and check that the confidence score is a float between 0.0 and 1.0 before routing the document downstream.

A robust implementation wraps the model call in a validation and retry loop. After receiving the response, validate the JSON structure using a schema library (e.g., Pydantic, Zod, or JSON Schema). If validation fails, retry the prompt with the same input and an added [ERROR_CONTEXT] describing the parse failure. Limit retries to a maximum of 2 attempts to avoid latency spirals. For documents where the confidence score falls below a configurable threshold (e.g., < 0.7), route the document to a human review queue rather than proceeding with automated extraction. Log every classification result—including the model used, prompt version, input hash, confidence score, and any retry attempts—to an observability platform for drift detection and auditability. For high-throughput pipelines, consider using a faster, cheaper model for initial classification and only escalating ambiguous cases to a more capable model.

Avoid wiring this prompt directly into a synchronous user-facing flow without a timeout and fallback. If the model call exceeds a latency budget (e.g., 2 seconds), fall back to a heuristic classifier based on filename extensions or MIME types, and flag the document for asynchronous reclassification. Do not use the model's classification to automatically delete, move, or expose documents without a human-in-the-loop review step when the confidence is low or the document type is associated with sensitive handling rules (e.g., contract, legal_filing, medical_record). The prompt is a classification tool, not an access control decision engine.