Legal Jurisdiction Boundary Detection Prompt

This prompt is designed for legal tech platform engineers who need a deterministic, auditable gate before any retrieval, reasoning, or generation steps. Its job is to inspect a user's legal query, detect the implicated jurisdiction, and determine whether that jurisdiction is within the system's supported set. If the jurisdiction is unsupported, the prompt produces a structured rejection with a jurisdiction-appropriate disclaimer, preventing the system from generating hallucinated legal advice or exposing the platform to unauthorized practice of law risk. The ideal user is an engineering lead integrating this into an AI pipeline's ingress layer, where it acts as a binary routing decision: proceed to legal analysis or return a graceful refusal.

Use this prompt when your platform explicitly supports a defined list of jurisdictions (e.g., 'California, New York, England and Wales') and must reject everything else. It is appropriate for consumer legal Q&A tools, contract review platforms, and legal intake systems where jurisdiction is a first-order routing concern. Do not use this prompt when your system provides only general legal information with no jurisdictional anchoring, when the user's location is already known from account metadata and can be injected directly, or when the downstream model is instructed to handle out-of-scope requests with its own refusal logic. This prompt is a classification and routing tool, not a legal advice generator. It belongs before any substantive prompt that interprets statutes, analyzes contracts, or recommends actions.

Before deploying, define your supported jurisdiction list explicitly and ensure it is injected into the [SUPPORTED_JURISDICTIONS] placeholder. Ambiguous queries that could span multiple jurisdictions (e.g., 'What are my rights as a remote worker?') require a clear policy: either flag them for human review, route to a clarification step, or default to the most conservative rejection. Wire the output into your application's routing logic so that a jurisdiction_status: unsupported result immediately short-circuits downstream processing and returns the disclaimer field to the user. Log every classification result with the input query, detected jurisdiction, and routing decision to build an audit trail for compliance review.

The prompt below is designed to be pasted directly into your system's classification layer. It instructs the model to analyze a user's request, identify the legal domain and implicated jurisdictions, and produce a structured verdict on whether the system can safely proceed. The template uses square-bracket placeholders that you must replace with your application's specific values before deployment.

textCopy
You are a legal jurisdiction boundary classifier for a legal technology platform. Your task is to analyze the user's request and determine whether it implicates a legal jurisdiction where the system is not authorized or able to provide assistance.

## SUPPORTED JURISDICTIONS
[SUPPORTED_JURISDICTIONS]

## UNSUPPORTED JURISDICTIONS
[UNSUPPORTED_JURISDICTIONS]

## AMBIGUITY HANDLING RULES
[AMBIGUITY_RULES]

## INPUT
User Request: [USER_REQUEST]
User Location (if known): [USER_LOCATION]
Additional Context: [ADDITIONAL_CONTEXT]

## TASK
1. Identify the primary legal domain(s) implicated by the request (e.g., contract law, family law, intellectual property, criminal law, tax law, immigration, etc.).
2. Determine which jurisdiction(s) the request implicates based on explicit mentions, the user's location, or the subject matter.
3. Classify the request into one of these categories:
   - **IN_SCOPE**: All implicated jurisdictions are in the supported list.
   - **OUT_OF_SCOPE**: At least one implicated jurisdiction is in the unsupported list.
   - **AMBIGUOUS**: The jurisdiction cannot be determined with sufficient confidence.
4. If OUT_OF_SCOPE or AMBIGUOUS, generate a jurisdiction-appropriate disclaimer.

## OUTPUT SCHEMA
Return a JSON object with exactly these fields:
{
  "classification": "IN_SCOPE" | "OUT_OF_SCOPE" | "AMBIGUOUS",
  "detected_legal_domains": ["string"],
  "implicated_jurisdictions": ["string"],
  "confidence_score": 0.0-1.0,
  "boundary_violation": null | {
    "unsupported_jurisdiction": "string",
    "reason": "string"
  },
  "disclaimer": null | "string",
  "recommended_action": "PROCEED" | "REJECT" | "ESCALATE"
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your application's concrete values. [SUPPORTED_JURISDICTIONS] should list every jurisdiction your platform is authorized to handle, using precise legal names (e.g., 'England and Wales', 'California, United States', 'Singapore'). [UNSUPPORTED_JURISDICTIONS] should explicitly list jurisdictions you know will appear and must be rejected. [AMBIGUITY_RULES] should define your tie-breaking logic when jurisdiction is unclear—for example, whether to escalate to human review or default to rejection. [CONSTRAINTS] should include any additional rules such as 'Never provide legal advice in the disclaimer text' or 'Always recommend consulting a qualified attorney in the relevant jurisdiction.' [EXAMPLES] should contain at least three few-shot examples covering IN_SCOPE, OUT_OF_SCOPE, and AMBIGUOUS scenarios to anchor the model's behavior.

Before deploying this prompt into production, validate its behavior against a golden test set that includes edge cases: requests mentioning multiple jurisdictions, requests with no explicit jurisdiction mention, requests in languages other than English, and adversarial inputs attempting to bypass jurisdiction checks. The structured JSON output makes this prompt straightforward to integrate into a routing middleware layer—parse the classification and recommended_action fields to determine whether to proceed with processing, return the disclaimer to the user, or escalate to a human reviewer.

The jurisdiction detection prompt is a classification gate that must run before any substantive legal analysis. In production, it sits in the request pipeline immediately after authentication and input sanitization but before the main legal reasoning model is invoked. The prompt's output is a structured JSON object containing a jurisdiction_flag, detected_jurisdictions, confidence_score, and a disclaimer_text. This output must be validated before the system decides whether to proceed, escalate, or reject the request. Because misclassification can create regulatory exposure, the harness must treat this prompt as a high-stakes decision point with mandatory audit logging and a clear escalation path for ambiguous cases.

Wire the prompt into an application by wrapping it in a validation layer that checks the JSON schema, enforces confidence thresholds, and handles multi-jurisdictional ambiguity. For example, if the prompt returns confidence_score below 0.85 or detected_jurisdictions contains more than one jurisdiction with conflicting support status, the harness should route the request to a human review queue rather than proceeding automatically. Implement a retry policy with a maximum of two attempts using a slightly higher temperature (0.3 → 0.5) on retry to dislodge stuck classifications, but never retry more than twice—persistent ambiguity is a signal to escalate, not to guess. Log every classification decision with the original input hash, the full prompt response, the validation result, and the routing decision for auditability. Use a model with strong instruction-following and low hallucination rates (such as Claude 3.5 Sonnet or GPT-4o) rather than a smaller, faster model, because the cost of a misclassification far outweighs the latency savings. If your system supports tool use, consider providing a lookup_jurisdiction_support function that checks an internal jurisdiction registry so the model can ground its classification in your actual supported-jurisdiction list rather than its training data.

The most common production failure mode is ambiguous multi-jurisdictional requests where a user asks about a legal matter spanning both supported and unsupported jurisdictions. The harness must handle this by checking whether any detected jurisdiction is unsupported and, if so, routing to the rejection path with the appropriate disclaimer. Do not allow the system to proceed with partial analysis on supported jurisdictions while ignoring the unsupported ones—this creates a misleading impression of completeness. Build an eval suite with at least 50 test cases covering single-jurisdiction supported, single-jurisdiction unsupported, multi-jurisdiction mixed, ambiguous jurisdiction mentions, and adversarial attempts to disguise jurisdiction. Run these evals on every prompt change and monitor production classification distributions weekly for drift. If the rate of confidence_score < 0.85 classifications increases by more than 20% week-over-week, trigger an alert and review recent input patterns before the system silently degrades.