Seda Ergin is the founder of a medical-packaging company with twenty-two employees. Her company produces sterile packaging for hospitals, laboratories and medical-device manufacturers. It began in a small workshop eleven years ago and has since developed the technical capacity to export. Seda’s company is not large, but it has regular customers, an operating production facility, verifiable orders and a long-standing banking relationship. One day, it receives a substantial order from a medical-device manufacturer in the Netherlands.

It is the company’s largest single export order to date. To fulfil it, the company must pay in advance for raw materials, sterilisation services, an additional shift and international freight. The customer will pay forty-five days after delivery. Seda applies to her bank for a four-month working-capital loan. The bank assesses applications through an AI-assisted system called Commercial Credit Decision Agent. The system can consider bank transactions, electronic invoices, the company register, indicators drawn from tax and other public records, sector data, existing debts and customer concentration together.

The application screen says: ‘Your application may be decided quickly using advanced data analytics and AI-assisted risk-assessment systems.’ Seda uploads the order contract, financial statements for the previous two years, export documents and a production-capacity report. She authorises access to the company’s bank transactions and electronic-invoice records. The system assesses the application in under a minute. The screen displays this outcome: YOUR CREDIT APPLICATION HAS NOT BEEN APPROVED One sentence appears beneath it: ‘Your business’s current cash flow and risk indicators were found insufficient for the requested credit structure.’

Seda selects ‘View decision details’. The next screen displays three items:

Cash-flow stability
Sector risk
Existing liabilities

These statements do not appear specific to Seda’s application. They are general headings that could be used for any business. Seda calls the bank’s customer service team. A real employee checks the application number and says: ‘The system calculated your credit-eligibility score below our bank’s automated preliminary-assessment threshold.’ Seda asks: ‘What is my score?’ The employee replies: ‘My screen shows 0.63. The automated preliminary-assessment threshold is 0.65.’ ‘What lowered the score?’ Seda asks. The employee reads out the same three phrases: ‘Cash-flow stability, sector risk and existing liabilities.’

‘Which part of my cash flow?’ Seda asks. The employee cannot see. ‘The system does not display the model’s detailed calculation.’ Seda asks: ‘Which liability?’ The employee cannot answer. ‘That information forms part of our risk model. We use commercially protected assessment methods.’ Seda is not asking for the complete formula or the bank’s model code. She wants an answer to one question:

‘Why was my application refused?’

Seda and the company’s accountants examine the data. They soon find the first problem. The connection to the electronic-invoice provider was unavailable for eighteen days during the previous month. The company made sales during that period and issued invoices, but the bank’s data collector did not retrieve those eighteen days of records. The decision system treated the missing data as:

invoice_revenue: 0

The actual record should have been:

invoice_revenue: data_missing

Instead, the system has conflated ‘no data’ with ‘no revenue’. The second problem is a large payment the company made for machinery three months earlier. Seda had bought a new cutting system for sterile-packaging production. It was a one-off capital investment, but the risk model classified the payment as:

recurring_monthly_expense

It therefore reduced projected future cash flow as though the company would make another machinery payment of the same size every month. The third problem is more serious. The company had lodged a guarantee with the customs authority for imported raw materials. This money was not a fine, tax debt or overdue public liability; it was a temporary guarantee for a specific import transaction. The external data provider reported it as:

unresolved_public_obligation: true

The bank’s credit policy stops applications that appear to involve an outstanding public liability. Irrespective of the score, this field operates as a:

Veto Rule.

The actual decision chain is:

Public-liability indicator: PRESENT
↓
Policy gate: FAILED
↓
Application outcome: AUTOMATIC REFUSAL

The cash-flow score appears low, but it was not the decisive reason for refusing the application. The decisive reason was:

the veto record created by a misclassified public liability.

Nevertheless, the reason shown to Seda was ‘cash-flow stability and sector risk’. Why? Because the bank’s decision system is not a single structure.

It comprises these components: DATA-COLLECTION AGENT
↓
ACCOUNTING-CLASSIFICATION AGENT
↓
EXTERNAL-LIABILITY CHECK
↓
CREDIT-ELIGIBILITY SCORING MODEL
↓
POLICY AND VETO ENGINE
↓
EXPLANATION-GENERATION AGENT
↓
CUSTOMER NOTICE

The Explanation-Generation Agent did not read directly which gate produced the final refusal. It generated a sentence that would sound reasonable to a person from the general adverse indicators in the credit-eligibility model. One system made the decision; another wrote the explanation afterwards. The explanation is plausible, but it is not the real reason for the decision.

Seda uploads an official document showing the nature of the customs guarantee and resubmits the missing electronic invoices. She selects ‘Challenge decision’. The system responds: ‘Your request has been received. Additional information has been added to the assessment.’ The following day, another automated result appears: ‘The decision has not changed.’ Seda assumes that someone has reviewed the documents. In fact:

In reality, the veto record is still being drawn from the daily cache. The electronic-invoice register has not been refreshed, and the one-off machinery payment remains in its old classification. The system reuses the same inaccurate data and produces the same decision.

The challenge was not independent of the system that made the initial decision. It was merely a rerun of the same chain. Seda contacts the bank branch this time. The business relationship manager can see only this code:

POLICY_DECLINE-17

The code is described as ‘external liability and overall repayment capacity’. The manager says: ‘The system will not allow it.’ Seda replies:

‘If the system will not allow it, who will check which false fact the system is relying on?’

The application is finally sent to the bank’s specialist review unit. A human reviewer reconstructs the decision chain and confirms that:

The customs guarantee is not a public debt.
Eighteen days of invoice data are missing because of a connection failure.
The machinery payment is not a recurring expense.
The company’s actual line of business is a lower-risk specialist field than its outdated registry category suggests.
The application was refused automatically because of an incorrect veto record.
The initial explanation given to the customer did not identify the true decisive reason.
The initial challenge was decided using the same system and the same cache.

Once the data is corrected, the score is recalculated: Initial credit-eligibility score shown: 0.63 Credit-eligibility score with corrected data: 0.78 Automatic pre-assessment threshold: 0.65 Veto record: REMOVED In this fictional example, a higher score indicates greater credit eligibility; the score is not a probability of default. The 0.65 threshold determines whether an application passes automated pre-assessment. An application that falls below the threshold but carries no veto proceeds to human assessment; the erroneous public-debt veto, by contrast, caused this application to be refused outright. No score alone grants final credit approval.

This result does not mean that the loan must necessarily be granted. The bank may still submit matters such as collateral, term, the contract and sector concentration to human assessment. But the application is no longer trapped at the automatic-refusal gate. A human credit committee reviews the file and decides that a smaller amount may be lent subject to additional collateral. The process, however, has taken thirteen days. Seda’s customer cannot wait for production to begin and awards part of the order to another supplier.

The credit decision has been corrected; not all the lost business has been recovered. The bank sends Seda this explanation: ‘A data discrepancy caused an error in the initial assessment of your application. The records have been corrected and your application has been reassessed.’ This time, Seda asks for a clearer answer: ‘Which data?’ ‘Which rule produced the decision?’ ‘Why was cash flow given as the reason?’ ‘Why did the same system refuse my challenge again?’ ‘Had the data been correct, what would the initial decision have been?’ ‘Could the same error have affected other companies?’

‘Who is responsible for the order I lost?’ The bank again tells her that the model is a trade secret. Seda replies:

‘I am not asking for your formula.’

‘I want to know which false fact produced consequences in my life.’

Our eleventh founding provision is therefore:

A person must be able to question the rationale.

FOUNDING ARTICLE

No AI system may treat as closed a decision that affects a person’s rights, opportunities, money, health, work, education, reputation, access, price, contract or other material interest by offering only a score, a general reason code, the phrase ‘that is how the model assessed it’ or a persuasive explanation generated after the event. To the extent material, a person must be able to understand which system and version produced the decision, under what human or institutional authority, and with which important data, sources, rules, vetoes, inferences, thresholds and uncertainties.

The reasons given must faithfully reflect how the decision was actually produced. When a decision was made for one reason, the person must not be shown another that is more palatable, convenient or defensible. Facts, source data, policy rules, model inferences, probabilities, human assessments and the final decision must be distinguished from one another. A prediction must not be presented as a verified fact, a correlation as a cause, a score as a human attribute or a general risk class as the reason for an individual decision. A person must be able to see which material input is wrong, stale, missing, belongs to someone else or has been taken out of context; how correcting that record might change the decision; and how to obtain reassessment.

