Write the reason for the person

Treat the reason you hand the affected party as a first-class product surface, and write it for them — because right now you almost certainly are not. Somewhere in your system a decision resolves, and a string comes back with it. Maybe it reads your application did not meet our criteria. Maybe it reads declined: policy 4.2, feature score below threshold. Either way, the person on the other end learns nothing they can act on. You did not write that string for them. You wrote it for the audit log, or you did not write it at all — you let the backend hand up whatever it had, and shipped it to a human being as though it were an explanation. It is not. It is a byproduct wearing an explanation's clothes.

Systems that produce any account of themselves tend to produce one of two useless kinds. The first is the compliance sentence: your request did not satisfy the applicable requirements. It is true. It is complete, in the sense that a lawyer signed off on it. And it is empty — it restates the outcome as though the restatement were a cause. The person already knew they were declined; what the sentence adds is the faint insult of being told so twice. The second is the technical dump: a policy code, a list of feature weights, a model version, a decision path. It is accurate to a fault. And it is unreadable — a printout of the machine's internals handed to someone who has no map of the machine. Neither of these was written for the person who has to do something next. One is written for the record; the other is the record, misdelivered.

You shipped the auditor's sentence

The tell is that both failures come from the same place: nobody wrote for the reader. The compliance sentence is written to survive review — it says as little as possible so that nothing in it can be held against you later, and its emptiness is the feature, not the bug. The technical dump is written by omission — it is whatever the decision process left lying around, surfaced without translation because translation was never anyone's job. In both cases the human on the receiving end was not modeled. They were routed a value. And a value routed to a person is not an explanation you gave them; it is one that happened near them.

This matters because the reason is often the only thing the person actually receives. The outcome they could have guessed — they applied, they were told no. The reason is the part that was supposed to do work: to let them understand what happened, decide whether it was right, and figure out what, if anything, to do now. When the reason is empty or unreadable, the decision arrives sealed. The person has been acted upon and handed a note that explains nothing, and every downstream thing they might do — fix the problem, gather a missing document, dispute an error — is foreclosed not by the decision but by the failure to explain it in terms they can use.

What a reason for the person answers

A reason written for the affected party answers the three questions they actually have, in the order they have them. First: what specifically drove this? Not the policy number — the substance. The particular fact, condition, or shortfall that moved the outcome, named plainly enough that the person can recognize it as being about them. Second: what, if anything, can I do about it? Some adverse decisions are fixable — a missing verification, an income threshold, a gap that closes with time — and some are not, and the honest reason says which. A person who can act deserves to know the lever; a person who cannot deserves to be spared the false hope of hunting for one. Third: how do I contest this if it is wrong? Decisions rest on facts, and facts can be mistaken. A reason that names its basis but hides the route to challenge it has told the person where the wound is and pocketed the bandage.

Notice that answering these three is a distinct act from producing the record. The record — the full account of what the decision rested on — is what makes a faithful reason possible; you cannot write honestly for the person if the system did not retain what it actually did. But the record is not itself the reason for the person. The reason is a separate rendering of it: the same underlying facts, shaped for a specific reader with a specific set of questions and a specific amount of context. This is a design and engineering job. It is the deliberate construction of a human-facing surface over the decision record — and like any surface, it can be built well or badly, and it will be built badly by default if no one owns it.

A reason the person cannot understand or act on is not an explanation you gave them; it is one you filed near them.

Build and test it like a real surface

So build it like one. The affected-party explanation has a reader, a job, and a failure mode, which means it can be designed, drafted, and tested the way you would test any surface that matters. Put a real version of it in front of real people — ideally people like the ones who will receive it — and check the two things that count: did they understand what drove the decision, and did they come away knowing what they could do next. Comprehension and actionability are measurable. If a representative reader reads your reason and cannot say, in their own words, what happened and what their options are, the surface has failed its acceptance test, and the fact that the sentence was technically accurate does not rescue it. Accuracy is the floor. Legibility to the intended reader is the standard.

There is a real tension here, and it has to be handled honestly, because the failure mode of legibility is the comforting lie. In the rush to make a reason readable, it is easy to make it false — to invent a clean individual story where the truth is messier, or to soften a basis until it no longer describes the decision that was actually made. The discipline is that the reason for the person must be a faithful rendering of the real basis: simplified, but not falsified. You drop the machine's internal notation; you do not drop the load-bearing fact. And where the true reason is genuinely a group-statistical pattern — where the decision rested not on a specific thing the person did but on how people with certain attributes tend to behave — the honest move is to say so, plainly, rather than manufacture an individual narrative that was never the real cause. A person told the truth about a statistical basis can at least contest the statistics, or the fit. A person handed a fabricated personal story has been lied to legibly, which is worse than being confused honestly.

This is where the surface stops being an afterthought and becomes an account. An explanation the person cannot act on is a courtesy, not an account — it acknowledges them without equipping them. The record is what makes the reason possible; writing it for the person is what makes it useful. Both halves are required, and the second one is the one your system is dropping, because the second one is product work and product work does not happen unless someone is made responsible for it. So make someone responsible. Spec the affected-party reason. Draft it for the reader, not the reviewer. Test it for comprehension and actionability against real people. And hold it to the standard that it must be true — simplified where it can be, honest where it cannot, and never a story invented to make the person feel explained-to when they have not been.

— Dispatches · Summit Cognitive