Compliance vs. General Inquiry Triage Prompt

This prompt is a classification guard designed for regulated platforms that must identify compliance-relevant inputs before standard processing occurs. Its job is to act as a triage filter, not a compliance officer. Use it when an incoming user request, document, or message might contain signals related to regulatory filings, formal complaints, policy violations, audit requests, or legal exposure. The ideal user is a platform engineer or AI architect building a routing middleware layer who needs a binary routing decision—compliance or general—with a confidence score and a concise evidence summary. This output is designed to be consumed by a downstream router or queue dispatcher that enforces specialized handling, audit trails, or retention policies for compliance-flagged items.

You should deploy this prompt at the ingress point of your AI pipeline, before any standard processing, tool use, or response generation. The required context includes the raw user input and a clear definition of what constitutes a compliance-relevant signal for your specific domain. You must provide a [COMPLIANCE_SCOPE] definition that outlines the regulatory boundaries, policy categories, and risk triggers relevant to your platform. Without this scoping, the model will default to a generic and potentially noisy definition of compliance. The prompt expects a structured JSON output containing a classification field (compliance or general), a confidence_score between 0 and 1, and an evidence_summary string that cites the specific phrases or signals that drove the decision.

Do not use this prompt for nuanced legal analysis, for generating compliance advice, or as a substitute for qualified legal review. It is a high-recall safety net designed to prevent compliance-relevant content from slipping into a general processing pipeline where it might be handled without proper audit trails, data retention, or human oversight. A false negative—classifying a compliance item as general—is the primary risk, as it can create regulatory exposure. A false positive—routing a general inquiry to the compliance queue—is a cost and latency problem but is typically safer. Your next step after implementing this prompt is to build the downstream router that consumes its output and to establish a human review process for low-confidence or high-severity compliance classifications.

This prompt template is designed to be dropped directly into your classification middleware. It forces the model to act as a strict triage classifier rather than a conversational assistant, which is critical for regulated platforms where a misclassified compliance input can create legal exposure. The template uses a system instruction that explicitly forbids answering the user's question, a defined taxonomy of compliance signals, and a constrained JSON output schema that downstream systems can parse deterministically.

textCopy
[SYSTEM_INSTRUCTION]
You are a compliance triage classifier for a regulated platform. Your only job is to determine if an input requires compliance handling. Do not answer the user's question. Do not provide advice.

[COMPLIANCE_TAXONOMY]
An input requires compliance handling if it contains any of the following:
- Formal complaints, disputes, or legal threats.
- References to regulatory bodies, statutes, or filing obligations.
- Requests for data deletion, access, or portability under privacy law.
- Reports of policy violations, fraud, or misconduct.
- Audit requests or inquiries about record retention.
- Language indicating potential litigation or regulatory action.

[INPUT]
"""
[USER_INPUT]
"""

[OUTPUT_SCHEMA]
{
  "classification": "compliance" | "general_inquiry",
  "confidence": 0.0-1.0,
  "evidence": "Short quote or summary from the input that supports the classification.",
  "reasoning": "One sentence explaining the classification decision."
}

[CONSTRAINTS]
- If no compliance signals are detected, classify as "general_inquiry".
- Confidence must reflect genuine certainty. Use 0.5 for ambiguous cases.
- Evidence must be a direct quote or a close paraphrase from the input.

To adapt this template for your platform, start by customizing the [COMPLIANCE_TAXONOMY] section to match your specific regulatory obligations. If you operate under GDPR, CCPA, HIPAA, or SOX, add the relevant trigger phrases and request types that your compliance team has defined. The taxonomy is the single most important section to get right because it defines the boundary between automated processing and specialized handling. Test it against a golden dataset of known compliance and general inquiry examples before deployment, and expect to iterate as your compliance team identifies new signal patterns.

The [CONSTRAINTS] section enforces three behaviors that prevent common failure modes: defaulting to general_inquiry avoids over-escalation that floods your compliance queue with false positives, the confidence scoring requirement forces the model to express uncertainty rather than guessing, and the evidence requirement creates an audit trail that your compliance team can review. When wiring this into production, validate that the output contains all four required fields and that classification is exactly one of the two allowed enum values before routing. If validation fails, retry once with the same prompt, then escalate to a human reviewer rather than silently defaulting to either path.

The most dangerous failure mode for this prompt is a false negative: a compliance-relevant input classified as general_inquiry and routed into standard processing. This can trigger regulatory reporting obligations, data handling violations, or missed response deadlines. Mitigate this by setting a lower confidence threshold for the compliance classification path: if confidence is above 0.3 for compliance, route to review even if the classification is general_inquiry. This asymmetric threshold trades some false positives for catching borderline compliance inputs that the model is uncertain about.

Next, build an eval harness that tests this prompt against edge cases: inputs that mention legal terms in non-legal contexts, complaints that don't rise to formal disputes, privacy requests buried in long messages, and multi-intent inputs that mix compliance and general inquiry content. Measure precision and recall against human-labeled examples, with particular attention to recall on the compliance class. If recall drops below 0.95, expand your taxonomy or add few-shot examples of borderline cases that should route to compliance.

Wire this prompt as a synchronous pre-processing step before your main agent or response pipeline. In code, call the classification endpoint, parse the JSON response, and branch on the classification field. If classification is compliance, route the input to a dedicated compliance queue and do not pass it to the general-purpose model. Log the full classification payload for auditability. If confidence is below your threshold, route to a human review queue.

Implement a retry with a backoff if the model returns malformed JSON. Use a validation function that checks for the required enum values and a confidence float between 0 and 1. If validation fails after a maximum of two retries, escalate to a human operator and log the raw response. For high-throughput systems, consider batching inputs but ensure each classification is independently logged with a trace ID that links back to the original input.

Choose a fast, cost-effective model for this triage step since it runs on every input. A smaller model like GPT-4o-mini or Claude Haiku is often sufficient. Do not use this prompt as the final compliance decision—it is a routing signal. Always preserve the original input and classification metadata in your logs. If your platform handles PII, ensure the classification prompt runs in the same data boundary as the input and that logs do not leak sensitive content into monitoring systems.