As a counterfactual explanation for a demoted marketplace seller, why prefer '3 fewer late shipments' to '400 more orders'?

## What a counterfactual explanation is Most explanation methods answer 'why this decision?'. A **counterfactual** answers a more directly useful question: 'what would have had to be different for the decision to go the other way?' Formally, given an input `x` that the model scored into an unwanted class, you search for a nearby point `x'` such that the model's prediction at `x'` is the desired class, while `d(x, x')` — a distance between the two rows — is as small as possible. The reported explanation is the *difference*: the handful of feature values that moved, and by how much. For a marketplace seller demoted by a trust score, two candidates might both clear the bar: - `late_shipments: 11 -> 8` - `lifetime_orders: 60 -> 460` Both are valid counterfactuals. Only one is worth sending to the seller. ## The four properties that separate good from valid **1. Validity.** The changed row must actually cross the model's decision boundary into the desired class. This is a hard requirement, checked by scoring `x'` with the model — never assumed. A 'counterfactual' that does not flip the prediction is simply wrong. **2. Proximity.** Among valid candidates, prefer the one closest to the original row. Closeness is what makes the explanation intelligible; a point on the far side of the feature space tells the seller nothing about their own situation. Distance is usually computed per feature and then summed, because raw units are not comparable — a change of 3 in a count that ranges 0 to 15 is enormous, and a change of 3 in a count that ranges 0 to 5000 is nothing. The standard fix is to divide each feature's change by a measure of that feature's spread in the data (its standard deviation, or a robust equivalent), so distances are expressed in typical units. Without that scaling, the widest-ranged column dominates and the search returns nonsense. **3. Sparsity.** Prefer changing few features over many. A recommendation touching one behaviour is something a person can hold in their head and act on; a recommendation touching nine features simultaneously is a shrug. Sparsity is encouraged by penalising the *number* of changed features, not only their total size — a penalty on absolute deviations tends to leave most features exactly untouched while moving a few decisively. **4. Actionability.** This is the property the seller example turns on. Even a small, sparse, valid change is useless if it is outside the person's control or unreachable in a relevant timeframe. Late-shipment counts respond to how the seller runs the next few weeks. Lifetime order volume is an accumulated history; going from 60 to 460 is not an action, it is a wait. Ranking by geometry alone cannot see this difference, so actionability enters as an explicit input: each feature is annotated with whether it may change at all, in which direction, and at what cost. ## Immutable and directional constraints The hardest version of the actionability problem is features that must never be proposed. If age is in the feature set, an unconstrained search can happily return 'be twelve years younger', because the optimiser only sees a cheap distance in a numeric column. Nothing in the mathematics knows that age is not a lever. The same applies to features that can move only one way — age increases, a tenure counter increases, a completed qualification is not un-earned. The discipline is to **declare mutability before searching, not filter afterwards**. Every feature is classified up front: freely actionable, actionable in one direction only, or immutable. The search is then constrained to the actionable subspace, so an unusable suggestion is never generated in the first place. Filtering afterwards is worse in two ways: it wastes the search, and it quietly changes what is being optimised, because the nearest valid point in the full space may have no near neighbour in the actionable one — which is itself information worth surfacing. ## Offering more than one A single counterfactual forces one route on the user. Good practice is to return a small **diverse** set of valid, sparse counterfactuals that differ in which features they move, and let the person pick the one that fits their circumstances. Diversity is added as an explicit objective; otherwise the search returns several near-duplicates of the same change. ## The limit to state out loud A counterfactual is a statement about the model's decision boundary given a set of inputs: had these values been these instead, this scoring function would have output the other class. It is not, by itself, a promise about what happens in the world if the seller changes their behaviour — establishing that is a separate question with its own machinery. Saying this plainly is what separates a candidate who understands the method from one repeating a marketing line about actionable explanations.