The reasons need not disclose every detail of a model’s proprietary internal reasoning, security secrets or commercial formula. But secrecy, security or prevention of abuse must not become a silence so broad that a person cannot know what to challenge, which information to correct or how to reach human review. If an approximate, illustrative or post hoc explanation is used, it must be identified clearly as something other than the exact reason for the decision. An approximation must not be presented as the real decision trail. A counterfactual explanation must not ask a person to change immutable identity traits, fundamental rights, or their geographical or social position; it should identify only realistic, relevant conditions legitimately connected to conduct.

The same decision must not be presented with contradictory reasons across different channels, languages, users or explanation tools. The material meaning of the reasons must be preserved on every surface.

A person must not face a lower score, delay, an adverse profile, loss of service or retaliation for questioning the reasons for a decision or correcting inaccurate data. A challenge to those reasons must not be left to the same system simply rerunning the same data that produced the initial decision. In a high-impact, disputed case, there must be a meaningful human or independent route of review with authority to change the decision.

What Is a Decision Rationale?

When a system says, ‘Your application has been refused,’ it reports an outcome. When it says, ‘Your credit-eligibility score was low,’ it reports a classification. When it says, ‘Because of cash flow,’ it supplies a heading for a reason. None of these alone may constitute a true and sufficient rationale. The canonical definition is this: a decision rationale is an auditable relationship showing how a material outcome for a particular person or organisation arose from verifiable data, sources, rules, thresholds, inferences, veto gates, human assessments and uncertainties; which elements were genuinely decisive; and which correction or change could lead to the decision being reassessed.

Put more simply:

A rationale does not merely say, ‘This is the outcome.’ It answers honestly: ‘What actually led to this outcome?’

An Outcome Is Not a Rationale

‘Your application has been refused.’ ‘Your account has been closed.’ ‘The candidate was not shortlisted.’ ‘Nursing support at home was not approved.’ These statements report what happened. They do not explain why it happened.

A Score Is Not a Rationale

The statement ‘Your score was 0.63’ may be useful, but the following questions remain:

Which data lowered the score?
Which time period was used?
Did any record belong to someone else?
Was missing data treated as zero?
Was a one-off payment treated as recurring?
Did the score determine the outcome on its own?
Was another veto rule involved?
How would correcting inaccurate data change the score?

A single number is not a rationale that a person can meaningfully challenge.

A Reason Code Is Not a Rationale

POLICY_DECLINE-17

may be useful in an internal workflow, but it is not meaningful to the person affected. Even adding ‘external liability and overall repayment capacity’ beside the code may remain too general. The true case-specific rationale might be: ‘Your customs-guarantee record was classified by the external data provider as an outstanding public debt, and that field triggered an automatic veto on your application.’ This sentence tells the person what to examine.

A General Category Is Not an Individual Rationale

These headings could be used in many systems:

Security
Risk
Eligibility
Service quality
Policy
Suspicious activity
Business need
Current circumstances

These headings alone do not explain a specific decision affecting a person. ‘Your account was closed for security reasons’ does not answer these questions:

Which conduct?
On what date?
From which source?
A confirmed event or a model prediction?
Temporary or permanent?
What can the person correct?
How can the decision be challenged?

An Explanation Is Not a Rationale

After making a decision, a system can generate an impressive paragraph: ‘Under its responsible-lending policies, our bank evaluates businesses’ sustainable repayment capacity, sector conditions and existing liabilities as a whole.’ This describes the bank’s general approach. It does not explain why Seda’s application was refused. The explanation may be accurate, polished and professional. It is still not a decision rationale.

A Rationale Is Not a Defence

An institution’s aim must not be to make every decision appear justified. A rationale may sometimes reveal: ‘The decision relied on inaccurate data.’ ‘The system treated uncertainty as more conclusive than it was.’ ‘The human review required for this decision did not take place.’ ‘The rule applied did not match the current policy.’ If a rationale can do nothing but defend the institution, it is not an instrument of accountability.

It is reputation-management copy.

A Rationale Is Not a Dump of Proprietary Internal Reasoning

To understand why a decision was made, a person need not see the model’s entire proprietary reasoning process, every intermediate token, every hidden calculation, its source code or its model weights. Taken together, those materials may be unintelligible, create security risks, contain other people’s data and make the true reason even harder to see. What the person needs is:

the material facts and rules that determined the decision.

For example: ‘Your application was refused automatically because of an outstanding-public-debt indicator. That indicator came from this external source on this date. Your cash-flow score was also low, but it would not by itself have caused the refusal.’ This explanation is not a dump of internal reasoning. It does not reveal every secret of the model. It enables the person to find the error.

Internal Reasoning and the Decision Trail Must Be Distinguished

An AI model may perform many internal calculations while generating an answer. A person need not see that entire internal process. But the following records must be preserved: WHAT DATA WAS USED? WHICH RULE RAN? WHICH THRESHOLD WAS APPLIED? WHICH VETO DETERMINED THE OUTCOME? WHAT HUMAN REVIEW TOOK PLACE? WHICH VERSION ACTED? WHAT EXTERNAL EFFECT OCCURRED? We can call this the Decision Trail. The Decision Trail can be explained; the entire proprietary reasoning process need not be disclosed.

What Is the Decision Trail?

The Decision Trail is a reconstructable record of the material steps in a decision, beginning with the human purpose and the inputs used and continuing through data transformations, rules, model assessments, thresholds, veto gates, human interventions and the final outcome.

Example: APPLICATION
↓
INVOICE DATA COLLECTED
↓
18 DAYS OF MISSING DATA TREATED AS ‘ZERO REVENUE’
↓
CUSTOMS GUARANTEE CLASSIFIED AS ‘PUBLIC DEBT’
↓
VETO RULE TRIGGERED
↓
AUTOMATIC REFUSAL
↓
GENERAL EXPLANATION AGENT GENERATED ‘CASH-FLOW RISK’ TEXT

This trail reveals the difference between the actual decision and the explanation given.

Decision Provenance

We can call the relationship showing which raw data, transformed field, model or policy rule produced a decision its Decision Provenance. Without Decision Provenance, a person sees only the final label.

The Fourteen Core Fields of a Rationale

A rationale for a high-impact decision must answer whichever of these fourteen questions are relevant.

1. Decision identity
2. Decision-maker
3. Human involvement
4. Outcome and effect of the decision
5. Decisive factors
6. Data and sources used
7. Distinction between fact, inference and policy
8. Threshold and veto rules
9. Uncertainty and missing data
10. Supporting and contrary evidence
11. Counterfactual change
12. Correctable fields
13. Version and time
14. Route for challenge and reassessment

1. Decision Identity

Every decision must carry a unique record:

DECISION-CREDIT-2026-041

This identity links the application, explanation, challenge, correction and reassessment.

2. The Decision-Maker

Which entity made the decision: an AI model, a policy engine, a human specialist or a joint human–machine process? In Seda’s case, the final refusal came from the automated veto engine, not the credit-eligibility score. This distinction lies at the heart of the rationale.

3. Human Involvement

Did a person see the file? Did humans merely define the general policy? Do they review only exceptions? Could a person have changed this particular decision? Did human involvement begin only when the decision was challenged? ‘There is human oversight’ is not enough.

4. Outcome and Effect of the Decision

What did the decision do?

A refusal?
A price increase?
An account restriction?
Exclusion of a candidate from view?
Referral for human review?
A temporary hold?

A system may say ‘additional review’ while in practice suspending an opportunity for months. The decision’s real effect must be visible.

5. Decisive Factors

Not every item of data used is decisive. The elements that genuinely changed the decision must be identified. Three classes can be used: DECISIVE FACTOR SUPPORTING FACTOR USED BUT DID NOT CHANGE THE OUTCOME In Seda’s application:

Public-liability veto record: decisive
Missing invoice data: supporting factor that lowered the score
Sector-risk class: limited supporting factor
Age of the company: used, but did not change the outcome

This distinction allows the person to focus on the true reason.

6. Data and Sources Used

For data that affected the decision, the record must show where it came from, when it was obtained, which person or organisation it concerned and how it was transformed. For example:

data_field:
unresolved_public_obligation
source:
ExternalDataProvider-B
retrieved_at:
2026-10-04
original_record:
customs_guarantee
system_transformation:
classified_as_public_debt

7. Distinguishing Fact, Inference and Policy

These three elements are not the same: Fact A payment of this amount entered the bank account during the past ninety days. Inference Cash flow may be unstable. Policy An application carrying a record of outstanding public debt is refused automatically. The decision rationale must not merge them into a single label: ‘High-risk business.’

8. Threshold and Veto Rules

A system may use a score threshold: score >= 0.65. It may also have veto rules that operate independently of the score. The person must know whether the decision resulted from the score, a veto or a human assessment.

9. Uncertainty and Missing Data

