Ship the receipt with the result

Decide where the record lives, because that decision is yours, and the default is bad. In most products the account of a decision — if it exists at all — is born into a warehouse the user will never see, retrievable only by a support agent, only on request, only after the person knows enough to ask and has the patience to wait. The outcome reaches the user instantly, in the product, in plain words: declined, not eligible, under review. The reasons reach the user, if ever, through a different door, days later, in a different register. We have split the verdict from its grounds and shipped only the verdict. That is a product decision, and it is the wrong one.

The instinct that produces this split is understandable. The record feels like a back-office concern — something for auditors, regulators, the legal team — and the product surface feels like it should be clean, simple, uncluttered by justification. So the reasons get treated as exhaust, routed to storage, and the user is handed a result with nothing attached. But the person on the receiving end of an adverse decision does not experience the record as back-office. They experience its absence as a closed door. They were told no and not told why, in the one moment they were paying attention, and now they have to go hunting for grounds the system already had in hand.

So the directive: ship the receipt with the result. When the product delivers an outcome that matters to someone — a denial, a downgrade, a flag, a refusal — deliver alongside it a plain-language account of what the decision rested on, in the same surface, at the same moment. Not a link to a portal. Not a promise that an explanation is available on request. The receipt, present at the point of decision, readable by the person it is about. The system already computed the reasons; it had to, in order to decide. Withholding them from the affected party is not a saving. It is a choice to make the record serve everyone except the person it most concerns.

Two readers, and only one of them got served

Be clear about who the record is for, because a decision record has more than one reader and a product team usually builds for the wrong one. There is the auditor — the regulator, the reviewer, the technical witness — who needs the record exact, exhaustive, unforgiving. And there is the affected person — the one denied — who needs, first of all, to understand what happened to them, in terms they can act on. A record built only for the auditor is complete and unreadable: admissible in a proceeding the affected party can barely enter. You have probably built that one, because it satisfies the legal review and never has to face the user.

The affected person is not owed a simplified record — simplification that drops the load-bearing facts is a second injustice. They are owed a legible surface over the complete one: the plain account of what was decided and why, sitting on top of the exact record, each traceable to the other. That is a product surface, and building it is product work — interaction design, copy, the decision about what shows first and what sits one layer down. It is not the warehouse team's job and it will not happen on its own. If product does not own the readable face of the record, no one does, and the affected reader gets the auditor's record or nothing.

A record the user has to file a request to see is not a receipt. It is a verdict with the reasons kept in a back room.

And timing is itself a design decision, not an implementation detail. A record that arrives at the moment of the decision lands while the person still has the context to use it and the standing to act on it. A record that arrives weeks later, after an appeal window has quietly narrowed, after the user has moved on, is technically delivered and practically useless. The same bytes, sent at two different times, are two different products — one that equips the affected party to respond and one that runs out the clock. You are choosing between them every time you decide when the reasons surface. Choose the moment of the decision.

The receipt is a feature, so spec it like one

Stop treating the record as compliance overhead and start treating it as part of the thing you are shipping, because that reframing changes what gets built. Compliance overhead is something you do the minimum of, as late as possible, to satisfy a reviewer. A feature is something you spec, design, test against real users, and hold to a standard. The decision receipt deserves the second treatment. It has a reader, a job, a failure mode, and a measurable test of success — can the person it is about read it and know what they would push on if they wanted to push. Write that into the spec the way you would write any acceptance criterion, and the receipt stops being an afterthought and becomes a thing the team is accountable for.

This is not a heavier product. In most cases the reasons are already computed and already stored; the work is to route them to the surface, render them legibly, and present them when the outcome is presented. The cost is design attention, not new machinery. And the return is a product that does something most of its competitors do not: tells a person, at the moment it tells them no, what the no rested on — which is the difference between a system that affords contestation and one that merely permits it in theory, behind a door the user has to find on their own.

So when you scope the next decision your product makes, scope the receipt with it. Decide, on purpose, that the account of the decision is delivered to the affected party, at the moment of the decision, in their surface, in their language. Make it an acceptance criterion, not a follow-up ticket. The outcome was always going to ship. The only question is whether you ship the grounds with it — or hand someone a verdict and make them go looking for the reasons you already had.

— Dispatches · The Field Manual · Summit Cognitive