An automatic decision can enter ordinary life almost silently: a platform ranks applications, a system decides which notice to show first, or an app narrows the options it presents. The problem does not begin only when the outcome is unfavourable. It also begins when nobody can explain, in words that help someone act, what happened and how it can be reviewed. The right to understand does not ask every person to become a programming specialist. It asks that they can reconstruct a decision affecting their time, opportunities, or peace of mind.
Review often stalls because it starts with the wrong question: “Whose fault is this?” That question may matter where there is a specific responsibility, but by itself it does not organise a useful response. An automated decision involves data, rules, support staff, deadlines, and complaint channels. Seeking a clear explanation does not excuse harm or release an organisation from its duties. It helps distinguish the error that needs correction, the information that must be provided, and the next step that can be checked.
Change the scene of the review#
Imagine Clara in front of a public training website. She had applied for a place on a course whose schedule worked with her job. The screen says “not prioritised” and gives a short message: “result calculated according to scoring criteria.” Clara feels two familiar impulses: assume she did something wrong or upload the same documents five times. Neither gives her new information.
Imagine Clara in front of a public training website. She had applied for a place on a course whose schedule worked with her job.
Instead, she opens a note and builds a verifiable scene. She writes the date, transaction name, application number, exact phrase she saw, deadline shown on screen, and practical consequence: if she does not know which criterion was applied, she cannot decide whether to correct a record, accept the result, or ask for review. She does not yet write interpretations such as “the system punished me” or “nobody wants to help.” She writes what another person could check.
That small change matters. A vague complaint forces the recipient to guess what occurred. A short record makes it possible to locate the decision, answer a specific question, and keep a timeline if the case lasts. It also reduces the emotional burden of retelling the experience. The person does not lose the right to express impact; they can describe it more precisely: “this result leaves me unable to enrol in September” is more actionable than “this is unfair,” even though both statements may be true.
A four-column sheet#
For a blame-free review, a paper or digital sheet divided into four columns is enough. The first is facts. Put notices, dates, screenshots, reference numbers, and checkable records there. The second is impact: what was delayed, which access was blocked, which decision had to be postponed, or what worry the result caused. The third contains questions. The fourth records replies and commitments: who answered, what they said, what deadline they gave, and what remains to be checked.
This sheet is not a legal case file or a duty to document everything. It is a tool for orientation. Keep only necessary information and keep sensitive documents out of informal group chats. Where family, an association, or a support professional takes part, the affected person decides what is shared. Accompanying someone does not mean collecting their data so that their case becomes somebody else’s conversation.
An entry might read: “12 October; grant portal; rejected status; reference 8A-41; impact: cannot confirm accommodation; question: which data point or criterion excluded the application?; reply received 15 October, says a validation is missing; next step: request the source of that validation and the deadline for correcting it.” The strength of this note is that it separates what is known from what is still missing.
Ask without demanding the impossible#
Understanding an automatic decision does not mean demanding a tool’s source code or security secrets. A useful explanation can begin with much more practical questions. Which category of data was considered? Where did the record shown as incorrect come from? On what date was it updated? Was a general rule applied, or did a person review the case? Is there a channel for requesting human review or providing information that was missing?
It is also legitimate to ask that a technical answer be turned into plain language. If an organisation writes that “the weighting did not reach the model threshold,” a crucial part is still missing: what that means for the person, which requirements mattered, which could not be checked, and what route exists to challenge an inaccuracy. Asking for clarity is not hostility. It is a condition for being able to respond, correct, or choose an alternative.
Separate three things when reading an answer. An explanation describes what happened. A promise announces a future action. An assumption offers an interpretation that still needs checking. “Your file arrived after the closing time” can be an explanation if it includes the record that demonstrates it. “We will review it” is a promise and needs a date or owner. “The system may not have read the file” is a hypothesis. That distinction prevents a case from being closed with a reassuring but empty sentence.
Case: the appointment that changed without an understandable notice#
Rashid had an in-person appointment to renew a document. Two days before it, he received an automated notice moving the appointment three weeks later. The message did not say whether he had to provide anything or whether the change affected his temporary authorisation. His daughter wanted to post a complaint with the screenshot on social media. Rashid chose a different sequence: save the notice, call the channel listed in it, and put three questions in writing.
He asked whether the change came from a record in his file, a diary reorganisation, or an automatic priority rule. He asked which document confirmed that his authorisation would not lapse. And he asked whether there was a procedure for seeking an alternative date when a specific harm could be shown. The first call did not solve the case, but it produced an incident number. The second reply said there was a general reassignment of appointments, not an individual problem, and offered a documented-urgency route.
Repair did not consist of finding a person to blame for the calendar. It consisted of replacing uncertainty with a checkable explanation, preserving evidence of contact, and obtaining a proportionate way to act. When the new appointment arrived, Rashid checked that the document remained valid and closed his note with two lines: what had worked and which question he would ask first if something similar happened again.
Case: a recommendation that traps someone in an old profile#
Nora uses an app to look for work. For months, the system recommended only telephone-support roles because that had been her previous job. After she completed technical training, she still received the same suggestions and stopped trusting the platform. Useful review did not need to assign an intention to the system. It began by describing the pattern: across three weeks, twelve of fifteen offers shared the same kind of role even though her profile already included new skills.
Nora asked which profile sections influenced recommendations, whether she could edit preferences, whether there was a way to view offers without personalisation, and when changes would update. The company replied with a configuration guide and an estimated timeframe. Nora took one screenshot before changing her preferences and another a week later. The offers did not change completely, but a manual filter appeared along with an option to disable one category of behavioural data.
The lesson was concrete. She did not need to prove that the app “knew her wrongly” in a human sense. It was enough to show that a setting maintained a practical bias and ask for controls to change it. If the service had not offered an adequate response, Nora could have searched through other channels. Autonomy also means being able to leave a tool that does not permit reasonable review.
Case: the family that receives a school alert#
A school sent Leo’s family an automated alert: “risk of absenteeism.” The message reached both parents and an aunt listed as a contact, although she does not take part in school decisions. The family became worried because Leo had been absent while recovering medically and every absence was justified. Before arguing with the school, they agreed on one rule: screenshots would not circulate in the family group and Leo would decide which medical information was mentioned.
At the meeting, they asked which records triggered the alert, when justifications updated, and who could check that an absence was not being counted twice. The tutor explained that the platform generated notices before some documents synchronised. The school corrected the record and adjusted copies so that they were sent only to authorised contacts. It also committed to saying in future messages that an alert is an invitation to review, not a label attached to a student.
This was not only about correcting data. It was about preventing a provisional classification from becoming shared shame. A careful explanation protects the dignity of people who appear in a system, especially where they are minors or depend on others to respond.
Measure progress honestly#
A review can last days. To avoid mistaking motion for a solution, use a three-state scale: resolved, in progress, and no reply. Once a week, rather than every day, ask four questions: what changed since the last note, what proof confirms it, what remains unclear, and who can take the next step? This routine makes small but meaningful progress visible: receiving an acknowledgement, discovering a deadline, correcting an email address, or getting an appointment with the right person.
It also avoids absolute phrases that wear down people who are trying to help. “Nobody did anything” can become “an incident was opened on 18 October, but we still have no answer about the source record.” The second statement does not minimise the problem; it describes what is missing and makes an action possible. If no reply arrives, the record itself shows when to change channels, ask a competent organisation for help, or stop sending sensitive information unnecessarily.
A support worker may not have designed the tool. Recognising that does not mean accepting an inadequate reply. You can ask them to log the issue, explain the next process, confirm a deadline, or escalate it. Firmness should aim at a verifiable repair, not at unloading frustration onto the person with the least power to change the system.
Close only when the effect changes#
A case should not be treated as closed merely because an email arrives. The final question is: what changed in practice? It may be a corrected date, a repeated assessment, enabled access, an understandable explanation, or a human alternative. Ask for written confirmation where possible and check the effect after a reasonable period.
If the reply does not resolve the harm, the four-column sheet lets someone present the case without exaggerating or starting from scratch. Keep the reference number, explain the impact, and identify the open question. Depending on the situation, it may be appropriate to use the organisation’s complaint procedure, seek data-protection guidance, or ask for legal, social, or health support. Not every incident has the same route, and nobody should promise outcomes they do not control.
What can be practised is a reliable sequence: collect facts, name impact, ask questions, distinguish a reply from a promise, check the change, and choose the next step. That sequence does not make an automatic decision perfect. It does something more valuable: it prevents opacity from turning into blame and gives the person real room to understand, repair, and choose.
A commitment for next time#
When a result appears that you do not understand, try one small commitment: “today I will save the notice and write one specific question.” You do not need to solve the whole algorithm. It may be enough to find out which record was used, who can review it, or when a reply will arrive. If you need accompaniment, ask for help ordering the facts, not for somebody else to speak for you without consent.
The right to understand is exercised through modest, repeatable gestures. A carefully saved screenshot, a noted deadline, an answer translated into plain language, and a checked correction build a practice of autonomy. Reviewing without blame does not mean giving up the demand for improvement. It means making that demand from a base that protects data, reduces shame, and leaves a better path for the next person.