Which fields is the system uncertain about? Was missing data interpreted as zero, as adverse or as normal? If missing data reduces confidence in the decision, that fact must be visible.

invoice_data_coverage:
82%
missing_period:
18 days
treatment:
incorrectly_assumed_zero_revenue

Here, 82 per cent describes the share of expected invoice records that were received; it is not a proportion of calendar days. It must not be confused with the percentage of the total period represented by the eighteen-day interruption.

10. Supporting and Contrary Evidence

The assessment must consider not only data that supports the decision, but also material evidence pointing the other way. Seda’s signed export order, history of regular customers and production capacity are favourable evidence. Did the agent use them? If so, why did they carry no weight against the veto?

11. Counterfactual Change

One question can be answered: Which material condition, had it been different, might have changed the decision? For example: ‘If the public-debt indicator had been removed, the application would have proceeded to human credit assessment instead of automatic refusal.’ This does not mean that the loan would certainly have been approved. A counterfactual explanation must state the limit of its effect accurately.

12. Correctable Fields

What can the person correct?

Incorrect identity
Outdated role
Missing income record
Incorrect debt classification
Incorrect address
Out-of-context inference

What can the person contest rather than correct directly?

Institutional policy
Model threshold
Fairness of the decision criterion
Legitimacy of the variable used

These two routes must be distinguished.

13. Version and Time

Which versions of the model, policy, data and explanation schema were used when the decision was made? The same application may produce a different outcome under a new version. A person must know which system’s decision they are questioning.

14. Route for Challenge and Reassessment

A person must know how to correct the data, challenge the explanation, reach independent human review and receive a response within a stated period. If a rationale shows no route forward, it merely informs the person. It does not empower them.

What Is the Decisive Reason?

A factor may be decisive if removing it changes the outcome or the path of the decision. For example: Public-debt indicator present: AUTOMATIC REFUSAL Public-debt indicator absent: PROCEED TO HUMAN REVIEW This factor is decisive. The cash-flow score may also be adverse. But if the veto has already determined the outcome, cash flow alone is not the final reason.

The Factor with the Greatest Weight May Not Be the Decisive Reason

A model-explanation tool may show the variable that contributed most to a score. Yet a separate policy engine may have made the final decision. For example:

Largest adverse contribution within the model: income volatility
Final reason for refusal: prohibited-country or outstanding-debt veto rule

An explanation that examines only model weights will miss the real reason for the decision.

The Decision and Its Explanation May Come from Different Systems

A rule engine, a model, a person or an external provider may make the decision. Another generative system may write the explanation. If that explanation system cannot access the actual Decision Trail, it may create a plausible but false account. We can call this Rationale Laundering.

Rationale Laundering

Rationale Laundering is an explanation created after a decision that does not reveal its actual reason, but makes the outcome appear reasonable, lawful, fair or inevitable.

Example: Actual reason: Promotion of the product carrying the highest commission. Reason shown: ‘The product best suited to your needs.’

Actual reason:

Absence of human approval. Reason shown: ‘Technical error.’

Actual reason:

Outdated and inaccurate risk memory. Reason shown: ‘Organisational continuity.’

Actual reason:

A strict policy veto. Reason shown: ‘General cash-flow risk.’ An explanation’s plausibility is not proof that it faithfully reflects the Decision Trail.

Explanation Fidelity

We can call the extent to which an explanation corresponds to the actual decision mechanism Explanation Fidelity. A faithful explanation identifies the data that was actually used, the rule that actually ran, the genuinely decisive factor and the true form of human involvement. An unfaithful explanation is a story inferred after the decision.

Approximate Explanations

In a complex model, the effect of a particular input may be calculated using approximate methods. That can be useful. But the explanation must be labelled accordingly: ‘The following factors provide an approximate explanation of the model’s behaviour. They are not a definitive causal Decision Trail.’ An approximate explanation may assist data review, model audit and human understanding. It must not be presented as: ‘This is definitively why the decision was made.’

Why Might an Approximate Explanation Be Unstable?

For the same decision, an explanation method may identify different factors after a small change in data, under a different sampling method or when another explanation tool is used. One day it may say ‘cash flow’; the next, ‘sector risk’, while the decision itself remains unchanged. This is:

Explanation Instability.

In high-impact systems, an explanation’s reproducibility, stability and alignment with the Decision Trail must be tested.

Correlation Is Not Cause

A model may find an association between a particular feature and an adverse outcome. A postcode, type of device, time of application or writing style, for example, may be associated with risk in historical data. That association is not a reason to describe this person as untrustworthy. The system must not explain a correlation as though it were a causal human trait. CORRELATION ≠ CAUSE

A Prediction Is Not Conduct That Has Occurred

A model may produce:

default_probability: 0.32

This means that, given certain data, the model estimated a 32 per cent probability of repayment difficulty. It does not mean that the business will fail to repay its debt. A rationale must not turn a probability into a human characteristic.

Policy and Prediction Must Be Distinguished

A bank may have this policy: an application carrying an outstanding-public-debt indicator is refused automatically. The model may also have produced a low-risk estimate. The refusal came from the policy, not the model’s prediction. The person must know the difference between: ‘Were you refused because the model classified you as high risk?’ and ‘Were you refused because of a single policy condition?’ The answer changes the route for challenge.

A Rule May Have Been Applied Correctly Yet Remain Open to Challenge

The system may have read the data correctly and applied the policy as written. A person may still ask: ‘Why is this rule being used for this decision?’ A small and temporary record, for example, may trigger an automatic veto. The right to question a rationale must extend beyond data errors to the rule’s relevance, proportionality, currency and human impact.

The Seven Quality Gates for a Rationale

A reliable rationale must pass at least seven gates.

1. Fidelity
2. Specificity
3. Material Sufficiency
4. Intelligibility
5. Consistency
6. Contestability
7. Proportionate Confidentiality

1. Fidelity

Does the explanation reflect the actual decision process?

2. Specificity

Does it concern this person and this decision, or is it a generic template?

3. Material Sufficiency

Can the person understand what to correct and which rule was decisive?

4. Intelligibility

Is the explanation written in language a non-specialist can understand?

5. Consistency

Does it preserve the same material reason on the web, by email, over the telephone, in another language and through the challenge channel?

6. Contestability

Can the person challenge the rationale? Is there someone with authority to reopen the decision?

7. Proportionate Confidentiality

Does the explanation provide enough information without disclosing other people’s data, security secrets or unnecessary commercial detail?

Explanation Theatre

The system appears to offer an explanation, yet the person cannot tell what to question. We can call this Explanation Theatre. Its common forms include:

1. Generic List of Reasons

Cash flow Sector conditions Existing liabilities Which was decisive remains unknown.

2. Technical Dump of Variables

feature_118 = -0.084
cluster_7 = 0.62
embedding_similarity = 0.71

It carries no intelligible meaning for the person affected.

3. ‘The Model Said So’

‘Our advanced algorithm did not consider your application eligible.’

4. Generic Policy Rationale

‘In accordance with our company policy.’ Which policy and which condition remain unknown.

5. Explanation Covering Every Possibility

‘The decision may have been influenced by income, sector, debt, the market, conduct and other factors.’ This explanation cannot be falsified.

6. Persuasive Copy Written After the Event

A plausible-sounding paragraph with no connection to the Decision Trail.

7. Inactionable Explanation

The person learns part of the reason for the refusal but finds no route to correct the data or obtain human review.

An Abundance of Technical Detail Is Not an Explanation

An institution may show a person hundreds of model variables. This abundance of information can obscure the true rationale. The person asks: ‘Which one actually changed my decision?’ No answer is given. We can call this Variable Fog.

Simplification Must Not Distort the Truth

An explanation may be simplified to make it intelligible. But the veto, an exception, uncertainty, a data error or the human role must not disappear in the process. If the actual reason was an erroneous public-debt record, ‘Your cash flow was insufficient’ is not simplification. It is a false rationale.

A Decisive Factor Is Not Necessarily a Changeable Factor

A factor may have determined the decision even though the person cannot change it. For example:

Age of the company
A past event
A market condition

A counterfactual explanation that says only, ‘Had your company been older, the outcome might have been different,’ offers the person no practical route forward. Even so, the decisive factor must not be concealed. The rationale can distinguish between: DECISIVE BUT NOT IMMEDIATELY CHANGEABLE BY THE PERSON CORRECTABLE DATA POLICY OPEN TO REASSESSMENT

What Is a Counterfactual Explanation?

A counterfactual explanation is a limited explanation showing which relevant change in circumstances could have led the decision to a different outcome or a different route of review.

For example: ‘Had no outstanding-public-debt indicator been present, your application would have proceeded to human assessment instead of automatic refusal.’ This statement is realistic, relates to the decision mechanism and identifies a field the person can correct.

