Explainables
Created with the help of AI
Category — Understand

Example-Based Explanation

causal reasoningaudience adaptationinteractive inquirycognitive accessibility
User question

What similar cases influenced this result?

Consulting signal

Useful when clients need to explain AI decisions to users who have no statistical background: particularly in healthcare, benefits, and legal contexts where precedent and comparison are natural reasoning modes.

Overview

Why this pattern exists

Abstract factor lists and probability scores are cognitively demanding for most users. People understand by comparison: by seeing how their situation relates to others like it. "Your application resembles cases where the primary issue was income instability" is often more meaningful than a bar chart of feature weights.

Example-based explanation draws on how humans naturally reason about unfamiliar decisions: through analogy, precedent, and prototype. In legal reasoning, precedent is the primary basis for judgment. In medicine, differential diagnosis is comparison-driven. In everyday life, people ask "has this happened before?" before trusting a new outcome.

For AI systems, this pattern is particularly valuable when the underlying model logic is complex or opaque: presenting a comparable case can make an otherwise abstract decision feel legible without requiring the model internals to be exposed.

Design goal

Help users understand an AI decision by showing how it relates to comparable cases: building intuition through analogy rather than abstraction.

Usage guidance

When to use

  • The decision space has recurring patterns that users can recognize from their own experience
  • The user needs to develop intuition about how the system behaves across cases
  • Showing similar past cases is legally permissible and privacy-compliant
  • The model uses case-based or nearest-neighbor logic internally (kNN, case-based reasoning)
  • Users are experts reviewing AI-assisted decisions and benefit from precedent (clinical, legal, risk)

When not to use

  • Similar cases would expose other users' private data without appropriate anonymization
  • The decision space is too unique or sparse for meaningful comparisons
  • Similar cases might mislead: two superficially similar cases may have important differences that are not visible in the display
  • The system's logic is not actually case-based and the comparison would be a post-hoc approximation that could mislead users

Design

UI primitives

Content Block / Card Set

Similar case cards

Cards showing 2–4 comparable cases with the key attributes that make them similar, the decision outcome, and a brief explanation of relevance. Anonymized where needed.

Inline Signal / Label

Similarity score or label

A signal showing how similar the example case is: "very similar" or "moderately similar", so users can calibrate how much weight to give the comparison.

Data Visualization / Comparison

Side-by-side comparison

A two-column layout placing the current case alongside a similar one. Key matching attributes are highlighted; differences are also visible, not hidden.

Content Block / Summary

Outcome distribution summary

Instead of individual cases, a summary view: "Of 84 similar applications, 61 were approved, 23 were declined." Gives a population-level sense of how cases like this typically resolve.

Content Block / Narrative

Cases like yours narrative

A short plain-language description: "Applications with similar income levels and employment gaps are typically referred for manual review." Translates the comparison into a readable statement rather than a visual.

Content Block / Card

Counterfactual case

A specific example showing a case that is similar except for one key factor, and had a different outcome. This is a bridge between Example-Based Explanation and Counterfactual Explanation: "Here's a case nearly identical to yours that was approved: the main difference was verified income documentation."

Content Block / Card Pair

Prototype and criticism pair

A two-example format drawn from interpretable machine learning: a prototype is a representative case that shows what a typical outcome of this type looks like; a criticism is a case that is unusual or hard to classify: one that the prototype does not fully explain. Showing both together gives users a richer sense of the decision space than any single comparison. Useful for professional audiences (clinicians, analysts) who reason by analogy and benefit from understanding both the rule and its exceptions.

How to use

Design for how domain experts already reason.

Case-based reasoning research shows that clinicians, lawyers, and analysts routinely solve new problems by retrieving and adapting solutions from memory. Example-based explanation meets these users where they already are: it doesn't ask them to adopt a new cognitive model. For lay users, examples still outperform abstract feature lists because they anchor the explanation in something concrete and comparable.

Prioritize anonymized real cases over synthetic ones.

Real cases carry more credibility. Where privacy prevents disclosure, anonymize by removing or generalizing identifying attributes, but be explicit that the examples have been anonymized.

Show why the example is similar, not just that it is.

"Similar case" means nothing without knowing in what way it's similar. Always surface the attributes driving the comparison.

Show diversity in examples, not just the nearest match.

Showing only the single most similar case can create a false sense of precision. Showing 2–3 cases with different outcomes gives a more honest picture of the decision space.

Don't use examples as a substitute for explanation.

Comparison is not causation. A user seeing three similar declined cases might conclude "cases like mine always fail": even if their specific situation is addressable. Pair examples with Actionable Recourse to prevent fatalism.

Be explicit about the comparison basis.

Users should understand whether similarity is being calculated on all attributes, a subset, or a specific focus area.

Use cases

flow a

Understanding a declined application

  1. 1. User sees their declined decision.
  2. 2. Below the attribution section, a "Similar cases" section shows 3 anonymized case cards.
  3. 3. Each card shows: key matching attributes, outcome, and a one-sentence similarity note.
  4. 4. One card is a "near-miss" case that was approved: showing what was different.
  5. 5. User understands their outcome in context of a recognizable pattern.
flow b

Expert review

  1. 1. Clinician reviews an AI-assisted diagnosis recommendation.
  2. 2. "Similar patients" panel shows 5 historical cases with matching symptoms and test results.
  3. 3. Clinician can view the full treatment path and outcome for each case.
  4. 4. Clinician uses the precedent cases to validate or challenge the AI recommendation.
flow c

Population context

  1. 1. User asks "Is my situation unusual?"
  2. 2. System shows: "Of 240 similar cases in the past 12 months, 78% received the same recommendation."
  3. 3. User understands their outcome is typical for their profile, not an anomaly.

Design trade-offs

Explanation vs. privacy

Real cases are more credible than synthetic ones but raise data protection concerns. Establish a clear policy: anonymize, aggregate, or generate synthetic cases. Be transparent with users about which approach is used.

Similarity vs. misleading analogy

Two cases can be superficially similar but differ in ways that matter greatly. A comparison that looks reassuring may actually be inapplicable. Use similarity scores and show differences, not just matches.

Intuition vs. false precedent

Example-based explanation can create an impression of legal or policy precedent where none exists. Be clear that similar past outcomes do not guarantee or constrain future decisions.

Connections

Relation to other patterns

Attribution explains factors within a case. Example-based explanation explains the decision by reference to other cases. They answer the same underlying question through different cognitive approaches.

Expert users (clinicians, analysts) benefit from richer case detail; lay users benefit from summary comparisons. The same underlying case data can be presented at different depths by role.

Sources

argues that interpretability is not a single property and that different users need different forms of explanation. Example-based approaches are identified as naturally aligned with how domain experts (clinicians, lawyers) already reason

foundational paper establishing case-based reasoning as a cognitive model and AI methodology. The pattern draws on this tradition: humans solve new problems by retrieving and adapting solutions from similar past cases, a process CBR formalizes. Published in AI Communications, 7(1), pp. 39–59

comprehensive reference covering example-based methods including influential instances, prototypes, and counterfactuals. Provides the technical context for the UI decisions in this pattern

Explainables
Created as a side project by Christian Laesser & AI