Is this just document search?

Retrieval is central, but the case-based purpose is to reuse prior experience for the current problem, with attention to relevant differences and outcomes.

Does it require a large language model?

No. Historical systems used information-retrieval techniques and domain knowledge; newer representations can be used without changing the basic idea.

Must all cases be manually rewritten into forms?

Not necessarily. Textual approaches specifically address existing narrative material, although useful metadata and reviewed features can improve comparison.

AI Glossary / Natural language and speech / Intermediate

Textual case-based reasoning

Definition

Textual case-based reasoning uses descriptions of previous situations, problems or experiences written in natural language to help address a new situation. It combines case-based reasoning with methods for representing, retrieving and interpreting textual material.

What it means

Many organizations record experience in service notes, project reports, incident descriptions and frequently asked questions. These documents can contain both a problem and evidence about what resolved it. Textual case-based reasoning aims to make that experience reusable.

The important comparison is not just whether two documents use similar words. A previous case may be relevant because its circumstances, constraints or failure mechanism resemble the current problem. Another case may sound similar while differing in a decisive detail.

The approach therefore needs an account of what makes cases usefully similar. Domain knowledge, extracted features and text representations can all contribute. Retrieval supplies candidates for reasoning; it does not establish that a previous solution should be copied unchanged.

How it works

A system builds or maintains a case collection linked to source documents. It identifies information that matters for comparison, such as symptoms, equipment type, version, attempted actions and outcomes. Depending on the design, those features may be manually recorded, extracted automatically or represented more indirectly.

A new description is mapped into a comparable form and used to retrieve relevant cases. The user or system examines similarities and differences, considers whether a recorded solution can be reused or adapted, and checks the result.

When an outcome is sufficiently established, it can inform the case collection. Failed attempts and applicability limits are also useful experience if they are recorded clearly.

Text introduces a particular difficulty: mentioning a factor is not the same as asserting that it applies. Negation, speculation and quotation can change how a passage should influence the comparison.

Three practical examples

A support engineer retrieves earlier tickets involving the same error under comparable software versions.
A project team reviews written lessons from earlier deployments before planning a new rollout.
An incident analyst compares event descriptions and attempted remedies to identify relevant prior experience for investigation.

Think of it this way

Think of consulting a colleague's organized notebook of past problems. The notebook is most useful when it records the circumstances, what was tried and what happened afterward.

The analogy also marks the limit: an old solution is a precedent to examine, not a universal instruction. Similar symptoms can arise from different causes, and changed conditions can make the earlier remedy unsuitable.

Worked example

Comparing cases with an explicit teaching score

Imagine a new printer-support case: no output, error E7 and firmware version 3. Define a simple illustrative score with weights 0.4 for the symptom, 0.4 for the error code and 0.2 for the firmware. Each exact feature match contributes its weight.

Case A matches the symptom and error but uses version 2. Its score is 0.4 + 0.4 = 0.8. Case B matches the symptom and firmware but reports error E9. Its score is 0.4 + 0.2 = 0.6.

Case A ranks first under the chosen rule. That ranking does not establish that its remedy is compatible with version 3. If the remedy is documented as version-2-only, the system should enforce that applicability condition before recommending it.

The example separates similarity ranking from solution validity. The weights are invented, not learned or calibrated probabilities. Changing the task or evidence could justify different weights or a hard compatibility filter before ranking.

Illustrative case study

A fictional facilities-software company builds a case browser from resolved support tickets. Its first ranking often returns long tickets with many repeated product names, even when their fixes concern a different configuration.

The team adds configuration metadata and displays the passages supporting key symptoms. It separates proposed fixes from confirmed outcomes and records when an earlier action failed.

Support staff can now review why a case was retrieved and whether its circumstances apply. The company evaluates usefulness on new cases rather than assuming a familiar-looking document is a correct answer. The case illustrates a possible workflow, not a measured deployment result.

Common misconceptions and mistakes

Equating document similarity with solution suitability. A decisive constraint may outweigh many shared words.
Treating every mentioned condition as present. Text may deny it or quote someone else's claim.
Assuming a closed ticket proves that the recorded action solved the problem. Closure reasons and outcome evidence need review.
Keeping only successful cases. Failed attempts can help avoid repeating unsuitable actions.
Letting stale cases remain authoritative indefinitely. Software, equipment and organisational processes change.

Business use

Textual case-based reasoning is useful when an organization repeatedly encounters related problems and has meaningful records of prior experience. It can support expertise transfer and make the basis of a suggestion inspectable.

Start with a bounded domain and a clear definition of case quality. Record context, source, outcome and applicability, rather than importing every document as an equally reliable case. Preserve access permissions when retrieving internal records.

Evaluate whether retrieved cases help users reach valid resolutions, not only whether they share vocabulary with a query. Track irrelevant suggestions and missing important precedents. Keep a process for updating, retiring or correcting cases when later evidence changes their interpretation.

Check your understanding

The highest-ranked past case uses an incompatible software version. Should its fix be applied automatically because the similarity score is highest?

Answer: No. Compatibility is an applicability condition. Ranking among candidates does not override evidence that a solution cannot be used in the current setting.

Related terms

Case-based reasoning
Similarity measure
Information extraction
case retrieval
knowledge management
solution adaptation
case maintenance

Learn next

Read case-based reasoning and information extraction. Take two fictional support notes with similar symptoms but different configurations, and identify which differences should block reuse of a proposed remedy.

Sources

Lenz, Knowledge Sources for Textual CBR Applications (1998): https://cdn.aaai.org/Workshops/1998/WS-98-12/WS98-12-006.pdf. Ashley and Brüninghaus, Developing Mapping and Evaluation Techniques for Textual Case-Based Reasoning (1998): https://cdn.aaai.org/Workshops/1998/WS-98-12/WS98-12-005.pdf. These primary sources establish the historical approach and text-to-case mapping concerns. The printer score and company story are original illustrations.

Previous: Text-to-video model Next: Textual entailment