Legal Brief Fact vs Argument Extraction Prompt

This prompt is designed for legal review teams and litigation support engineers who need to programmatically separate asserted facts from legal argument, characterization, and rhetorical framing within briefs and filings. The core job-to-be-done is transforming a dense, persuasive legal document into a structured artifact where every sentence is classified as a 'Fact' (a verifiable statement with a record citation), an 'Argument' (a legal conclusion, characterization, or persuasive framing), or 'Mixed' (a sentence containing both). The ideal user is a technical operator building a verification or case-preparation pipeline, not a lawyer performing a one-off manual review. Required context includes the full text of the legal brief and, critically, the associated record citations or an instruction to flag facts that lack them.

Do not use this prompt when the goal is to summarize a brief, predict a judicial outcome, or provide legal advice. It is strictly an extraction and classification tool. It is also inappropriate for documents where the record is not yet established, such as initial complaints drafted entirely on information and belief, because the distinction between a 'fact' and an 'allegation' becomes a matter of procedural posture rather than textual structure. For high-stakes filings, the output of this prompt must be treated as a first-pass draft for human review, not a final work product. A legal professional must validate the classification of every 'Mixed' sentence and confirm that no argumentative characterizations were mislabeled as facts.

Before integrating this prompt into a production system, define your tolerance for two specific failure modes: false positives (argument labeled as fact) and false negatives (fact labeled as argument). In legal workflows, a false positive is often more dangerous, as it can lead to an argument being mistakenly treated as an established fact in downstream analysis. Your evaluation harness should weigh recall on fact extraction against precision on argument exclusion, and you should implement a human-in-the-loop review step for all 'Mixed' classifications and any fact statement that lacks an explicit record citation. Proceed to the prompt template section to copy the base instruction and adapt the placeholders to your document type and output schema.

This template is designed to be copied directly into your prompt library or orchestration layer. It instructs the model to separate asserted facts from legal argument, characterization, and rhetorical framing within a provided legal brief. The prompt uses square-bracket placeholders for all variable components—input text, output schema, constraints, and examples—so you can wire it into a production pipeline without manual rewriting. The core instruction forces the model to output only fact statements with record citations and argument passages flagged separately, never blending the two.

textCopy
You are an expert legal analyst. Your task is to process the provided legal brief and separate every sentence into one of two categories: (1) Asserted Fact, or (2) Legal Argument, Characterization, or Rhetorical Framing.

For each sentence in the brief, apply these rules:
- An Asserted Fact is a statement that can be verified against a court record, document, witness statement, or physical evidence. It must be capable of being true or false independent of legal interpretation.
- Legal Argument, Characterization, or Rhetorical Framing includes any statement that applies law to facts, characterizes evidence, draws inferences, uses persuasive language, or frames facts to support a legal conclusion.
- If a single sentence contains both a factual assertion and argumentative language, extract the factual core as an Asserted Fact and flag the remainder as Argument. Do not discard embedded facts.
- For every Asserted Fact, provide the most specific record citation available in the text. If no citation is present, note "No citation provided."

[INPUT]

[CONSTRAINTS]

[EXAMPLES]

[OUTPUT_SCHEMA]

To adapt this template for your workflow, replace each placeholder with concrete values. [INPUT] should contain the full text of the legal brief. [CONSTRAINTS] can specify jurisdiction-specific rules, page limits, or additional classification categories like 'Procedural Statement' or 'Mixed.' [EXAMPLES] should include 2–3 few-shot demonstrations showing correctly classified sentences, especially edge cases where facts are embedded in argumentative sentences. [OUTPUT_SCHEMA] must define the exact JSON structure you expect—typically an array of objects with fields for sentence_text, classification, extracted_fact (if applicable), citation, and rationale. In high-stakes legal workflows, always route outputs with low-confidence classifications or missing citations to a human reviewer before the extracted facts enter any downstream verification or filing system.

This prompt is designed to be a single step within a larger legal document processing pipeline. It should not operate in isolation. The application layer must manage document ingestion, chunking, and output aggregation. Because legal briefs often exceed typical context windows, you must implement a pre-processing step that splits the brief into manageable sections (by heading, argument section, or page range) while preserving citation anchors. Each chunk is then processed independently through the prompt, and the results are merged in a post-processing step that deduplicates fact statements and aligns argument passages with their original document positions.

The implementation harness must enforce strict output validation before any extracted content is accepted. Validate that every fact statement includes a non-empty record_citation field and that the fact_text is a self-contained, atomic assertion. Argument passages must include both argument_text and argument_type classifications. Implement a retry loop with a maximum of two attempts: if the model returns malformed JSON or fails to separate facts from arguments, re-inject the raw output and the original chunk into the prompt with a specific error directive (e.g., 'The previous output failed schema validation. Ensure every fact has a citation and every argument has a type.'). After two failures, flag the chunk for human review rather than silently dropping it. Log every extraction attempt, including the model version, chunk identifier, validation errors, and retry count, to support audit trails and prompt debugging.

Model choice matters for this workflow. Use a model with strong legal reasoning and structured output capabilities, such as Claude 3.5 Sonnet or GPT-4o, and set the temperature to 0 or a very low value (0.1) to maximize extraction consistency. Do not use this prompt with small or general-purpose models that lack the capacity to distinguish legal argument from factual assertion. For high-stakes filings, route all outputs to a human review queue where a legal professional can confirm fact-argument boundaries before the extracted data is used in downstream analysis or case strategy. Avoid treating the model's classification as ground truth; it is a first-pass triage tool that accelerates human review, not a replacement for legal judgment.