Legal Information vs Legal Advice Disambiguation Prompt

This prompt is for legal tech product teams building AI features that must distinguish between providing general legal information and giving specific legal advice. The core job is to classify a user query, identify which elements cross into advice territory, and produce a structured boundary decision that downstream application logic can act on. Use this prompt when your product handles user-submitted legal questions and you need a reliable, auditable gate before generating a substantive response. This is not a replacement for legal review; it is a safety layer that reduces the risk of unauthorized practice of law while preserving the ability to answer informational questions about statutes, procedures, and legal concepts.

The ideal user is an AI engineer or product manager integrating this classifier into a retrieval-augmented generation (RAG) system, a chatbot, or a legal intake workflow. Required context includes the full user query, any jurisdiction tags available (e.g., [JURISDICTION]), and the intended output schema for the downstream system. Do not use this prompt when the user has already established an attorney-client relationship with a supervising lawyer in a closed system, or when the product is a pure document retrieval tool with no generative component. It is also inappropriate for fully unmoderated public forums where no human review layer exists.

Before deploying, pair this prompt with a regression test suite that includes both clearly informational queries ('What is the statute of limitations for breach of contract in California?') and clearly advice-seeking queries ('Should I sue my landlord for not fixing the heat?'). Measure the false positive rate on informational queries to ensure you are not over-refusing and degrading the user experience. The output of this prompt should feed a routing decision: informational queries proceed to generation, advice-seeking queries trigger a safe refusal or redirection, and ambiguous cases should escalate for human review or request clarification from the user.

This prompt template is designed to be deployed as a pre-processing guard or classification step in legal tech products. Its job is to analyze a user's query and determine whether it stays within the boundary of providing general legal information or crosses into the territory of legal advice. The template uses square-bracket placeholders so you can adapt it to your jurisdiction, risk tolerance, and output format without rewriting the core logic. Copy the block below into your system prompt, classification step, or safety guard.

textCopy
You are a legal information boundary classifier. Your task is to analyze the following user query and determine whether it requests legal information or legal advice. You must not provide legal advice under any circumstances.

## Definitions
- **Legal Information**: General statements about the law, legal processes, court procedures, definitions of legal terms, publicly available legal facts, or educational explanations that do not apply law to a specific person's situation.
- **Legal Advice**: Any statement that applies law to a specific set of facts, recommends a course of action for a particular situation, predicts a legal outcome for a specific scenario, interprets how a law applies to someone's described circumstances, or suggests what someone should do in a legal matter.

## Input
User Query: [USER_QUERY]
User Context (if available): [USER_CONTEXT]
Jurisdiction: [JURISDICTION]

## Classification Rules
1. If the query asks for general information about laws, procedures, definitions, or publicly available legal facts without reference to a specific personal situation, classify as `legal_information`.
2. If the query describes a specific personal or business scenario and asks what the law says about it, what someone should do, what rights or obligations apply, or what the likely outcome would be, classify as `legal_advice`.
3. If the query mixes general questions with specific scenario details, classify as `legal_advice` if any portion crosses the boundary.
4. Hypothetical scenarios framed for educational purposes (e.g., "In a law school hypothetical, if someone...") should be classified as `legal_information` only if clearly labeled as educational and not disguised requests for personal guidance.
5. Requests for legal document templates with instructions on how to fill them out for a specific situation should be classified as `legal_advice`.

## Output Schema
Return a JSON object with the following fields:
- `classification`: One of `legal_information` or `legal_advice`
- `confidence`: A float between 0.0 and 1.0 indicating confidence in the classification
- `reasoning`: A brief explanation of which elements triggered the classification
- `crossing_elements`: An array of strings identifying specific phrases or patterns that crossed into advice territory (empty array if `legal_information`)
- `recommended_action`: One of `allow`, `block`, `redirect_to_disclaimer`, or `escalate_for_review`