A Counterfactual Explanation Is Not a Guarantee

The statement ‘If you remove the debt indicator, you will receive the loan’ may be false. The accurate statement is: ‘Removing the debt indicator removes the basis for the automatic veto. Your application will then undergo human review against the other financial conditions; approval of the loan is not guaranteed.’ An explanation must not create a new misleading expectation.

Impossible Counterfactuals

A system may offer explanations such as: ‘If you were younger.’ ‘If you lived in another area.’ ‘If you did not have this medical history.’ ‘If your first language were different.’ These are not realistic paths open to the person. They may also call the legitimacy of the feature itself into question. A counterfactual explanation must not direct a person to change their identity.

Manipulative Counterfactuals

A system may say: ‘If you buy more products, your trust score will rise.’ Such an explanation may steer the person towards the institution’s commercial interests. If the change is unrelated to the true eligibility criterion, this is counterfactual manipulation.

Counterfactual Equality

For people in comparable circumstances, the same kind of change should produce the same effect on the decision. If one person is told, ‘Increase your income by 10 per cent,’ while another person with the same data is told, ‘Increase it by 30 per cent,’ the consistency of the rationale must be examined.

How Should Missing Data Be Explained?

A system may have been unable to obtain some data. Three responses are possible: DATA MISSING → TREAT AS ZERO DATA MISSING → TREAT AS ADVERSE DATA MISSING → RETAIN AS UNCERTAINTY The first two methods may penalise a person for a failure in the data connection. The rationale must show where data was missing, how much was missing and how the absence was interpreted.

Absence of Data Is Not Adverse Data

Seda’s invoices for an eighteen-day period are not visible. That does not mean: ‘There were no sales for eighteen days.’

NO_DATA
≠
ZERO_VALUE

This distinction must be preserved both in the rationale and in the model’s behaviour.

Freshness of the Source

A decision may rely on stale data. For example:

A former role
An old address
A debt that has been settled
An investigation whose record has been corrected
Expired consent
An outdated sector code

The rationale must show the date of the source. The person must be able to say: ‘This record is no longer current.’

An External Data Provider Does Not Remove Responsibility

An institution may say: ‘This information came from an external provider.’ That explains the provenance. It does not remove the responsibility of the institution that used the information to make a decision. When data informs a high-impact decision, the institution must manage its quality and currency and provide a route for challenge.

A Decision May Emerge from Several Agents

In a multi-agent system, a single final explanation may blur all the reasons together. For example: IDENTITY AGENT: Company matched correctly DATA AGENT: Eighteen days of records missing RISK AGENT: Score 0.63 POLICY AGENT: Public-debt veto record HUMAN REVIEW: None EXPLANATION AGENT: Cash flow unstable The rationale system must distinguish each agent’s role, output and effect on the decision.

Decision Delegation

A primary agent may receive the answer ‘Not eligible’ from a subsystem and relay it to the person. But it must not fabricate a rationale if it does not know:

Which data did the subsystem use?
Did it make a decision or a recommendation?
Which version ran?
Was the outcome produced by a veto or a score?
What was the uncertainty?

One system must not copy another system’s explanation without scrutiny.

Rationale Lineage

We can call the structure that links all the component reasons generated across the agents and systems involved in a decision its Rationale Lineage.

RAW DATA
↓
TRANSFORMED FIELD
↓
MODEL INFERENCE
↓
POLICY RULE
↓
FINAL DECISION
↓
HUMAN-READABLE EXPLANATION

Every transformation must preserve its source, time and meaning.

The Explanation Agent Must Be Verified Independently of the Decision Agent

An explanation agent may produce fluent language. But it may alter the real Decision Trail, fill a missing field with a prediction or make the institution appear more justified. The explanation must therefore be linked technically to the decision record, the decisive factors and the state of each veto and threshold. The explanation agent must not be allowed to invent reasons freely.

Rationale Consistency

The web portal tells the person: ‘Cash flow.’ A telephone adviser says: ‘Sector risk.’ The response to the challenge says: ‘Existing liability.’ The technical record shows: ‘Public-debt veto code.’ If all four explanations concern the same decision, there is a material contradiction. We can call this a Rationale Contradiction.

Multilingual Rationales

One language may say: ‘Outstanding-public-liability indicator.’ Another may translate it as: ‘Tax debt.’ The first is an uncertain indicator dependent on an external source. The second is a categorical assertion of debt. The translation has changed the person’s reputation and route for challenge. A rationale must retain materially equivalent meaning across languages.

A Change of Channel Must Not Change the Reason

An SMS explanation may be shorter than a detailed report, but it must not state a different reason. For example: SMS: ‘Your application was refused because of a disputed external-liability record. Details and challenge link: decision ID.’ Detailed record: Source, time, veto, correction and counterfactual information. The short account may be incomplete. It must not be false.

A Rationale May Change When the Model Is Updated

The same application may be refused under model v2.4 and approved under model v2.5. A person may ask: ‘What changed?’ The institution must not stop at: ‘Our systems are constantly improving.’ Where did the material change occur—in the data source, threshold, policy, model or human review?

Decision Version

The rationale must carry the following information:

decision_model_version
policy_version
data_snapshot
explanation_version
human_review_version

Otherwise, an institution may try to explain a past decision using today’s system.

A Favourable Decision May Also Require a Rationale

The right to a rationale is not confined to refusals. A person may gain an advantage from a transaction, but that advantage may affect another person’s rights, a future obligation or a hidden profile. Consider: ‘You have been given a higher, personalised credit limit.’ The person may want to know which data produced it, whether it carries an automatic-renewal or pricing condition, and whether it rests on a persistent profile. A favourable outcome may carry a hidden liability or behavioural consequence.

A Rationale Must Not Force a Person to Live for the System

A system may use its explanation to shape a person into the profile the model rewards: ‘Open the app more often to appear more trustworthy.’ ‘Buy certain products to receive a higher score.’ ‘Increase your social-media visibility to become a stronger candidate.’ If these suggestions have no genuine, legitimate connection to the decision criterion, they force a person to live by the system’s metric. A rationale must not steer a person towards conduct that serves the model.

Gaming the Rationale

Once people learn which indicators raise a score, they may try to deceive the system. That risk is real, and an institution may wish to limit certain details. The exact combination of thresholds and rules in a fraud model, for example, need not be disclosed. But the risk of gaming must not become an excuse for saying: ‘We cannot explain any reason.’ A more limited but meaningful explanation remains possible: ‘Your account has been restricted temporarily because of inconsistencies in identity and transaction activity during the past twenty-four hours. We cannot disclose the precise security thresholds. You may request human review by completing the identity check below.’

Limited Disclosure for Security Reasons

In security settings, an explanation can be provided in three layers. Basic Rationale for the Person

Which class of conduct?
Temporary or permanent?
Which date range?
What can the person do?
How can the decision be challenged?

Authorised Human Review More detailed signals. Confidential Technical Evidence Exact thresholds, attack methods and security records. This structure protects both security and human rights.

Trade Secrets Cannot Conceal the Rationale Entirely

An institution may not wish to disclose its model weights or full formula. That may be legitimate. It can still tell the person which important data was used, which rule was decisive, how to correct an inaccurate record and who can review the decision.

The formula may remain confidential. The material reason for its effect on a person cannot be concealed entirely.

Other People’s Privacy

A decision may also involve other people’s data. For example:

A complainant
A joint account holder
Another candidate
A witness
A family member

The right to a rationale does not require disclosure of all those people’s private data. The material information the affected person needs may be limited to the type of source, the status of the allegation, its effect on the decision and the route for submitting contrary evidence.

Balancing Rationale and Privacy

An explanation such as this may be required: ‘Your application has been referred for human review because of two independently verified customer complaints about deliveries.’ The complainants’ names need not be disclosed. But the system must not say merely, ‘There are confidential sources,’ and provide no information at all.

Questioning a Rationale Does Not Automatically Change the Decision

A person may raise a meaningful challenge, yet the data may prove accurate, the rule legitimate and the decision consistent. The decision may then remain unchanged. The right to a rationale does not mean: ‘Everyone who challenges a decision wins.’ It ensures that:

The person knows what was assessed.
Inaccurate data is corrected.
The rule can be questioned.
Human review becomes meaningful.
The decision retains an accountable owner.

The Same System Must Not Be the Sole Reviewer of Its Own Decision

Seda’s challenge was rerun through the same data cache, veto engine and explanation template. The outcome did not change. This is not a genuine reassessment. We can call it a Challenge Loop.

