On a January morning, Elena opens the energy-support portal and sees the same sentence she saw three days earlier: “application not admissible.” It does not say which document is missing, which detail does not match, or who can look at the case. Her first impulse is to complete the form again. Her second is to call a general number. Neither step explains what happened. What changes the case is not learning computing or arguing with a machine; it is turning an opaque reply into a short record that another person can check.
That is the everyday meaning of a right to understand an automatic decision. It is not a demand for source code or a lesson in statistics. It is the ability to identify what was decided, what effect it has, what information can be corrected, which route accepts a review, and when the situation needs support. A useful explanation enables action; an explanation made only of labels shifts every burden onto the person who received the result.
Making the context clear#
**Start by taking a picture of the moment.** Before logging in again, save the full notice, date and time, website address or app name, case number, and concrete consequence. For Elena, the consequence was not “a portal error”; it was being unable to receive a reduction on a bill due the following week. That precision matters: appointment priority, a payment block, a job-screening result, and an enrolment refusal do not carry the same risk or deadline.
**Start by taking a picture of the moment.** Before logging in again, save the full notice, date and time, website address or app name, case number, and concrete consequence.
Also record what happened immediately before the answer. Was a document uploaded? Did an address change? Was a link from an email pressed? Did the screen close without confirming receipt? This sequence is not intended to prove a theory about the system. It separates observation from interpretation. “The portal showed not admissible after I uploaded the residence certificate” is an observation. “The algorithm discriminates against me” may be a legitimate concern, but it does not yet give a reviewer a concrete lead for finding the problem.
What changes in practice#
**Use a six-box case note, not an endless collection of screenshots.** The note can live on paper, in a protected note, or in an email to yourself. Include: decision received; impact; date and channel; data or documents involved; main question; next action and deadline. If several people are affected, do not combine their data. One note per case lets a mediator, service desk, or trusted person understand the situation without following a scattered conversation.
The main question should be answerable. Instead of “explain the algorithm,” Elena can ask: “Which specific requirement is recorded as unproven, and which document or correction can be reviewed?” Where the result affects an important application, she can add: “Was there human involvement, and what channel can I use to request a review before my bill falls due?” Asking this way does not weaken the request. It stops a reasonable question from disappearing into a standard reply.
Deciding with information#
**Look for signs that the process genuinely works.** The first sign is traceability: the organisation identifies the decision, case, or transaction and its date. The second is understandability: it explains in ordinary language which general condition was applied, what information is missing or seems wrong, and which part can be corrected. The third is a route to correction: there is a link, office, verifiable number, or procedure that does not require starting from nothing. The fourth is responsibility: someone is known to answer, even where an automatic system made the initial decision. The fifth is verification: once a correction is promised, there is a date or method for checking that it took effect.
Not every first screen must be perfect for a reasonable route to exist. Sometimes the initial notice is brief and the explanation arrives when requested. The warning sign is when channels contradict each other, nobody recognises the case, every answer tells the person to repeat the process, and the deadline keeps running. That combination deserves attention, especially when the outcome affects income, housing, health, education, work, identity, mobility, or an essential service.
Reviewing and adjusting#
**Separate a reversible annoyance from a significant decision.** A platform recommending an odd song or a spam filter archiving a message can usually be corrected with one gesture. An appointment dropped from a medical system, a withheld payment, an unexpected price increase, or an employment application never read may require human review. The difference is not whether technology is present. It is whether the person can correct the effect easily without losing an important opportunity.
When potential harm is low, try a limited check first: review the data, save the result, and use the official route. When impact is high or time is short, do not wait through several rounds of generic messages. Request a contextual review at once and seek support. A local social service, consumer office, trade union, patient group, digital-support point, or suitable professional can help organise the request. Seeking help does not turn a problem into a fight; it prevents one person from carrying a poorly explained procedure alone.
**Protect the evidence and protect your data too.** The need to document does not justify sending passwords, full document copies, or another person's data to any address. Keep what is needed in a dated folder. If you share the case with someone helping you, cover document numbers, access codes, and details that do not change the issue. Check domains and use contact details published on the official page, not a link that arrived unexpectedly. An alarming notice may be both a poor automation experience and an attempted fraud.
Elena's note contained one screenshot, the bill, the due date, and a copy of the certificate she sent. It held no passwords, full identity-document photos, or screenshots involving other people. That selection allowed a municipal office worker to see the likely error: the portal had read a renewal date as an issue date. Elena sent a short request, received a reference number, and asked for written confirmation that the case would be assessed again.
**Measure progress through facts, not promises.** After sending a review request, write down the reference number, route used, and expected response date. If someone says “it is being processed,” ask what action has started and how you can check it. If a data item is corrected, review the later screen or document. If a decision is reversed, keep both the original notice and the final confirmation. This is not automatic distrust. It is a way to distinguish a polite response from an effective solution.
Three checkpoints can help. The first, twenty-four hours later, confirms that the request arrived. The second, before the relevant deadline, checks that a responsible person or unit exists. The third, after the answer, verifies the practical effect: did the bill change, does the appointment appear, was the transaction released, did the case advance? If one of these points fails, the note already contains what is needed to explain why a second intervention is necessary.
**Do not let urgency erase judgment.** A message demanding immediate action may be real, but it should be possible to verify it outside the message itself. Before paying, sharing extra information, or using a link, enter through the official website or call a number you already know. If the situation affects an older person, a child, someone with a disability, or someone with limited digital access, offer supported reading and an alternative route. An organisation requiring an important action should also be able to explain how people receive help when they cannot solve everything on a screen.
**Turn the case into one concrete improvement.** When closing the file, write two lines: which sign made it understandable and which barrier delayed the solution. Elena noted that the reference number made follow-up possible and that “not admissible” did not identify what needed checking. If a library, shop, school, or association receives similar incidents, it can turn those notes into an improvement: add a human contact, test the form with varied people, explain required documents, or provide an in-person alternative.
The right to understand becomes real when it leaves a usable trail. The next time a screen delivers a meaningful result, do not try to solve everything at once. Preserve the fact, name the effect, ask a checkable question, use a safe channel, and confirm the outcome. If the impact is serious, the deadline is close, or nobody takes responsibility for review, seek help early. A system can automate a first response; it should not automate the loneliness of the person who needs to understand it.
