Understand
Example-Based Explanation
How did similar cases turn out?
Explains a result by comparing it to cases the user can recognise, building intuition through analogy rather than abstraction.
Overview
Why it matters
Many people find comparisons easier than weights.
Factor lists and probabilities are hard work for most people. “Your application resembles cases where employment records were missing” often means more than a chart of feature weights.
Lawyers reason by precedent, doctors by comparison, and everyone asks “has this happened before?” This pattern uses that habit to make a complex decision easier to understand.
What does it look like?
Understanding a declined application
Understanding a declined application
- Applicant sees the decline and the factors behind the system’s recommendation.
- Below them, an “Applications like yours” section shows a one-sentence narrative and an outcome summary, not individual cases.
- A note says past outcomes reflect past decisions.
- A link leads to “What could change this?”.
Caseworker review
Caseworker review
- On 22 September, a caseworker reviews #4821: score 71 (range 64 to 78), the system recommends decline, employment records incomplete.
- “Similar applications” panel shows anonymized past cases compared on income, debt and employment status.
- Each card says why it is similar and shows its outcome; some were approved after records arrived, some declined.
- Caseworker uses the cases as context, checks this case’s factors, and requests the employment records.
Population context
Population context
- User asks “Is my situation unusual?”
- System shows: “Of 240 similar applications in the past 12 months, 180 (75%) received the same recommendation.”
- A note says past outcomes reflect past decisions and do not show that this one is right.
When does it fit?
Use it when
- The decision space has recurring patterns people recognize
- Experts benefit from precedent, as in clinical, legal or risk work
- Showing past cases is legally and privacy-wise possible
Skip it when
- Past cases can’t be anonymized properly
- Cases are too unique for meaningful comparison
- The model isn’t case-based and the comparison would be presented as the model’s reasoning
Design
How do I apply it?
-
Say what the comparison is based on.
Name the attributes used, and leave protected attributes and close proxies out.
-
Use real cases only if truly anonymized.
Detailed financial or health cases are hard to anonymize. Otherwise aggregate, or use clearly labeled illustrative cases.
-
Explain why a case is similar.
“Similar” means nothing without saying in what way.
-
Show variety, not just the closest match.
Two or three cases with different outcomes give a more honest picture.
-
Don’t let examples replace explanation.
Three similar declines can feel like fate. Link to the factors behind this case and to Actionable Recourse.
For your technical team
If the model is not case-based (unlike, for example, a nearest-neighbour model), similar cases are found separately from the model’s reasoning and may not reflect what drove this result. Prototype and criticism pairs from interpretable machine learning show both a typical case and a hard-to-classify one.
How can I show it?
Similarity score or label
How similar the example really is.
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.
Cases like yours narrative
One sentence on how cases like this usually go.
A short plain-language description: “Applications like this one, with incomplete employment records, were usually approved once the records arrived.” Translates the comparison into a readable statement rather than a visual.
Outcome distribution summary
“Of 84 similar cases, 61 were approved.”
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 resolved in the past. Say that past outcomes reflect past decisions.
Similar case cards
Two to four comparable cases with their outcomes.
Cards showing 2 to 4 comparable cases with the key attributes that make them similar, the outcome, and a brief explanation of relevance. Anonymized, or illustrative and labeled as such.
Counterfactual case
A case alike in all but one factor, with a different outcome.
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 close to yours that was approved: the main difference was that employment records were on file.”
Side-by-side comparison
This case and a similar one, differences visible.
A two-column layout placing the current case alongside a similar one. Key matching attributes are highlighted; differences are also visible, not hidden.
Prototype and criticism pair
A typical case next to an unusual one.
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 (caseworkers, analysts) who reason by analogy and benefit from understanding both the rule and its exceptions.
Similarity labels go with any of the others.
What does it cost?
Explanation vs. privacy
Real cases convince, but detailed financial or health records are hard to anonymize. A few details can be enough to recognize a person. Aggregate or use labeled illustrative cases unless real cases can be truly anonymized.
Similarity vs. misleading analogy
Two cases can look alike and differ where it matters. A match on visible attributes can hide the factor that drove the outcome. Show the differences as well as the matches.
Intuition vs. false precedent
Past outcomes reflect past decisions, including past bias. A typical outcome does not show that this one is right. Say that past outcomes are context, not a rule.
Connections
Which patterns work with it?
Attribution
Why did the system recommend this?
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.
Counterfactual Explanation
What would have changed the outcome?
A near-miss case is close to a counterfactual, but a real case differs in more than one way. Say which differences matter.
Actionable Recourse
What can I do to change this outcome?
Showing a case that was approved due to one different factor creates a natural bridge to recourse: “here’s what that person had that you could also provide.”
Role-Based Explanations
Does this explanation fit who I am and what I can do?
Expert users (caseworkers, 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 (3)
Sources (3)
Lipton (2018) — The Mythos of Model Interpretability
argues interpretability is not one property; notes that explanation by example mirrors how humans justify by analogy, e.g. doctors citing case studies (arXiv 2016; ACM Queue 2018)
Aamodt & Plaza (1994) — Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches
widely cited overview of case-based reasoning, including the retrieve, reuse, revise, retain cycle. Published in AI Communications, 7(1), pp. 39 to 59
Molnar (2025) — Interpretable Machine Learning
comprehensive reference covering example-based methods including influential instances, prototypes and criticisms, and counterfactuals. 3rd edition (2025), the version the URL serves
Your users have no statistics background, and your explanations assume they do.
Especially in health, benefits and legal settings, comparison is how people reason. That’s where this pattern starts. Let’s look at your interface together.
Work with me