Document Confidentiality Level Classification Prompt Template

This prompt is designed for data handling, DLP, and security engineering teams who need to automatically classify documents into a confidentiality tier based on their content. The primary job-to-be-done is a structured, auditable classification step that assigns a tier—public, internal, confidential, or restricted—and provides a rationale for that decision. It is ideal for users building automated routing, access control, or data loss prevention pipelines where consistent, machine-readable metadata must be derived from unstructured text before a document is stored, shared, or processed further.

Use this prompt when you have a document's textual content and need a single, defensible classification label. It is particularly effective as a pre-ingestion filter: a document classified as 'restricted' can be blocked from entering a general-purpose RAG index, while 'public' documents can bypass certain review queues. The prompt handles mixed-sensitivity content by requiring the model to classify based on the highest sensitivity present and to note conflicting signals in the rationale. However, this is a classification step, not a replacement for a full human-led security review. Do not use it as the sole decision point for irrevocable actions like data deletion, legal disclosure, or access revocation without a human-in-the-loop check.

Before implementing this prompt, ensure you have a clear, organization-specific definition for each confidentiality tier. The prompt template includes placeholder constraints for you to inject your company's data classification policy. Without this context, the model will rely on generic definitions of confidentiality, which may not align with your compliance requirements. After classification, always log the output, the model version, and the rationale for auditability. For high-risk documents, route any classification with a confidence caveat or mixed-signal rationale to a manual review queue.

The prompt below is designed to be copied directly into your application or evaluation harness. It enforces a strict output schema, requires evidence-based rationale, and explicitly handles documents that contain content at multiple sensitivity levels. The tier definitions are embedded in the prompt to reduce ambiguity and prevent the model from inventing its own classification taxonomy.

textCopy
Classify the following document content into a confidentiality tier. Use only the tiers defined below. Provide a concise rationale that cites specific signals from the text. If the document contains mixed sensitivity levels, assign the highest applicable tier and note the conflicting signals in the rationale.

### Confidentiality Tiers
- **public**: Information intended for public disclosure. No harm if shared externally.
- **internal**: Information for employees and authorized contractors. Unlikely to cause harm if disclosed but not intended for the public.
- **confidential**: Sensitive business, financial, or personal data. Disclosure could cause competitive, financial, or reputational harm.
- **restricted**: Highly sensitive data subject to strict need-to-know access. Disclosure could cause severe legal, financial, or safety consequences. Includes PII, PHI, trade secrets, and material non-public information.

### Document Content
[DOCUMENT_TEXT]

### Output Format
Return a single JSON object with the following keys:
- "confidentiality_level": (string) One of: "public", "internal", "confidential", "restricted"
- "rationale": (string) A brief explanation citing specific signals from the text.
- "mixed_signals": (boolean) True if the document contains content that would normally fall into a lower tier.
- "lower_tier_signals": (array of strings, optional) List any lower tiers that were also detected, if mixed_signals is true.

To adapt this template, replace [DOCUMENT_TEXT] with your actual document content. If you are processing long documents, consider truncating or chunking the input and aggregating results with a rule that takes the maximum tier across chunks. For regulated environments, add a [CONSTRAINTS] block specifying jurisdiction-specific definitions of PII, PHI, or trade secrets. The output schema is intentionally flat to simplify downstream parsing; avoid nesting unless your ingestion pipeline requires it.

Before deploying, validate the output against the expected JSON schema. Common failure modes include the model returning a tier outside the defined enum, omitting the mixed_signals field, or providing a rationale that paraphrases the tier definition without citing specific text signals. Add a post-processing validator that rejects any output where confidentiality_level is not one of the four allowed strings, and log those rejections for prompt refinement. For high-stakes document pipelines, route any restricted classification to a human review queue before taking automated action.

This prompt is designed to be called programmatically within a document ingestion pipeline. The LLM receives the prompt template populated with the document text and returns a structured JSON response containing the confidentiality_level, rationale, and mixed_signals fields. Your application must parse this JSON and use the confidentiality_level field as the primary routing signal. The rationale and mixed_signals fields should be logged immutably alongside the document metadata to create an audit trail for every classification decision.

Implement a strict validation layer that checks the LLM's response before any action is taken. The output must conform to the expected schema: confidentiality_level must be one of the defined enum values (public, internal, confidential, restricted), and both rationale and mixed_signals must be present as strings. If the JSON is malformed or fails schema validation, implement a retry mechanism with a simpler, more forceful prompt that reiterates the exact JSON schema required. For high-volume pipelines, log the failure and the raw response before retrying. Never act on a classification that hasn't passed schema validation.

The routing logic should be deterministic based on the validated confidentiality_level. Documents classified as restricted or confidential must be immediately routed to a secure, access-controlled storage bucket and a human review task must be created in your workflow system. Automated downstream processing, such as text extraction, indexing, or sharing, must be blocked until a human reviewer approves the document for release. Documents classified as internal can proceed with standard access controls, while public documents can be routed to less restrictive pipelines. Always ensure the human review interface displays the original document, the model's classification, and the full rationale to make the approval decision efficient and informed.