the system should explain the refusal.
automated systems say no every day.
a payment is blocked. an account is suspended. a claim is rejected. access disappears behind a message that says the request could not be completed.
the system has made a consequential decision without giving the person a usable reason.
security and fraud prevention require limits on disclosure. that does not justify meaningless language.
an explanation should tell the person what category of issue occurred, which information can be corrected, whether the decision can be reviewed, and how long the next step should take.
“policy violation” is not enough when the policy is invisible.
design the refusal before launch. list the reasons the system may deny an action. decide which can be shown directly, which require a protected explanation, and which demand human review because the evidence is uncertain.
appeals are part of the product.
people need a channel that can change the result, not a form that sends the same inputs back into the same logic. the reviewer should see the original reason, relevant evidence, and any context the automated process could not accept.
track reversals. a high reversal rate may reveal poor thresholds, missing data, or a group that the system misunderstands. complaints are not merely support volume. they are evidence about decision quality.
measure how long correction takes and how many times the person must repeat the same facts. an appeal that eventually succeeds can still impose unreasonable harm.
publish the common pathways in plain language so people can prepare the evidence that matters.
a refusal creates friction by definition. clarity prevents that friction from becoming helplessness.
systems earn trust when limits are understandable, correction is possible, and responsibility remains reachable.