## Constraints
- Do not generate a substantive response to the user's legal question.
- If classification is `legal_advice`, the recommended action must be `block` or `redirect_to_disclaimer`.
- If confidence is below [CONFIDENCE_THRESHOLD], set recommended_action to `escalate_for_review`.
- Apply [JURISDICTION]-specific rules for what constitutes legal advice in that jurisdiction.
- For queries involving [RESTRICTED_DOMAINS], apply heightened scrutiny and default to `escalate_for_review`.

## Examples
[FEW_SHOT_EXAMPLES]

## Risk Level
Current risk level: [RISK_LEVEL]
- At `low`, permit `legal_information` classifications with confidence >= 0.7.
- At `medium`, require confidence >= 0.85 for `legal_information` and escalate borderline cases.
- At `high`, escalate all classifications for human review regardless of confidence.

To adapt this template for your application, replace each square-bracket placeholder with concrete values. For [JURISDICTION], specify the relevant legal jurisdiction (e.g., "California, USA" or "England and Wales") because the definition of legal advice varies by jurisdiction. For [CONFIDENCE_THRESHOLD], set a numeric threshold based on your risk tolerance—start with 0.8 and adjust based on false positive and false negative rates observed in production. For [RESTRICTED_DOMAINS], list high-risk areas such as immigration, tax, criminal defense, or family law where misclassification carries greater consequences. For [FEW_SHOT_EXAMPLES], provide 3-5 labeled examples covering both classifications, including edge cases like hypothetical scenarios and mixed queries. For [RISK_LEVEL], wire this to a runtime configuration so operators can adjust thresholds without changing the prompt. Validate outputs against the JSON schema before routing, and log all classifications for audit and threshold tuning. If the model returns malformed JSON, retry once with a repair prompt; if that fails, escalate to human review.

This prompt is designed to sit at a critical boundary in legal tech products: the moment a user query moves from general legal information into specific legal advice. The implementation harness must treat the model's classification as a signal, not a final decision. Because the consequences of misclassification include potential unauthorized practice of law claims, the application layer should enforce additional checks before any response is shown to the user. Wire this prompt as a pre-response classifier that runs after the main generation prompt but before the output is delivered, or as a standalone triage step that routes the query to different handling paths based on the classification result.

Integration pattern: Place this prompt as a synchronous classification step in your request pipeline. The model receives the user query plus any retrieved legal content and returns a structured classification object. Your application should parse the classification field (information or advice) and the boundary_elements array that identifies which specific phrases or requests crossed the line. Validation rules to implement: (1) reject any classification that lacks at least one boundary element when classified as advice—this indicates the model flagged advice without articulating why, which is a low-confidence signal; (2) if confidence_score is below your configured threshold (start with 0.85), route to human review; (3) check that jurisdiction_relevant is populated when the query mentions specific locations or legal systems. Retry logic: if the output fails to parse as valid JSON or is missing required fields, retry once with a stricter schema reminder. After two failures, escalate to a human reviewer and log the raw response for prompt debugging.

Model choice and latency: Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). This classification task is latency-sensitive if it gates every user response, so keep the prompt concise and avoid chaining multiple model calls for the same decision. Logging and audit trail: Log the full classification result, the user query, the timestamp, and the final routing decision. In regulated deployments, also log the reviewer identity when human review is triggered. Human review integration: When the classification is advice or confidence is below threshold, queue the interaction for review rather than blocking silently. The review interface should display the original query, the model's classification, the boundary elements, and a simple approve/override control. Track override rates by reviewer to identify calibration drift. Do not use this prompt as the sole defense—combine it with retrieval-augmented generation that grounds responses in specific legal sources, and always include a disclaimer in user-facing outputs when the classification is information but the topic is high-risk (family law, immigration, criminal procedure).

What to avoid: Do not treat a low_risk classification as a green light to generate unconstrained legal content. The prompt classifies the query, not the response. Your generation prompt still needs its own guardrails. Do not skip jurisdiction detection—a query classified as information under California law may still constitute advice in other jurisdictions. Finally, do not deploy this prompt without a regression test suite that includes the eval criteria described in the full playbook: jurisdiction-specific disclaimers, hypothetical vs. specific scenario detection, and edge cases where the user provides detailed personal facts but frames the request as a hypothetical question.