Legal Precedent Analysis Prompt for RAG

This prompt is designed for a specific, high-stakes job: analyzing how a single retrieved legal case applies to a new fact pattern. It is not a general legal chatbot. The ideal user is a legal professional or a legal AI product team that has already built a retrieval pipeline. The prompt assumes that a RAG system has surfaced a candidate case, and the model's task is to perform a structured, disciplined analysis. This includes extracting the case's core holding, assessing factual similarity to the user's scenario, noting whether the case is binding or merely persuasive authority in the relevant jurisdiction, and identifying key factors that distinguish the precedent from the current matter.

Use this prompt when the primary failure mode is the overgeneralization of a precedent's scope—a common and dangerous error where a model incorrectly assumes a case applies more broadly than it does. The prompt enforces strict citation discipline by requiring direct quotes for key holdings and explicitly separates binding from persuasive authority. It also includes built-in abstention logic: if the retrieved context is insufficient to perform a reliable analysis, the model is instructed to state that clearly rather than fabricate a connection. This makes it suitable for integration into a legal research tool where a wrong answer is far more costly than no answer.

Do not use this prompt for open-ended legal Q&A, for analyzing multiple cases simultaneously, or for providing legal advice. It is a single-case analysis tool. Before deploying, you must ensure your retrieval system is providing the correct case as context; this prompt will not correct a retrieval error. The next step is to wire this prompt into an application harness with strict output validation, as covered in the Implementation Harness section. For production use, always pair this with a human review step for any analysis that informs a legal filing, client advice, or a judicial decision.

This prompt template is the core instruction set for a legal RAG system that analyzes how precedent applies to a given fact pattern. It is designed to be placed in your model's system instructions, with square-bracket placeholders replaced at runtime by your application's retrieval pipeline, user input, and output schema requirements. The prompt enforces strict citation discipline, jurisdictional scoping, and explicit separation of factual similarity assessment from binding authority analysis. It also includes built-in abstention logic for when retrieved context is insufficient.

textCopy
You are a legal research analyst AI. Your task is to analyze how retrieved legal precedent applies to a given fact pattern. You must ground every statement in the provided [CONTEXT], which contains case law excerpts retrieved from a legal database.

## INPUTS
- Fact Pattern: [FACT_PATTERN]
- Jurisdiction: [JURISDICTION]
- Procedural Posture (if known): [PROCEDURAL_POSTURE]

## RETRIEVED CONTEXT
[CONTEXT]

## OUTPUT REQUIREMENTS
Generate a structured analysis in valid JSON matching the [OUTPUT_SCHEMA] below. Do not include any text outside the JSON object.

## ANALYSIS RULES
1. **Case Holding Extraction**: For each case in [CONTEXT], extract the core holding in 1-2 sentences. Cite the case name and year.
2. **Factual Similarity Assessment**: Compare the [FACT_PATTERN] to each case's material facts. Rate similarity as High, Medium, or Low with a one-sentence justification grounded in specific facts from both the pattern and the case.
3. **Binding Authority Notes**: For each case, state whether it is binding, persuasive, or distinguishable in [JURISDICTION]. Include the court level and jurisdictional scope. If the case is from a different jurisdiction, explain its persuasive value or lack thereof.
4. **Distinguishing Factors**: Identify specific factual or procedural differences that could limit a precedent's applicability. Be precise: cite the differing fact from the [FACT_PATTERN] and the corresponding fact from the case.
5. **Synthesis and Risk Assessment**: Provide a 2-3 paragraph synthesis of how the precedent landscape applies to the [FACT_PATTERN]. Include an assessment of litigation risk or outcome likelihood, explicitly labeled as "Assessment, Not Prediction."
6. **Abstention**: If [CONTEXT] contains no cases from [JURISDICTION] or no cases with Medium or High factual similarity, state "Insufficient on-point authority retrieved" in the synthesis and do not fabricate applicability. If [CONTEXT] is empty, return {"error": "No context retrieved."}

## CITATION FORMAT
- Inline citations: (Case Name, Year, Court)
- Pinpoint citations to specific sections if available in [CONTEXT]
- Do not cite cases not present in [CONTEXT]

## CONSTRAINTS
- Do not provide legal advice. Label all outcome assessments as "Assessment, Not Prediction."
- Do not invent case names, holdings, or procedural history.
- If the [FACT_PATTERN] involves [RISK_LEVEL] risk (e.g., criminal liability, constitutional claims), append "[HUMAN_REVIEW_REQUIRED]" to the synthesis field.
- Limit direct quotes from cases to 50 words each.

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