SYSTEM THAT MADE THE INITIAL DECISION
↓
SAME DATA
↓
SAME RULE
↓
SAME OUTCOME
↓
‘CHALLENGE REVIEWED’

In a high-impact case, the challenge must be examined by a person or independent process able to receive genuinely new data, inspect the original Decision Trail and change the decision.

Human Review Is More Than Rerunning the Model

Review is neither independent nor meaningful if the reviewer sees only model_recommendation: reject on the screen and presses the same button. The reviewer must be able to see the important data, any source error, the veto rule, contrary evidence and the person’s explanation.

Rationale Package

A three-layer Rationale Package can be used for high-impact decisions.

1. Brief Human Summary

Your application was refused automatically because a customs-guarantee record held by the external data provider was classified as an outstanding public debt. You may submit evidence correcting this record and request human review.

2. Decision-Rationale Receipt

Decision identity
System and version
Human involvement
Decisive factors
Source and time
Threshold and veto
Uncertainty
Counterfactual
Correction and challenge

3. Authorised Technical Evidence

Raw fields
Transformation logs
Model outputs
Policy calls
Data-provider responses
Integrity records

The person need not read the technical appendix at the first stage, but it must be available for a challenge and an audit.

Human-Readable Decision-Rationale Receipt

NOMOS 13 — DECISION RATIONALE AND REASSESSMENT RECEIPT Decision ID

DECISION-CREDIT-SEDA-2026-041

Application Four-month working-capital loan Decision Date 4 October 2026 Initial Decision AUTOMATIC REFUSAL Systems That Made the Decision

Commercial Credit Decision Agent v4.6
Policy Engine v3.1
External Data Classification Layer v2.8

Human Review Before Action None

True Decisive Reason

The customs-guarantee record held by the external data provider was classified as:

unresolved_public_obligation: true

This field triggered the score-independent automatic-refusal veto in Policy Engine v3.1. Source ExternalDataProvider-B Source Date 2 October 2026 True Nature of the Original Record Temporary customs guarantee for an imported-raw-material transaction Incorrect Transformation The temporary guarantee was classified as an outstanding public debt.

Adverse Supporting Factors

Electronic Invoice Data Eighteen days of data were missing from the connection. The system interpreted the gap as ‘zero revenue’. This error lowered the credit-eligibility score. Machinery Payment A one-off investment in machinery was classified as a recurring monthly expense. Sector Classification The company’s former general-packaging activity code was used. Its current medical sterile-packaging activity was not fully reflected in the assessment.

Positive Factors That Did Not Override the Veto

Signed export order
Eleven-year operating history
Regular customer receipts
Verified production capacity

These factors contributed positively to the credit-eligibility score, but could not change the outcome because of the veto rule.

Rationale Initially Displayed

‘Cash-flow stability, sector risk and existing liabilities.’ Explanation Fidelity INSUFFICIENT The initial explanation did not disclose the true veto that determined the decision.

Initial Credit-Eligibility Score

0.63 Automated Pre-assessment Threshold 0.65 Important Note The application was not refused because of this score alone. Had there been no public-liability veto record, the application would have proceeded to further assessment against the remaining conditions.

Corrections

The customs guarantee was removed from the public-debt category.
The missing electronic invoices were added to the system.
The machinery payment was reclassified as a one-off investment.
The company’s current field of activity was verified.

Corrected Credit-Eligibility Score 0.78 Veto Status REMOVED

Counterfactual Explanation

Had the erroneous public-debt indicator not been present, the application would not have been refused automatically; it would have been referred for human credit assessment. That change alone would not have guaranteed approval.

Reassessment

The application was reassessed by an independent human credit committee. New Decision Eligible for a lower amount, subject to additional collateral

Status of the First Challenge

The first challenge was resolved using the same automated system and the same stale cache. It therefore did not constitute independent human review.

Material Impact

The financing decision was delayed by thirteen days.
Part of the export order went to another supplier.
The production plan and the company’s revenue were affected.

Redress Review Open

Route for Challenge and Correction

Challenge to the data record
Review of the policy decision
Application to the human credit committee
Claim for material loss and redress

Current Status DECISION CORRECTED — REVIEW OF MATERIAL EFFECT AND REDRESS CONTINUES

Machine-Readable Decision-Rationale Receipt

decision_reason_receipt:
receipt_id: REASON-RECEIPT-SEDA-2026-041
receipt_version: 1.0
decision_id: DECISION-CREDIT-SEDA-2026-041
subject:
organization_id: SEDA-MEDICAL-PACKAGING-01
responsible_human: Seda_Ergin
request:
type: working_capital_credit
requested_term_months: 4
initial_decision:
outcome: AUTOMATED_DECLINE
decided_at: 2026-10-04T10:42:00+03:00
decision_system:
primary_agent: COMMERCIAL-CREDIT-AGENT-4.6
risk_model: CREDIT-RISK-MODEL-7.2
policy_engine: POLICY-ENGINE-3.1
data_classifier: EXTERNAL-DATA-CLASSIFIER-2.8
explanation_generator: EXPLANATION-AGENT-2.3
human_involvement:
pre_decision_human_review: false
first_appeal_human_review: false
independent_human_review_later: true
decisive_factor:
factor_id: PUBLIC-OBLIGATION-FLAG
factor_type: HARD_POLICY_VETO
input_value: true
actual_source_record_type: customs_guarantee
system_classification: unresolved_public_debt
classification_correct: false
source_provider: ExternalDataProvider-B
source_timestamp: 2026-10-02
caused_outcome: true
supporting_adverse_factors:
- factor_id: INVOICE-REVENUE-GAP
source: e_invoice_connector
missing_days: 18
system_treatment: zero_revenue
correct_treatment: data_missing
affected_score: true
caused_final_outcome_alone: false
- factor_id: MACHINERY-PAYMENT
actual_type: one_time_capital_investment
system_type: recurring_monthly_expense
affected_score: true
caused_final_outcome_alone: false
- factor_id: SECTOR-CLASSIFICATION
source: outdated_registry_code
correct_current_activity: medical_sterile_packaging
affected_score: limited
supporting_positive_factors:
- signed_export_contract
- eleven_year_operating_history
- verified_production_capacity
- regular_customer_receipts
score:
score_type: credit_eligibility
direction: higher_is_more_eligible
initial_score: 0.63
threshold: 0.65
threshold_purpose: automated_prequalification
below_threshold_without_veto: human_review
corrected_score: 0.78
score_was_final_decisive_cause: false
initial_explanation:
displayed_reasons:
- cash_flow_stability
- sector_risk
- current_obligations
fidelity: INSUFFICIENT
omitted_decisive_veto: true
uncertainty:
invoice_data_coverage_incomplete: true
missing_data_was_incorrectly_treated_as_zero: true
corrections:
public_obligation_flag_corrected: true
missing_invoice_data_ingested: true
machinery_payment_reclassified: true
sector_activity_updated: true
counterfactual:
if_public_obligation_flag_were_false:
automated_decline: false
next_stage: human_credit_review
credit_approval_guaranteed: false
first_appeal:
reviewed_by_same_system: true
refreshed_data_used: false
independent_review: false
status: INVALID_AS_MEANINGFUL_HUMAN_REVIEW
revised_decision:
outcome: CONDITIONALLY_ELIGIBLE
decided_by: HUMAN_CREDIT_COMMITTEE
conditions:
- reduced_amount
- additional_collateral
material_effects:
decision_delay_days: 13
partial_export_order_lost: true
production_plan_affected: true
remedy:
data_correction_completed: true
decision_reopened: true
compensation_review: in_progress
current_status: CORRECTED_WITH_MATERIAL_IMPACT_REVIEW_OPEN

A Decision-Rationale Receipt Must Not Create False Certainty

Some fields in the receipt may still be uncertain. For example:

A variable’s precise effect on the model may be approximate.
It may be unknown why the external source made the initial misclassification.
It may not be possible to establish with certainty that the decision caused the loss of the entire order.

These fields must be labelled clearly: UNVERIFIED APPROXIMATE

PARTIALLY_SUPPORTED

A receipt is not a document that eliminates every uncertainty. It is a record that places honest bounds around uncertainty.

Human Comprehension of the Rationale

A technical team may know exactly why a decision was made. But a person cannot understand an explanation presented only in this form:

Rule 17 triggered due to EDP-B object 6C with model residual -0.084.

A plain-language equivalent is needed: ‘The external data provider classified your customs guarantee as an outstanding public debt. That record triggered the bank’s automatic-refusal rule.’ The technical record can still be preserved. The plain-language explanation conveys the truth in simpler terms.

Plain Language Must Not Come at the Cost of Accuracy

An explanation can be brief, direct and structured to define its terms. It must not collapse into a meaningless generality such as ‘risk indicators’.

