Counterfactual Explanations
Not why — what would change the answer
A counterfactual says what minimal change to the inputs would flip a prediction. Unlike attributions, it's actionable: 'raise revenue by 8% and keep inventory under 1.2M and the loan is approved'.
What you will learn
- Formulate counterfactual search as minimal perturbation
- Compare counterfactuals vs SHAP (attribution vs action)
- Apply constraints: feasibility, actionability, sparsity
What is this?
A counterfactual explanation answers: 'what is the smallest change to THIS input that would flip its prediction?' — e.g. from reject to approve. You search the input space for a nearby instance whose predicted class follows the desired rule, minimizing a distance (ideally weighted by feature actionability and feasibility). Results read as 'change A to A′ (and nothing else) to get X'. It's the natural bridge from explainability to decision support.
Why do you need it?
- Actionability: attribution says 'income pushed you down'; counterfactual says what to ACTUALLY change.
- Justification: 'we can't approve today; here's exactly what would change that' is defensible.
- Sparsity: models surface a one-line, low-dim instruction rather than a full explanation.
- Natural AI-as-advisor: used directly in catalogs, portfolio and what-if tools.
Mental model
A driving instructor saying exactly which move changes the route
A counterfactual
Instead of 'your route was heavy on the highway' (attribution), the instructor says: 'turn right at the next light instead of the highway and the trip fits the time limit' — a minimal, actionable change that flips the outcome from late to on time.
How it works
- Define desired outcome (e.g. y ≥ threshold) and feature distance (weighted L1/L2 in scaled space).
- Search: optimize (or enumerate) neighboring inputs that achieve the flip while minimizing distance.
- Sparsity: penalize nonzero changes so few features move — explanations stay legible.
- Feasibility: hard-constrain immutable features (age, zip, contract type) to remain fixed.
- Validity check: the flipped instance must be a plausible real-world point, not adversarial noise.
Nearest instance on the other side of the boundary.
In production
- Lending: auto-generate 'how to get approved' letters with concrete knobs.
- Churn: alert the CS team with the one or two plan changes predicted to keep the customer.
- Ops: model flips into diagnostic suggestions for failing services.
Best practices
- Weight distance by actionability: immutable features cost infinite; hard-to-change cost high.
- Verify plausibility — reject CF instances that fall outside the training manifold.
- Offer 3-5 diverse alternatives (different features) so users have choices.
- Pair CFs with a validity number (model confidence at the flipped point) for honesty.
Common mistakes
- Suggesting changes to immutable features ('change your age').
- Finding a mathematically-near but physically-impossible point and shipping it.
- Treating CFs as upper-bound guarantees — the model is what it is.
- Retraining drift: a CF computed on a stale model version misleads decisions.
Common issues
CF suggests changing immutable fieldNo actionability weights in the objective
Set immutable-feature cost to ∞ (hard constraint) in the search.
All users get the same CFSearch collapsed to one global boundary point or over-tight sparsity
Diversify: multiple restarts, different intializations, and a diversity term across returned CFs.
CF flips prediction but looks impossible in realityObjective minimized raw distance off-manifold
Constrain features to plausible ranges; clamp to observed percentiles; validate with a density check.
Debugging tips
- Sanity: flip a known-easy boundary case first; the CF should be a small, sensible move.
- Run sensitivity: does the minimal CF jump when you tweak weights? Unstable CF = weak search config.
- Log the instance's true position: nearby adversarial CFs (with microscopically small deltas) should be excluded.
- Compare a CF against a hand-built feasible alternative for realism.
Interview checkpoint
Quick quiz
A counterfactual explanation is primarily:
Counterfactual search should always allow changing age or contract type freely.