Case-Based Reasoning System¶
Reasoning system — instantiates Nearest-Exemplar Response Reuse
Runs the full retrieve–reuse–revise–retain loop, but earns its keep at the revise step: it adapts a retrieved case's solution to the new case's specific differences rather than copying it.
A Case-Based Reasoning System solves a new problem by remembering how a similar one was solved, then changing that solution to fit. It is organized around the four-Re cycle — retrieve the closest prior case, reuse its solution, revise it to match the differences, and retain the finished case for next time.[n1] What separates it from a lookup table or a nearest-neighbor vote is the revise step: the system does not hand back the old answer, it produces an adaptation delta — an explicit record of which parts of the retrieved solution were kept, which were transformed, and why. The encoded present case and the curated case base are its raw materials; the adaptation of the delta is the work only this mechanism does. Everything upstream (how "closest" is measured) it borrows; the transformation from old solution to new is what makes it case-based reasoning rather than case-based recall.
Example¶
A field technician's tablet app helps diagnose a rooftop HVAC unit that will not cool. She enters the present case: unit model, symptom ("compressor runs, no cold air"), error code E4, ambient temperature, refrigerant type. The app encodes this into a comparable case profile and retrieves the closest resolved job from the company's case base — a fix from a neighboring county three weeks earlier where E4 plus the same symptom meant a failed contactor. That retrieved case proposed "replace contactor, recharge refrigerant."
Here the system does its actual job. It does not just show her the old ticket; it walks the deltas. The retrieved unit used R-22 refrigerant; this one is R-410A, so the recharge pressures and the recovery procedure differ — the app substitutes those steps. The old unit was single-stage; this one is two-stage, so it adds a second-stage lockout check the original fix never needed. The output is the reused solution with a running adaptation note: "contactor replacement carried over as-is; refrigerant steps adapted R-22→R-410A; added two-stage lockout check." She fixes it in one visit, and the completed, adapted case is retained so the next R-410A E4 job starts closer to done.
How it works¶
The distinguishing machinery lives in reuse-plus-revise:
- Encode the present case into a profile of decisive features so it can be compared at all — the same features the case base is indexed on.
- Reuse, then walk the deltas. Once a case is retrieved, mark each feature as matching (carry the solution part as-is), adaptation-relevant (transform it), or blocking (the retrieved solution cannot cover it). The adaptation itself uses substitution (swap a parameter), transformation (rework a step), or, when deltas pile up, rejection.
- Bound the adaptation. Track how much of the old solution survived unchanged; a solution that had to be almost entirely rewritten is a signal the retrieval was wrong, not that the reasoning was clever.
- Retain. Append the finished, adapted case to the base so future retrievals land closer.
Tuning parameters¶
- Adaptation aggressiveness — how far the system will bend a retrieved solution before it refuses. Aggressive adaptation solves more cases from a thin base but risks patching a poor match into a plausible-looking wrong answer.
- Case granularity — whether an exemplar is a whole job, a subproblem, or a single step. Finer cases adapt more cleanly but multiply retrievals.
- Retain policy — which finished cases re-enter the base (all of them, only successes, only novel ones). Retaining everything grows coverage but also grows noise and redundancy.
- Delta threshold for rejection — the amount of required adaptation past which the system escalates instead of adapting. Set it low and you escalate too often; set it high and you rationalize bad matches.
When it helps, and when it misleads¶
Its strength is handling situations whose decisive detail is a configuration that no compact rule captures — exactly where an abstract policy is too crude but a close prior case, suitably adjusted, is not. Because it records what it changed, its reasoning is auditable and teachable.
Its central failure mode is over-adaptation: stretching a retrieved solution across differences it was never meant to cover, so the adaptation delta quietly becomes a rewrite while the system still reports a confident "based on case #4471." The classic misuse is treating adaptation effort as a virtue — the more the technician had to change, the worse the underlying match, not the better. The guarding discipline is an honest adaptation budget: when the deltas exceed a set share of the solution, the system must reject the match and escalate to fresh analysis rather than keep bending, and it should flag heavily-adapted reuses for review before they are retained as if they were clean exemplars.
How it implements the components¶
query_case_profile— encodes the present situation into the comparable feature profile the retrieval and adaptation both run on.stored_exemplar_case— maintains the case base of prior situations with their solutions and outcomes, and grows it at the retain step.adaptation_delta_note— its signature output: the explicit, per-feature record of what was carried over, what was transformed, and why.
It does not compute the match itself — the similarity_metric belongs to Similarity Search over Case Embeddings and the voting neighbor_set to K-Nearest-Neighbor Case Matcher; it does not fix a fast, coverage-bounded response_reuse_boundary as an immediate starting action — that's Incident Playbook Lookup; and its retain step merely appends to the case base, whereas the governed outcome_feedback_update_record that tracks each exemplar's authority across reuses is Exemplar Feedback Registry's.
Related¶
- Instantiates: Nearest-Exemplar Response Reuse — this is the archetype's most literal mechanism, scoped here to its distinctive adapt-and-retain contribution.
- Consumes: Similarity Search over Case Embeddings (or a rubric) for the retrieve step; Exemplar Feedback Registry for durable outcome tracking beyond a simple append.
- Sibling mechanisms: K-Nearest-Neighbor Case Matcher · Similarity Search over Case Embeddings · Precedent Matching Workflow · Incident Playbook Lookup · Expert Case Recall Checklist · Case Similarity Rubric · Exemplar Feedback Registry
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Runs the full retrieve–reuse–revise–retain loop, but earns its keep at the revise step: it adapts a retrieved case's solution to the new case's specific differences rather than copying it, making its operative form a computation, comparison, model, or analytic representation used to infer, estimate, or choose.
Independent corroboration: The frozen evidence defines Case-Based Reasoning System as 'Runs the full retrieve–reuse–revise–retain loop, but earns its keep at the revise step: it adapts a retrieved case's solution to the new case's specific differences rather than copying it', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Artificial-intelligence research formalized case-based reasoning as the retrieve–reuse–revise–retain cycle, with adaptation distinguishing it from retrieval.
Related originating lineages:
- Cognitive Science — Research on analogical memory and similarity-based retrieval supplied the cognitive model formalized by case-based AI.
Review resolution: Computer science is primary because the retrieve-reuse-revise-retain cycle is the canonical AI formulation of case-based reasoning. Cognitive science supplies the analogical-memory lineage; legal precedent is an analogy and application rather than a necessary independent origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
"Case-based reasoning" is often used loosely for the whole archetype. As a mechanism it is narrower: the retrieve and score steps are delegated to matchers, and its irreducible job is the revise step — turning a retrieved solution into an adapted one and keeping the trail of what changed.
[n1] The four-Re cycle — Retrieve, Reuse, Revise, Retain — is the canonical structure of case-based reasoning, articulated by Aamodt and Plaza. The Revise step (adaptation) is the part that distinguishes reasoning from mere retrieval. ↩