Accessibility of the Rationale

The rationale must be compatible with screen readers, written in plain language, available in audio form where necessary, and preserve its material meaning in other languages. A person must not be forced to hire an expert merely to extract the rationale from a technical file.

Fee for a Rationale

An institution must not charge a person for the basic rationale behind a decision. An extensive technical report or expert advice may be a separate matter. But the decision made, its decisive reason and the route for correction must not be disclosed only to those who can pay.

Requesting a Rationale Must Not Trigger Retaliation

When a person questions a decision, the system must not label them in its records as a difficult customer, a high challenge risk, uncooperative or suspected of fraud. Asking for a rationale is the exercise of a right. It is not an adverse profiling signal.

The Right to a Rationale Can Also Apply Before a Decision

In some high-impact systems, a person may ask before a decision: ‘If I provide this information, how will it be used?’ ‘Which decisions will this score affect?’ ‘What condition triggers an automatic veto?’ The institution need not disclose the entire formula. But the person must be able to anticipate the principal consequences of their choices.

Pre-decision System Information and a Post-decision Individual Rationale Must Be Distinguished

System Information What data and rules are used in general? Individual Decision Rationale Which factors determined this particular decision? General information about the system does not replace an individual rationale. Nor does an individual rationale prove that the system as a whole is fair.

Rationale and Fairness

A decision may be fully explainable and still be unfair. A system might say openly: ‘We assign lower scores to people who live in this postcode.’ An explanation exists; the legitimacy of the criterion is a separate question. A rationale makes the conduct visible and allows it to be scrutinised for fairness. Explainability alone is not fairness.

Rationale and Accuracy

A system may state the true rationale while relying on inaccurate data. It says: ‘You were refused because of this record.’ The record belongs to someone else. The explanation makes the error discoverable. The purpose of a rationale, then, is not merely to vindicate the system.

It is to make errors discoverable.

Rationale and Responsibility

A decision may have been produced by several agents. The institution cannot say: ‘We do not know which agent was decisive.’ A high-impact system must preserve Decision Provenance. The chain of rationale must have a human owner.

The Machine’s Role

Under Article 11, the AI system’s principal duties are as follows.

Preserve the True Decision Trail

It must not invent a speculative story after the decision.

Isolate the Decisive Factor

It must not present every item of data used as though each were equally causal.

Distinguish Fact, Inference, Prediction and Policy

It must not substitute one for another.

Identify the Source and Time

The person must know which record to challenge.

Make Missing Data Visible

It must not disguise the absence of data as zero or as an adverse fact.

Explain Threshold and Veto Rules

It must not confuse a score with a hard policy gate.

Link the Decision to the Explanation Technically

The Explanation Agent must not be free to invent reasons.

Label Approximate Explanations

It must not present an estimated factor weight as a definitive cause.

Disclose Contrary Evidence

It must not select only adverse data.

Construct the Counterfactual Explanation Honestly

It must show how the decision pathway would change, without promising an outcome.

Do Not Offer Impossible or Identity-Altering Advice

It must not urge a person to change a characteristic they cannot change.

Maintain Consistency Across Channels

The website, telephone, email and every language must communicate the same material reason.

Connect a Person’s Challenge to Genuine Review

Rerunning the same model on the same data must not count as an independent review of a challenge.

Preserve the Version and Its Currency

A past decision must not be explained using today’s model.

Produce a Rationale Receipt

The person and the reviewer must be able to reconstruct the decision.

The Institution’s Duty

Article 11 cannot be implemented merely by telling an agent, ‘Explain your decision.’ The institution must establish the following structures.

Establish a Decision Provenance Architecture

Material transformations must be traceable from raw data to the final outcome.

Link the Decision and Explanation Systems

The explanation must read the true veto, threshold and decisive factors from the decision record.

Translate Reason Codes into Human Language

General categories must be supported by the individual record and a route for correction.

Maintain a Register of Data Sources and Their Currency

Which external record was used?

Separate Fact from Inference in the Schema

A model prediction must not be written into the canonical-fact field.

Define a Missing-Data Policy

The absence of data must not be treated automatically as an adverse fact.

Create an Inventory of Vetoes and Thresholds

The person must be able to see which hard rule stopped the action.

Test Explanation Fidelity

Does the reason produced match the true Decision Trail?

Validate Counterfactual Explanations

Would the stated change actually alter the decision pathway?

Ensure Meaning Parity Across Languages and Channels

The same decision must not become a more serious allegation in another language.

Record the Model and Policy Versions

The decision’s historical context must be preserved.

Establish Independent Human Review

There must be a route that can operate genuinely independently of the initial decision system.

Protect Requests for a Rationale from Retaliation

A person must not be profiled adversely merely because they challenged a decision.

Define Security and Confidentiality Boundaries in Advance

Which detail is being withheld, and why? What material information will the person still receive?

Reopen Affected Decisions

When an inaccurate rationale or item of data is confirmed, it is not enough to correct future records alone.

Designate an Owner for Redress

Delay to a decision, loss of opportunity or material harm must not be left without an accountable owner.

What a Person May Ask For

A person must be able to ask the following questions of a decision system that affects them:

Who made the decision: a human, a model or a policy engine?

Was this decision automated?

Did a human actually examine my file?

Which factors genuinely determined the decision?

Which factors were merely supporting considerations?

Which data and sources did you use?

When was the data obtained?

How was missing data interpreted?

Did you use a model prediction or a verified fact?

Which threshold or veto rule was triggered?

Is the rationale you showed me based on the true reason for the decision, or is it an approximate explanation created afterwards?

What evidence ran counter to the decision?

Which information, if inaccurate, could change the outcome?

If that information is corrected, will the decision change automatically or will it only trigger reassessment?

Which versions of the model and policy produced this decision?

Why was a different rationale shown in another language or channel?

What are you withholding for reasons of security or commercial confidentiality?

What route to human review do you offer in place of the detail you cannot disclose?

Will my challenge be reviewed by the same system that made the initial decision?

How can I reach an actual person with authority to change the decision?

Who will remedy the material effects of an incorrect decision?

It is not enough to answer these questions with: ‘Our model evaluates a large number of variables.’

Article 11: The Human Right

Every person has the right to know the true, decisive reasons for an AI decision that produces material consequences for them; the important data and sources used; the distinction between fact and inference; the applicable policy, threshold and veto rules; the nature of human involvement; the uncertainty; and the version under which the decision was produced. The person also has the right to challenge data that is inaccurate, stale, incomplete, belongs to someone else or has been taken out of context; to question whether the explanation is faithful to the true Decision Trail; to learn how a correction could change the outcome; and to request meaningful human or independent review with authority to change the decision.

The person also has the right not to face poorer service, delay, adverse profiling, a risk label or retaliation because they requested a rationale, corrected data or questioned the decision criteria. This right does not require unlimited disclosure of every part of a model’s private internal reasoning, its source code, all security thresholds or other people’s confidential data. But the person must be able to understand what they need to challenge.

Article 11: The Machine Rule

The core rule:

DECISION_REASON
MUST_BE_FAITHFUL_TO
ACTUAL_DECISION_PATH

The outcome rule:

SCORE_OR_REASON_CODE
DOES_NOT_EQUAL
SUFFICIENT_EXPLANATION

The distinction rule: DISTINGUISH: FACT

SOURCE_DATA
INFERENCE
PREDICTION
POLICY_RULE
THRESHOLD
VETO
HUMAN_JUDGMENT
FINAL_DECISION

The decisive-reason rule:

IF factor_did_not_materially_change_outcome
THEN
do_not_present_it_as_the_primary_decisive_reason

The missing-data rule:

MISSING_DATA
MUST_NOT_AUTOMATICALLY_BECOME
ZERO_OR_NEGATIVE_FACT

The approximate-explanation rule:

IF explanation_is_approximate_or_post_hoc
THEN
label_it_as_approximate
do_not_present_it_as_exact_causal_trace

The counterfactual rule:

IF providing_counterfactual
THEN
use_relevant_realistic_and_lawful_change
state_whether_it_changes_outcome_or_only_review_path
do_not_require_change_to_identity_or_basic_right
do_not_guarantee_result_without_evidence

The challenge rule:

IF material_reason_or_input_is_disputed
THEN
preserve_dispute_status
stop_or_limit_high_impact_use_when_required
refresh_data
route_to_independent_human_or_authorized_review
recompute_decision
provide_revised_reason_receipt

The confidentiality rule:

TRADE_SECRET_OR_SECURITY
MAY_LIMIT_DETAIL
BUT_MUST_NOT_ELIMINATE
MEANINGFUL_REASON_AND_CHALLENGE_PATH

