Explanations for affected individuals

What it does

It gives the person affected what they need to understand and contest a decision. For each decision of consequence, the organisation can state in plain language the outcome, the principal factors that led to it for this person, the information about them that was used, and the route to have it looked at again. The explanation is offered with the decision or on request. The business owner of the decision is accountable; operations deliver it and compliance sets the standard. It is designed in and operates whenever such a decision is communicated.

How to implement it

• Decide which decisions require an explanation, starting with those the law covers.
• Design the system to record the main reasons for each decision at the time it is made.
• Write explanations for the reader: specific to the case, free of jargon, and honest about uncertainty.
• Tell the person what data was used and where it came from.
• Give front-line staff access to the reasons and training to explain them.
• Test explanations with members of the affected group.

Evidence it operates

Design: an explanation standard; reason capture in the decision record. Operation: sampled decision notices with case-specific reasons; logs of explanation requests and responses; staff training records; user testing of the wording.

Where it fits

At the point a decision is communicated, drawing on design choices made earlier. It is the primary control for inadequate explainability for affected individuals, and supports automated decision-making without safeguards and inadequate contestability and redress. It depends on explanation method validation for reasons that are true.

Limits

An explanation is only as faithful as the method that produced it. For complex models the main reasons are an approximation. Detailed reasons can help people game a system, which creates pressure to say less. A clear explanation of an unfair decision does not make it fair.