To adapt this template, replace each square-bracket placeholder with your application's runtime values. [CONTEXT] should be populated by your retrieval pipeline with the top-k case law chunks. [FACT_PATTERN] is the user's case description. [JURISDICTION] should be a structured value like "Ninth Circuit, Federal" or "Delaware Chancery Court" to enable binding-authority logic. [OUTPUT_SCHEMA] should be a JSON Schema object defining the exact fields your downstream application expects—at minimum, include case_analyses (array), synthesis (string), and human_review_flag (boolean). [RISK_LEVEL] should be set by your application's classification layer before prompt assembly. If your system cannot determine risk level, default to requiring human review. Before deploying, validate the prompt against your golden dataset of fact patterns with known precedent outcomes, and run eval checks for citation hallucination, jurisdictional misattribution, and overgeneralization of precedent scope.

The Legal Precedent Analysis prompt is designed to operate inside a retrieval-augmented generation (RAG) pipeline, not as a standalone chat interaction. The application layer is responsible for assembling the correct context before the prompt is ever sent to the model. This means your retrieval step must surface the specific case opinions, statutes, and secondary sources relevant to the user's fact pattern. A naive keyword search will fail here. You need a hybrid retrieval strategy that combines dense vector search over case embeddings with metadata filtering on jurisdiction, court level, and date ranges. Without this pre-filtering, the model will receive irrelevant precedent and produce analysis that looks plausible but applies the wrong binding authority.

Once the prompt returns a response, the first gate is structural validation. The output schema expects a JSON object with case_holdings, factual_similarity_assessment, binding_authority_notes, and distinguishing_factors arrays. Your harness must parse this JSON immediately and check for missing required fields, empty arrays where content is expected, and malformed citation strings. If validation fails, do not show the user a broken partial answer. Instead, trigger a retry loop that feeds the validation error back to the model with the original context and a repair instruction. Limit retries to two attempts. If the model still cannot produce valid JSON, escalate to a human reviewer with the original query, retrieved context, and both failed attempts logged for diagnosis.

The highest-risk failure mode for legal RAG is overgeneralization of precedent scope. The model may cite a case correctly but apply its holding to a jurisdiction where it is not binding, or fail to note that a decision was overturned or limited by a later ruling. Your harness must include a post-generation Shepardizing check where possible. If your system has access to a citator API or a database of subsequent treatment, run every cited case through it. Flag any citation where the treatment is negative, the case was overturned, or the holding was narrowed. Append these flags to the output before it reaches the user. If you cannot perform automated citator checks, the output must carry a prominent, hardcoded warning that citation treatment has not been verified and the user must Shepardize all authorities before relying on the analysis.

Human review gating is mandatory for any output that will be used in a filing, client advice, or substantive legal work. Your harness should classify the [RISK_LEVEL] input parameter. If the risk level is high or the output contains a binding_authority_notes entry that identifies controlling precedent in the user's jurisdiction, route the complete analysis to a review queue. The review interface should display the generated analysis side-by-side with the retrieved source passages so the reviewer can verify each holding extraction and similarity claim against the original text. Log the reviewer's action—approve, edit, or reject—along with a timestamp and reviewer identity for audit trail purposes.

For model choice, prefer a model with strong legal reasoning benchmarks and a large context window. The prompt template expects substantial retrieved context, often multiple full case summaries. A context window of at least 128K tokens is recommended. If you are using a model with a smaller context window, you must implement aggressive context pruning before the prompt assembly step, ranking retrieved passages by relevance and dropping low-scoring results. This pruning itself introduces risk of omitting relevant authority, so log which passages were dropped and make them available in the review interface.

Finally, evaluation and monitoring must be continuous. Build a golden dataset of fact patterns with known relevant precedent and expected holding extractions. Run this dataset against every prompt version before release. Measure citation precision (are cited cases real and correctly attributed?), holding accuracy (does the extracted holding match the actual holding?), and jurisdictional correctness (does the analysis correctly identify binding vs. persuasive authority?). In production, monitor the rate of validation failures, retry escalations, and human reviewer rejections. A rising rejection rate is your leading indicator that retrieval quality has degraded or the prompt needs revision.