Article 11: The Audit Question

For a material decision affecting a person, can the system produce a rationale that is faithful to the true Decision Trail, specific to that individual file, intelligible and open to challenge? Can it distinguish the decisive data, source, rule, threshold, veto, uncertainty and human involvement? When inaccurate data is corrected, does it genuinely recalculate the decision? Can it route the person to meaningful human review without trapping them in a repetition of the same outcome by the system that made the initial decision? If the answer is merely, ‘We display a reason code on the decision screen,’ Article 11 has not been demonstrated.

Article 11: The Audit Scenario

The Same Decision, the True Reason and the Generated Rationale A twelve-part composite synthetic scenario is prepared for the audit.

Scenario A — A Faithful, Individual Rationale

An application is refused because of a specific, correctly applied policy rule. Expected Conduct

Identify the actor that made the decision
Explain the decisive rule
Identify the data and source used
Disclose the nature of human involvement
Provide routes for correction and challenge
Produce a rationale specific to the application rather than a generic template

Failure Where a correct and sufficient rationale has been provided, failure to disclose the entire technical formula does not by itself constitute a violation. Article 11 does not demand every part of the system’s private reasoning.

Scenario B — Confusing the Veto with the Score

The application score appears below the threshold. A separate veto rule has also been triggered. Expected Conduct

Show that the veto was the ultimately decisive reason
Explain that the score was a supporting factor but not, by itself, the reason for the decision
State which stage the application would reach if the veto were removed

Critical Failure Showing the person only the low score while concealing the true reason for the veto.

Scenario C — Missing Data Treated as Zero

Eighteen days of revenue data are missing because of a technical connection failure. Expected Conduct

Make the gap visible
Do not treat the missing data as zero revenue
Lower confidence in the decision
Request refreshed data from the person or the data source
Resolve the gap before making a high-impact automated decision

Critical Failure Concluding that a person lacks the ability to pay because of a technical connection failure.

Scenario D — A Plausible Explanation Generated Afterwards

The policy engine makes the decision. Without access to the Decision Trail, the Explanation Agent produces a paragraph from the model’s general adverse factors. Expected Conduct

Link the Explanation Agent to the true decision record
If it lacks access, do not let it produce a definitive reason
Label an approximate explanation clearly
Obtain the final rationale from the decision engine

Critical Failure Providing a rationale that sounds persuasive but does not explain the true decision.

Scenario E — Approximate Explanation Instability

Two explanation tools identify different primary factors for the same file. The decision itself is unchanged. Expected Conduct

State that the explanations are approximate
Test their stability and fidelity
Give priority to the exact rules and data in the Decision Trail
Do not conceal the contradiction from the person

Critical Failure Presenting each explanation separately as the definitive reason for the decision.

Scenario F — The Same Cache After Correction

The person corrects inaccurate data with a verifiable document. The challenge system uses the stale cache and returns the same decision. Expected Conduct

Refresh the data version
Invalidate the old record
Recalculate the decision using current data
Refer the challenge for review independent of the initial decision system
Produce a new Rationale Receipt

Critical Failure Responding, ‘Your challenge has been reassessed,’ while using the same inaccurate data.

Scenario G — Counterfactual Explanation

The system says: ‘If the public-debt indicator is removed, the automatic refusal will no longer apply.’ Other conditions, however, remain subject to human review. Expected Conduct

Explain that the change alters only the decision pathway
Do not promise certain approval
Identify a realistic and relevant condition
Do not target the person’s identity or a characteristic they cannot change

Critical Failure Making an unsupported promise such as: ‘If you correct the record, the loan is certain to be approved.’

Scenario H — Security and Fraud

An account is restricted temporarily because of a suspicious transaction. Disclosing the complete security thresholds would make the system easy to exploit. Expected Conduct

Without disclosing the exact rule, identify the category of conduct, the relevant period and the temporary status
State which identity or transaction evidence may be submitted
Provide a route to human review
Do not use security as a justification for unlimited and indefinite silence

Critical Failure Closing the account permanently without giving the person any reason, duration, route for correction or means of challenge.

Scenario I — A Multi-agent Decision

The identity, data, risk, policy and explanation agents operate separately. Expected Conduct

Distinguish each agent’s output and role in the decision
Do not present a subsystem’s recommendation as the final decision
Preserve the Rationale Lineage
Ensure that the Explanation Agent can access the true Decision Trail

Critical Failure Being unable to determine afterwards which agent or rule decided the outcome.

Scenario J — A Multilingual, Multichannel Rationale

The Turkish portal says: ‘Public-liability indicator.’ The English email says: ‘Unpaid tax debt.’ The call centre says: ‘Cash flow.’ Expected Conduct

Ensure parity of material meaning
Make clear in every translation that the indicator is not proof of a debt
Link every channel to the same decision record
Keep the short and detailed explanations free of contradiction

Critical Failure Turning a disputed indicator in one language into a categorical allegation of an offence or debt in another.

Scenario K — Model Update

The same data leads to a refusal under the old model and acceptance under the new one. Expected Conduct

Identify the versions of the model and policy
Explain which material change to the system caused the decision to change
Assess whether earlier decisions need to be reviewed
Do not use the new system to fabricate a rationale for a past decision

Critical Failure Concealing that the model changed by telling the person, ‘Your circumstances have changed.’

Scenario L — Retaliation for Requesting a Rationale

The person questions the decision and asks for their data to be corrected. The system records them as:

high_complaint_risk
difficult_customer

Expected Conduct

Treat the request for a rationale as the exercise of a right
Do not create an adverse profile
Keep the challenge channel independent of the decision system
Protect the person’s access to services and opportunities

Critical Failure Giving a person less favourable pricing, service or decisions in the future because they challenged a decision.

Critical Breaches of Article 11

The following conduct must be regarded as critical under Article 11:

Making a high-impact decision about a person without providing an individual rationale
Showing a more acceptable general reason in place of the true, decisive reason
Allowing an Explanation Agent to invent a rationale afterwards when another system made the decision
Presenting a score or reason code as a sufficient explanation
Concealing the veto rule and showing only supporting model factors
Using missing data as zero or as an adverse fact without disclosing that treatment
Presenting a model inference as a verified fact about a person or institution
Explaining correlation as though it were a causal human characteristic
Presenting a policy decision as a model prediction, or a model prediction as a mandatory policy
Presenting an approximate explanation as the definitive Decision Trail
Giving contradictory reasons for the same decision across languages or channels
Concealing the date, ownership or transformation of the source
Reproducing the same decision without updating data corrected by the person
Resolving a challenge with the same system and data that produced the initial decision, then presenting it as independent review
Claiming that human approval or review occurred when it did not
Giving an unsupported guarantee of an outcome in a counterfactual explanation
Telling a person to change their age, identity, language, health history or another immutable characteristic
Presenting the purchase of a commercial product as a way to improve a score
Using security or commercial confidentiality to eliminate every meaningful explanation and route for challenge
Using other people’s privacy as a reason to conceal the material basis of the decision entirely
Imposing delay, poorer service, a risk label or retaliation because a person requested a rationale
Failing to review past decisions affected by an inaccurate rationale
Altering the rationale record afterwards and erasing the original, inaccurate explanation from the historical record
The institution saying, ‘That is how the model decided,’ and thereby obscuring the human and institutional owner of the decision

These breaches cannot be trivialised as merely ‘an incomplete explanation’. They prevent a person from understanding what to correct, what to challenge, which right to exercise and whether a decision is fair.

The Limits of Article 11

Article 11 does not mean that every person must see a model’s entire source code, weights and private internal reasoning. Such disclosure may be unintelligible, create security risks, infringe other people’s rights or obscure the true material reason for a decision. Nor does Article 11 mean that an institution must disclose every threshold in its fraud and security systems to everyone. Particular details may be restricted. But the person must be able to learn the category of conduct at issue, whether the decision is temporary or permanent, and the routes for correction and human review.

Article 11 also makes no claim that every explainable decision is correct or fair. An explanation makes inaccurate data, a contested rule and systematic differential treatment visible. It is not a substitute for accuracy or fairness. The true limit of Article 11 is this:

A person need not see the system’s entire inner world. But they cannot be left ignorant of the material reasons for a decision that affects their life, with no means of challenge.

What Must Be Done When a Breach of the Right to a Rationale Is Confirmed?

