Confidentiality Tier Assignment Prompt for Documents

This prompt is for data governance engineers and compliance teams who need to classify unstructured documents into confidentiality tiers before those documents enter AI pipelines, retrieval systems, or agent workflows. The job-to-be-done is automated, evidence-backed classification that downstream systems can act on—enforcing tier-based access controls, retention rules, or processing boundaries without manual review of every document. The ideal user understands their organization's data classification taxonomy and needs a repeatable, auditable classification step that produces more than a label: it must output a confidence score and a rationale that cites specific evidence from the document text.

Use this prompt when you have the full document text available and your organization has clearly defined what each tier means in operational terms. The prompt assumes the model receives the document content and your tier definitions as input. It is designed for batch or event-driven classification of documents entering a system—such as files uploaded to a knowledge base, documents ingested into a RAG pipeline, or attachments processed by an agent. Do not use this prompt for real-time chat message filtering, where latency and partial context require a different approach. Do not use it for structured database records that already have metadata classification fields. Do not use it as a replacement for human-classified documents that have already undergone review; running the prompt over pre-classified documents will introduce drift and conflicting labels.

The most common failure mode is over-classification. If your tier definitions are vague or the model lacks clear boundaries between tiers, it will default to the higher confidentiality tier to avoid risk. This breaks downstream workflows by restricting access to documents that should be broadly available. Before deploying this prompt, validate your tier definitions for clarity and test the prompt against a golden set of documents with known classifications. If your organization cannot articulate the difference between 'internal' and 'confidential' with concrete examples, resolve that ambiguity before relying on model-driven classification. The next section provides the copy-ready prompt template you can adapt with your own tier definitions and output schema.

This prompt is designed to be pasted directly into your system instructions or a single-turn classification workflow. It instructs the model to act as a data governance classifier that assigns one of four confidentiality tiers—Public, Internal, Confidential, or Restricted—to a given document. The prompt includes placeholders for your organization's specific tier definitions, handling examples, and output format requirements. It is structured to produce a machine-readable JSON object containing the assigned tier, a confidence score, and a concise rationale, making it suitable for integration into automated document processing pipelines.

textCopy
You are a data governance classification engine. Your task is to analyze the provided document and assign a single confidentiality tier based on the definitions below. You must output a valid JSON object with no additional text.

## TIER DEFINITIONS
[Tier_Definitions: A list of the four tiers with detailed, organization-specific criteria for each. For example, define what constitutes 'Restricted' data, such as PII, PHI, or material non-public financial information.]

## CLASSIFICATION EXAMPLES
[Examples: Provide 2-3 few-shot examples showing a document excerpt, the correct tier, and a brief rationale. Include edge cases, such as a document that contains both Internal and Confidential information, and show the correct higher-tier assignment.]

## CONSTRAINTS
- If the document contains elements of multiple tiers, you must assign the highest applicable tier.
- If the document is ambiguous, you must assign the higher of the two possible tiers and note the ambiguity in the rationale.
- Do not over-classify. A document that is merely internal process documentation should not be classified as 'Confidential' unless it meets the specific criteria.
- Your rationale must cite specific content from the document that triggered the classification.

## INPUT DOCUMENT
[INPUT]

## OUTPUT FORMAT
Respond with a single JSON object matching this schema:
{
  "tier": "string (Public | Internal | Confidential | Restricted)",
  "confidence": "number (0.0 to 1.0)",
  "rationale": "string (A brief, evidence-based explanation for the assigned tier.)"
}

To adapt this template, start by replacing the [Tier_Definitions] placeholder with your organization's precise data classification taxonomy. Vague definitions lead to inconsistent model behavior, so include concrete examples of data types for each tier. Next, populate the [Examples] section with real or representative few-shot examples that demonstrate the boundary between tiers, particularly the Internal/Confidential boundary, which is the most common source of error. Finally, integrate this prompt into your application by replacing [INPUT] with the document text. Ensure your application layer validates the output JSON against the defined schema before accepting the classification. For high-risk documents, implement a human review step for any classification with a confidence score below a defined threshold, such as 0.85, or for any document classified as 'Restricted'.

This prompt is designed for a single-turn API call, not a chat session. Build a thin wrapper that loads the document, injects it into the prompt template, calls the model, validates the JSON output, and logs the result. The wrapper should treat the prompt as a stateless function: document in, classification out. Do not maintain conversation history or allow the model to ask clarifying questions—the classification must be completed in one response. The wrapper should enforce a strict timeout (e.g., 30 seconds) and handle rate limits with exponential backoff.

Validation is the critical gate. Before accepting any model output, validate that the JSON response contains all required fields: tier (must be one of public, internal, confidential, restricted), confidence (a float between 0.0 and 1.0), and rationale (a non-empty string). Reject responses that are missing fields, contain invalid enum values, or produce unparseable JSON. On validation failure, retry once with the same prompt and a temperature of 0. If the retry also fails, log the raw output and escalate for human review rather than silently defaulting to a safe tier. For high-volume pipelines, implement a dead-letter queue for failed classifications that can be replayed after prompt or model updates.

Model choice matters for consistency. Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format: { type: 'json_object' } or Claude with tool-use mode forcing a structured output). Set temperature=0 to minimize variance across repeated classifications of the same document. Log every classification attempt with the document hash, model version, prompt version, assigned tier, confidence score, and validation status. This audit trail is essential for detecting classification drift when you update the prompt or switch models. For documents near tier boundaries (confidence below 0.85), consider flagging them for human review or routing to a secondary classifier for consensus. Avoid building a pipeline that silently accepts low-confidence confidential or restricted assignments—these are the failure modes that create the most operational risk.