Explaining an AI Decision to the Person It Affected

1. The reason code and its human-readable text

The person asks "why." The record holds a code such as RULE_INC_04. The code map holds the sentence. The sentence is the deliverable, and it must name the fact that decided the outcome, not the rule that detected it. "Income verification could not be completed within 30 days" beats "RULE_INC_04" and also beats "insufficient documentation," which is the kind of sample-form phrase that hides the real reason.

Reason codes drift. A code map that is not versioned alongside the model can end up printing a meaning the model never scored, which is exactly the failure described in this worked lending example, where one model version redefined a code and letters went out with the wrong reason until someone noticed. The fix is structural: store the code map identifier in the decision record at decision time, not the map that happens to be live when someone asks.

2. The named reviewer and their role

The person asks "who decided." If a human reviewed or signed off, the record should name them, their role and the date and time of the review. If the decision was fully automated, the record should say that plainly and name the accountable function instead of inventing a person.

This is the difference between nominal and genuine oversight. A reviewer who lacks the information, authority or time to change the outcome does not satisfy meaningful human review requirements, and the evidentiary basis is an audit trail showing who authorized what, when and under which policy per this compliance analysis. Human in the loop means a human must review, approve or act before the workflow proceeds, and the reviewer's approval is an event in the log, not an edit to it per this HITL and HOTL comparison. A named person with a timestamp is also the single most calming sentence you can put in a letter.

3. The versioned policy or model that set the threshold

The person asks "why that line and not another." The record answers with an identifier and version, for example renewal-policy-v4 or a named model release. Version identifiers are what let you explain a historical decision honestly later, when the threshold has moved as this decision-logging guide notes.

Without the version, two things break. First, you cannot reproduce the decision, so your answer to a regulator and your answer to the customer may diverge. Second, you cannot tell whether the decision would still hold under today's policy, which is often the customer's actual question. Keeping the version identifier in the record costs almost nothing and converts a fragile answer into a stable one.

4. The appeal path and its deadline

The person asks "what can I do about it." Give the channel, the person or team that handles it, what the person should send, and the date by which they will hear back. If a statutory clock applies, give it in plain words. Adverse action notices carry a 30-day window from a completed application, and the clock runs while the file sits in review per this overview.

Two details make appeals real rather than decorative. The appeal must be able to change the outcome, and the person reviewing it must not be the person who made the original call where volume allows. Both of those need to be true in the workflow before you promise them in a letter.

A common mistake is to write one paragraph that paraphrases the record. The recipient cannot check a paraphrase. Translate field by field and keep the code visible in a reference line, so that a support agent, a regulator or the customer's own adviser can join the letter to the record.

A pattern that works:

Decision reference: D-4417
What we decided: we could not verify your income within 30 days of your application.
Why: our rule set at the time (income-verification policy, version 4) requires
verification within 30 days. Your application reached day 31 without the two
documents we requested on 3 and 11 June.
Who reviewed it: A. Okafor, underwriting team lead, reviewed this decision on 14 June.
What you can do: reply to this message or call the number below before 12 July.
Send the two documents and we will recheck the decision. A different reviewer
will look at it and you will hear back within 10 business days.

Every sentence in that block is checkable against one field. None of it speculates about intent, and none of it hides behind passive voice.

Two rules keep the translation honest. First, describe the fact, not the score. "Your oldest account is 11 months old, below the 24 months our policy requires" tells someone what to do next; "low creditworthiness" does not. Second, do not quote model internals. Reason codes are designed to be safe to expose; raw feature weights and prompt text are not, and storing them creates a second copy of sensitive data with its own retention obligations per this logging guidance.

For teams producing these at volume, the reason map is worth treating as product, not configuration. A mislabelled reason is a wrong explanation to a real person, and it repeats at the speed of your batch job.

Records have gaps. The reviewer field is empty because the workflow skipped the step. The policy version was not written because the field was added later. The code map changed and the original sentence is gone. The temptation is to reconstruct a tidy story. Do not.

The rule: state what the record contains, state what it does not contain, and state what you will do and by when. "Our record shows the decision was made by the automated rules engine on 14 June. It does not show that a person reviewed it before it was issued. That is a gap in our process, and I have asked our team to confirm whether a review happened and to come back to you by 21 June." That answer is uncomfortable and it is defensible. The invented version is comfortable and it collapses the first time anyone audits it.

Gaps also tell you where to invest. Missing reviewer identity usually means the approval step was optional in the workflow, not that the reviewer forgot. Missing policy version usually means the decision service read the live policy instead of snapshotting it. Both are schema fixes, and both are cheaper than the correspondence they generate.

Three practical moves:

• Make the four fields required at write time. A decision that cannot produce them should not be allowed to send a customer-facing outcome.
• Link, do not copy. Store references to evidence such as the documents received and the verification attempt, with access controls and retention that already apply to those systems per this decision-log schema discussion.
• Check that review is real. If the reviewer screen shows only a summary and an approve button, the review is theater, and the letter will overclaim.

Retention deserves a decision rather than a default. No AI-specific rule fixes a period for these records, so organizations derive it from sector rules; PCI DSS, for instance, requires at least 12 months of audit log retention with three months immediately available, and privacy law may extend it where personal data is involved per this retention summary. Pick the longest applicable clock and write it down, because the person asking about a decision two years later is often the one with the strongest reason to ask.

The best time to solve this is schema design. Store the outcome, the reason codes with their map version, the reviewer identity and role with an event timestamp, the policy or release manifest identifier, and an appeal case reference. The record should be reproducible without the full prompt or the full customer file, which means stable references and versioned identifiers rather than a giant JSON blob per this agent decision record pattern.

If you are running agents rather than a rules engine, the same fields map onto agent identity, the authorizing principal, an action classification and an outcome, with tamper-evident chaining so a record cannot be quietly edited after the fact per this draft audit-trail format. You do not need the full format to answer a customer, but the authorizing principal field is the one that lets you name a person when the model acted on its own.

One more design note, because it is where teams get surprised. If your model is accessed through a single gateway, log the request at the gateway with the decision reference attached. That gives you one place where code version, model identifier and policy version meet, which is usually cheaper than retrofitting four fields into six downstream services. A gateway that speaks one interface for every model type, such as Quanta Inference, makes that correlation straightforward because the model identifier is already part of the request.

• Does the reason sentence name a fact the person could act on, and is the code map version recorded with the decision?
• Is the reviewer's name, role and review time in the letter, or an explicit statement that no review occurred?
• Does the policy identifier match the version in force at decision time, not today's version?
• Is the appeal channel real, with a named handler, a stated deadline and a recorded way to overturn?
• If a field is missing, does the letter say so and give a date for the follow-up?

If your team handles these questions by hand across several products, or the review step exists but nobody can show where it is recorded, a short working session on the decision record and the response template usually pays for itself. Quanta Consulting runs a free 30-minute discovery call where you can bring one real decision record and map it against these four fields.