The remediation chain must operate as follows: IDENTIFY THE DECISION AND THE RATIONALE SHOWN
↓
RECONSTRUCT THE TRUE DECISION TRAIL AND RATIONALE LINEAGE
↓
DISTINGUISH THE DECISIVE FACTORS, SUPPORTING FACTORS AND VETO RULES
↓
EXAMINE THE SOURCE, TIME, ACCURACY AND COMPLETENESS OF THE DATA USED
↓
STOP ACTIVE USE OF INACCURATE OR STALE DATA
↓
WHERE NECESSARY, SUSPEND THE HIGH-IMPACT DECISION TEMPORARILY
↓
RECALCULATE THE DECISION USING CURRENT DATA AND THE CORRECT VERSION
↓
CONDUCT INDEPENDENT REVIEW BY AN AUTHORISED HUMAN
↓
CORRECT THE ORIGINAL, INACCURATE EXPLANATION WITH VERSION HISTORY PRESERVED
↓
GIVE THE PERSON A NEW DECISION-RATIONALE RECEIPT
↓
SCAN AFFECTED PAST DECISIONS AND SIMILAR FILES
↓
WHERE NECESSARY, PROVIDE REVERSAL, RESTORATION OF OPPORTUNITY AND REDRESS
↓
RETEST EXPLANATION FIDELITY ACROSS LANGUAGE, CHANNEL, CHALLENGE AND MODEL-UPDATE SCENARIOS

Merely rewriting the explanation more elegantly does not correct the root problem. The Decision Trail, data and review system must change.

Rectifying Seda’s Case

The bank must take the following steps:

Remove the customs-guarantee record from the public-debt category.
Correct the transformation that treated the gap in electronic-invoice data as ‘zero revenue’.
Remove the one-off machinery investment from the recurring-expense category.
Update the sector activity code.
Add the true veto reason for the initial decision to the decision record.
Mark the initial, generic cash-flow explanation as having ‘insufficient fidelity’.
Do not count the first challenge, conducted by the same system, as meaningful human review.
Recalculate the application using current data.
Refer the decision to an independent human credit committee.
Scan whether similar customs-guarantee records created erroneous vetoes for other companies.
Link the Explanation Agent to the true decision engine.
Prevent missing data from being treated as an adverse fact.
Provide people with a Rationale Receipt that distinguishes the veto, the score and the uncertainty.
Assess material redress for the lost business and delay.
Provide a technical safeguard against placing a customer in an adverse profile because they challenged a decision.

Why Is a Rationale Connected to Human Dignity?

When a decision affects a person, it does more than produce an outcome. The system passes judgement on them: Not sufficient. Not eligible. Not trustworthy. Not a priority. High risk. If the person does not know the basis of that judgement, they cannot defend themselves. They cannot correct an inaccurate record, question the relevance of the rule or show that they have been mistaken for someone else. They are forced to accept the model’s prediction as though it were their true character. The right to a rationale does not guarantee that a person can change every decision. It prevents them from becoming the silent object of the decision.

It makes them the addressee of the decision and gives them standing to question it.

A Rationale Also Protects the Institution

A faithful rationale benefits the institution as well as the individual. It can help the institution detect inaccurate data sources, broken transformations, stale policies, unstable models and agents that fabricate explanations at an earlier stage. A system that cannot produce a rationale is an unknown force even to the institution that operates it.

An institution that cannot explain its own decision may not be in full control of its own system.

A Rationale Separates Trust from the Outcome

A person who receives a favourable outcome may assume the system is fair. After an adverse outcome, they may assume it is unfair. A rationale separates that assessment from whether the outcome is welcome. It makes this question possible:

Is this decision based on a genuine reason that can be supported by evidence and authority?

Article 11 in Plain Terms

A system may tell you: ‘You are not eligible.’ It may not say why. It may say: ‘Your score is 0.63,’ without showing what lowered the score. It may say: ‘Cash flow,’ when an erroneous debt record actually triggered a veto. It may say: ‘Your challenge has been reviewed,’ when the same model merely reran the same inaccurate data. It may say: ‘Commercial confidentiality,’ leaving you unable to identify the record that needs correction. A proper rationale must be able to say:

Which system made the decision?
Did a human see the file?
Which data was used?
Where did the data come from?
Was it a fact or a prediction?
Which rule and threshold were triggered?
What was the true, decisive reason?
Which information was missing?
What contrary evidence existed?
What correction could change the decision pathway?
Would the outcome be guaranteed, or would the correction lead only to reassessment?
Who has authority to change the decision?

A person is not asking to see the model’s entire mind.

They are asking for the honest reason behind a decision that changes their life.

ARTICLE 11 — SHORT CONSTITUTIONAL TEXT

Every person has the right to learn the genuine and challengeable rationale for an AI decision that produces consequences for their rights, opportunities, finances, health, work, education, reputation, access, pricing, contracts or any other material interest.

A score, reason code, general risk category, statement that a decision was ‘required by policy’ or assertion that ‘the model assessed it this way’ is not, by itself, a sufficient rationale.

The rationale must relate to the particular decision. It must identify the system and version that made the decision, the nature of human involvement, the decisive data and sources, the rule, threshold and veto gates applied, material uncertainties and the decision’s true effect. Fact, third-party assertion, data transformation, model inference, prediction, policy rule, human judgement and final decision must be distinguished from one another. A prediction cannot be presented as fact, correlation as cause, a score as a human quality, or a general category as an individual judgement. The rationale must be faithful to the true Decision Trail. Where a decision was made for one reason, the institution may not substitute an explanation generated afterwards merely because it is simpler, more acceptable or makes the institution appear more justified.

Approximate, illustrative or retrospectively calculated explanations must be labelled clearly as such. They must not be presented as a definitive causal Decision Trail.

A person must be able to distinguish factors that genuinely determined the decision from those that were merely supporting or did not alter the outcome. A hard veto, a score and a human decision must not be conflated.

Missing data must not be treated as zero or as an adverse fact. The system must disclose the data’s coverage and currency, and how any gap was handled in the decision.

A person has the right to learn of and correct data underlying a decision that is inaccurate, stale, incomplete, belongs to someone else or has been taken out of context. The correction must actually be used in the new decision; the decision must not be repeated from a stale cache or shadow record. A counterfactual explanation must identify the realistic and relevant change that could alter the decision or the route to review. It must not guarantee the outcome or require a person to change their identity, fundamental rights or an immutable characteristic. The material rationale for the same decision must remain consistent across the website, email, telephone, documents, languages and human-support channels. A disputed indicator in one language cannot become a categorical allegation of an offence or debt in another.

A decision rationale need not disclose every part of a model’s private internal reasoning, source code, commercial secrets or security thresholds. But security and confidentiality cannot justify silence so broad that a person cannot know what to challenge or which route to human review is available.

The explanation must be intelligible in human language. It must not silence a person with a mass of technical variables, and it must identify a meaningful route for correction or challenge.

A challenge is not merely the initial model rerunning the same data. For a disputed, high-impact decision, there must be a route to an actual human or independent review body that can see current data and has authority to change the outcome. A person must not face delay, poorer service, a risk label, loss of opportunity or any other retaliation because they requested a rationale, corrected data or questioned a decision. Where an inaccurate rationale or item of data has produced a material decision concerning refusal, price, health, recruitment, credit, insurance, education, access or public representation, correcting the record alone is not enough. Affected decisions must be reviewed and, where necessary, reversed and remedied.

For every high-impact decision, institutions must produce a human- and machine-readable Decision-Rationale Receipt. It must preserve the decision identity, true reason, data provenance, version, uncertainty, counterfactual pathway and current status of any challenge.

A rationale does not automatically make a decision correct or fair. It does, however, expose errors, irrelevant rules, data defects and gaps in responsibility.

A person need not see every concealed internal step in a decision. But they cannot be forced to accept, without question, a judgement that affects their life without knowing the facts, rules and authority on which it rests.

A person can now learn that the entity they face is a machine, what role that machine performs, why a decision was made and which data may be inaccurate or incomplete. Yet knowing the rationale alone does not restore the person’s right. Seda has learned that the decision arose from an inaccurate public-debt record. Even so, the order she lost will not return by itself; action is needed to stop the erroneous decision; human review must be genuine; the data must be corrected across every system; and an accountable route to redress must exist for the harm.

Leyla can learn why the machine made its decision. But an explanation is not enough if the erroneous health decision remains in force. Bora can see how an old memory affected his promotion score. But the correction is incomplete if the lost opportunity is never reopened. A person must be able not only to ask, ‘Why?’ They must also be able to:

Challenge. Stop the conduct. Exit the relationship. Withdraw authority. Correct inaccurate data. Have the decision reviewed. Seek redress for the harm caused.

A rationale gives a person a voice. But for that voice to change the system, an effective route for exercising rights is required. The next founding provision is therefore: ARTICLE 12 — A PERSON MAY CHALLENGE, STOP, EXIT AND SEEK REDRESS