"Explain This Decision"

Three People Ask, and They Want Different Things

The word explanation hides three separate demands. A supervisor asks whether the model was conceptually sound, properly validated and used as intended — a question about process and evidence, answered from documentation. A complaint handler or ombudsman asks whether this particular customer was treated fairly and what the firm relied on — a question about one case. The declined customer asks what it was about them, and what they could change. In US consumer credit the Equal Credit Opportunity Act and its implementing Regulation B require a creditor to give specific principal reasons for an adverse action. In the EU, data protection law restricts solely automated decisions with legal or similarly significant effects and gives rights to human intervention and to contest.

• The supervisor wants process and evidence: soundness, validation, use within intended purpose
• The complaint handler wants this case: what was relied on and whether treatment was fair
• In US consumer credit, adverse action requires specific principal reasons under ECOA and Regulation B
• The EU restriction bites on solely automated decisions, so inserting meaningful review changes which rules apply

Global and Case-Level Explanation Are Not Substitutes

A global explanation describes the model overall: which factors it uses, how it was developed, what alternatives were considered, whether relationships are constrained to move in a sensible direction, and how it performs across segments. That is what a validation file contains and what a supervisor examines. A case-level explanation says why this application, at this time, produced this outcome. Firms routinely offer one where the other is required. Handing a supervisor a per-case attribution chart answers nothing about conceptual soundness; handing a declined customer a statement of overall feature importance tells them nothing they can act on. Both must exist, they are produced by different work, and neither excuses the absence of the other.

• Global: factors used, development record, alternatives considered, constrained relationships, segment performance
• Case-level: why this application, at this moment, received this outcome
• A supervisor asking about soundness is not answered by a per-case attribution chart
• A declined customer is not answered by overall feature importance — build both deliberately

Attribution Is Not the Same as a Reason

Post-hoc attribution methods assign contribution scores to inputs for a given prediction, and they are genuinely useful for debugging. They are not reasons. They describe the arithmetic of the model, not the situation of the customer. They are also less stable than they look: different methods, different reference baselines and correlated inputs can each reorder which factors appear to dominate, and a firm should know how much its explanations move under those choices. A reason that will survive a complaint must be truthful about the decision actually made, specific enough for the person to act on, and consistent between runs. Where the explanation duty is strict, that argues for a more interpretable model rather than a more elaborate explainer.

• Attribution describes the model's arithmetic; a reason describes the customer's situation
• Different methods and baselines can reorder attributions — test how much yours move
• A usable reason is truthful, specific, actionable and stable across runs of the same case
• Where the duty is strict, an interpretable model often beats an elaborate post-hoc explainer

Try It Yourself

Explanations look adequate until someone tries to act on one. Take a decision your firm makes and write the two explanations out in full, then attack them.

Decision type:
Global explanation (one paragraph, no jargon):
Case-level reason 1:
Case-level reason 2:
Case-level reason 3:
What the customer could actually change:
Where the reason came from (model output, policy rule, or human override):
Would the same case produce the same three reasons tomorrow?