Textual Case Based Reasoning¶
A case-based method that uses text-bearing past cases to retrieve relevant experience or reuse it for a new problem.
Core Idea¶
Textual case based reasoning (TCBR) brings past cases recorded in or derived from natural-language text to bear on a new case-solving task. A system must connect that text to a task-relevant case relation: it may return earlier cases useful to a person, compare cases to analyze a new problem, or reuse earlier solution text in a proposed answer. Text can carry the problem, the stored case, the solution, or a representation derived from them. Neither one NLP algorithm nor a complete retrieve–reuse–revise–retain cycle is required in every instance.[1][2][3]
This is narrower than case-based reasoning in general because text-bearing case knowledge is essential. It is also more specific than ordinary document search because the returned or processed text serves a defined case-based problem-solving task. In one original study, legal fact text is converted to case factors before issue analysis and prediction. In another, stored email requests and responses provide material for a new response whose final wording remains under a writer's control.[1][2][3]
Structural Signature¶
Four roles identify the method:
- New problem. A target case or request defines what prior experience would be relevant. Without a current case-solving task, a text search is not enough.[1][2][3]
- Text-bearing case knowledge. Some past-case material used for the task is natural-language text or is extracted from it. A purely structured feature-vector case base with no textual knowledge would be generic CBR, not the textual subtype.[1][2][3]
- Task-relevant text-to-case bridge. The method makes textual material usable as cases for the task. This might be factor indexing, passage relevance, text-sensitive retrieval, or another representation and comparison strategy. No one bridge is universal.[1][2][3]
- Case-based output. The earlier cases materially help address the new one. The output may be a relevant retrieved case or set for further reasoning, an analysis, or a reused/adapted answer. Requiring every system to generate its own final answer would exclude retrieval-focused TCBR expressly recognized in the field.[1][2][3]
The representation, similarity or relevance test, and later adaptation are design choices constrained by the task. A case need not be a full unstructured document; its textual component only needs to matter to case use. Conversely, text classification by itself does not become TCBR unless its output is used in a case-solving relation.[1][2]
What It Is Not¶
- Not all case-based reasoning. Structured cases can be retrieved and adapted with no text-bearing knowledge; the textual subtype adds a representation or access problem.[1]
- Not generic information retrieval. Returning topically similar documents without a defined new case and case-solving relation lacks the method's purpose. Returning relevant textual cases to support that purpose may qualify even when a person does later reasoning.[1][2]
- Not a mandatory four-stage cycle. Retrieval, reuse, revision, and retention describe a common CBR framework, but retrieval-focused textual systems are still within this category. Neither worked case proves that every query revises and retains a new case.[1][2][3]
- Not legal precedent as such. Prior judicial decisions may be a source of cases, but their binding or presumptively authoritative legal force is not required in email response reuse or every TCBR system.[2][3]
- Not one accuracy guarantee. The legal study reports a gap between automatic and manual representation; the email study evaluates passage selection, not autonomous final-message quality.[2][3]
Scope of Application¶
TCBR is literal when natural-language material from earlier cases informs a new case-solving task. Its text-sensitive bridge can range from retrieval that surfaces relevant cases to richer extraction and adaptation. In the legal example the task is issue analysis and prediction from fact summaries. In the email example the task is preparing a response from earlier request/response pairs. The difference in task and output is substantial, while the four roles remain recognizable.[1][2][3]
The selected candidate provenance is the article Textual case-based reasoning. A frozen screening seed described broad CBR and included nontextual planning examples; those examples do not by themselves support this narrower entry. The live Prime Precedent (Stare Decisis) has the alias case_based_reasoning, but its legal-authority commitment is not this method's identity. The exact alias is a vocabulary collision requiring care, not evidence that this subtype is already covered.[1][2][3]
Clarity¶
The label forces a writer to specify three otherwise hidden choices: which part of a case is textual, how text is connected to the current problem, and what case-based output is expected. Saying only that a system “uses examples” or “searches text” hides the mechanism. SMILE turns legal fact sentences into Factors for IBP's case comparison; the email system retrieves a request/response pair and marks response passages for possible reuse. Those are different bridges, not interchangeable implementations.[2][3]
Manages Complexity¶
Past cases hold detailed experience that may be hard to rewrite as general rules. A text-to-case bridge makes some of that experience available without requiring all cases to begin as hand-built structured records. The bridge also introduces uncertainty: factor extraction may miss case features, and reusable text may contain details inappropriate for the new request. A system should keep these limits visible rather than treating a retrieved case or annotated response as a verified final solution.[2][3]
Abstract Reasoning¶
To analyze a candidate system, ask: What is the new problem? Which earlier cases supply text-bearing knowledge? How does the system relate their text to the problem? What case-based material or conclusion does it return? The test admits retrieval-only systems when the retrieved items are task-relevant cases, while excluding a generic document search with no case-solving relation. It also permits a legal prediction and an assisted email response to share a type without forcing their algorithms or outputs to match.[1][2][3]
Knowledge Transfer¶
The portable question is how to use prior textual experience for a new case. Legal factor extraction shows one way to translate text into comparable case features; email passage annotation shows a different way to reuse solution text. Transferring the idea to another domain requires a new account of what counts as a case, how relevance is judged, and who validates the output. The legal study's factors or the email study's passage classes cannot be presumed to work elsewhere.[2][3]
Examples¶
Legal case analysis and prediction. Brüninghaus and Ashley's SMILE+IBP framework accepts a textual summary of a new trade-secret case. SMILE identifies Factor indices from text; IBP uses those factors to compare prior cases, analyze legal issues, and predict an outcome or abstain. Here the new summary is the target problem, earlier fact texts are case knowledge, factor indexing is the bridge, and issue analysis/prediction is the output. The study evaluated 146 manually marked cases under leave-one-out testing; its reported automatic representation was less effective than manual indexing and did not establish practical deployment.[2]
Email response reuse. Lamontagne and Lapalme store earlier request/response messages as textual case pairs. For a new email request, the system retrieves an earlier response and identifies passages that may be kept, omitted, or changed. The new request is the target, stored messages are cases, retrieval and passage annotation form the bridge, and the annotated proposed response is the output. The human writer decides whether to make final changes. The paper's experiments compare passage-selection strategies, not the quality of fully autonomous finished replies.[3]
Structural Tensions¶
No one opposed pressure defines every TCBR instance. A particular system may balance broad retrieval against case relevance, or automatic extraction against expert indexing effort. The legal and email studies expose such design choices, but their different objectives do not establish one universal accuracy–effort tradeoff. The identity instead rests on text-bearing prior cases serving a defined new case-solving task.[2][3]
Structural–Framed Character¶
The method is structural within AI practice: a new problem is related to past text-bearing cases through a task-sensitive bridge. It is framed by human decisions about case boundaries, relevance, and usable output. “Case” appears in both the legal and email CBR studies; that shared vocabulary does not make legal obligation to follow a prior decision part of the email method. TCBR is a label within CBR and AI research, with no inherent moral or prestige claim and no particular institution constituting its computational identity. Calling an ordinary document search “case based” would import a label without its defining problem-to-prior-case relation; recognizing that relation is the criterion. Its character: a computational method with a transferable case-use structure, bounded by text representation and by the task that gives case relevance meaning.[1][2][3]
Structural Core vs. Domain Accent¶
The core is text-bearing prior experience made usable for a new case-solving task. Legal factor classification, case outcome prediction, email passage annotation, and human control of final changes are domain accents. A broader “retrieve earlier experience for a new case” skeleton is visible in the live Exemplar Retrieval Prime, but its closest-case and response-template commitments fail an all-instance parent test for this subtype. No current live parent passed the full test; whether a more general case-use Prime should exist is a future question. Textual representation and computational problem solving keep this entry domain-specific.[1][2][3]
Instantiates / Related Primes¶
This entry is an approved unparented root under the current catalog: no tested neighbor is a necessary complete parent of both retrieval-focused and factor-based textual CBR. Exemplar Retrieval requires closest-case response reuse that these cases need not perform. Search and Retrieval brings a fuller search signature and strict ancestors that need not hold in every assisted case use. Knowledge Representation and Reasoning requires formal semantics and inference commitments absent from some text reuse. The live Precedent (Stare Decisis) Prime is a different legal norm despite its broad case_based_reasoning alias. These remain neighbors without a typed edge.
Neighborhood in Abstraction Space¶
Textual Case Based Reasoning sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2721 abstractions)
Nearest neighbors
- Example-First Modeling — 0.77
- Extended Boolean model — 0.76
- Uniform Resource Identifier — 0.76
- Text mining — 0.76
- YARA — 0.76
Computed from structural-signature embeddings · 2026-10-17
Not to Be Confused With¶
- Generic text search: topical document retrieval without a defined case-solving task and prior-case relation.[1]
- Structured CBR: case-based inference when text-bearing knowledge is absent.[1]
- Legal stare decisis: a doctrine giving past decisions binding or strongly persuasive authority, unlike the general computational text-to-case method.[2][3]
- The SMILE+IBP or LUG implementation: each is one domain-specific realization, not the definition of all textual CBR.[2][3]
References¶
[1] Weber, Ashley, and Brüninghaus, “Textual case-based reasoning,” The Knowledge Engineering Review 20, no. 3 (2005 issue; online 2006), 255–260, DOI 10.1017/S0269888906000713. Publisher record and abstract; full original-author manuscript, §§1 and 3. Commentary/survey used for terminology and boundary, not as an original experiment; manuscript publication metadata is provisional. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q
[2] Brüninghaus and Ashley (2006), “Progress in Textual Case-Based Reasoning: Predicting the Outcome of Legal Cases from Text,” Proceedings of AAAI 2006, 1577–1580, PDF pp. 1–4, especially SMILE+IBP Figures 1–3 and the evaluation. Original publisher paper. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w
[3] Lamontagne and Lapalme (2004), “Textual Reuse for Email Response,” Advances in Case-Based Reasoning, LNAI 3155, 242–256, DOI 10.1007/978-3-540-28631-8_19, §§2–6 and Tables 1–2. Complete author-uploaded original paper. The university-hosted PDF was inaccessible on direct open; the author-uploaded original text was inspected. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u