Explainable artificial intelligence increasingly offers diverse ways to communicate how intelligent systems operate, yet explanation selection is still frequently driven by method availability or model compatibility rather than stakeholder need. This article develops a stakeholder-oriented taxonomy for determining which explanation type may be appropriate for whom, at which decision moment, and for what purpose. Explanation is treated as a multiform system capability encompassing different scopes, reasoning functions, presentation modes, interaction patterns, and quality requirements. The taxonomy distinguishes global explanations concerned with model-level behaviour from local explanations directed at individual predictions, while clarifying the roles and limitations of feature attribution, saliency, surrogate models, rule extraction, transparency, fidelity, stability, and completeness. It further differentiates counterfactual, contrastive, and causal explanations according to their contributions to alternative reasoning, actionability, contestability, recourse, and accountability. Example-based, case-based, prototype, rule-based, natural-language, interactive, dialogue-based, adaptive, and personalized explanations are positioned according to user expertise, cognitive accessibility, task demands, and interaction context. The proposed taxonomy connects explanation families with stakeholder roles, pre-decision, during-decision, and post-decision timing, explanation purpose, decision consequence, uncertainty, trust calibration, human oversight, and accountability requirements. Its central contribution is a structured selection logic that moves beyond technical method categories toward stakeholder–purpose–timing–risk alignment. The taxonomy can guide explanation design and evaluation but does not independently establish understanding, fairness, recourse, accountability, legal sufficiency, trustworthiness, or deployment readiness. Stakeholder-specific and decision-context-specific validation therefore remains necessary.
Explanations in intelligent systems are not neutral descriptions transmitted from a model to a passive recipient. They are selective communications shaped by the question being asked, the information considered relevant, and the cognitive and social expectations of the person receiving them. Human explanations are often contrastive, audience-sensitive, and directed toward particular uncertainties rather than toward complete disclosure of every factor involved [1]. Consequently, the central explainability problem is not merely whether a system can generate an explanation, but whether it can produce an appropriate explanation for a specific stakeholder and purpose.
Existing explainable artificial intelligence classifications provide valuable distinctions among intrinsic and post-hoc methods, model-specific and model-agnostic approaches, and local and global explanation techniques. These classifications establish an essential technical vocabulary, but technical form alone does not determine whether an explanation is cognitively accessible, decision-relevant, actionable, or suitable for accountability [2]. An explanation method may be technically compatible with a model while remaining mismatched to the stakeholder’s question, expertise, decision authority, or exposure to harm.
Black-box explanation methods also differ in the object they explain, the information available to the explanation process, the scope of their claims, and the form of their outputs. Global summaries, local rules, feature relevance scores, representative examples, prototypes, counterfactuals, and surrogate models therefore answer different explanatory questions [3]. Treating these outputs as interchangeable can conceal important distinctions between describing general model behaviour, accounting for an individual prediction, identifying an alternative outcome, communicating a decision rule, and supporting scrutiny of a consequential decision.
This article develops an original stakeholder-oriented explainability taxonomy organized around four questions: which explanation is needed, by which stakeholder, at which decision moment, and under which purpose or risk condition? Stakeholder interests can include understanding, debugging, decision support, justification, contestation, recourse, oversight, or accountability, and these interests should not be reduced to fixed role-based assumptions [4]. The proposed taxonomy therefore connects explanation scope and reasoning function with stakeholder responsibility, expertise, timing, actionability, cognitive accessibility, uncertainty, trust calibration, and accountability demands.
Explainability should be understood as a multiform system capability rather than a single property possessed uniformly by a model. Interpretability commonly concerns the extent to which model behaviour or reasoning can be understood, while transparency concerns access to relevant structures, processes, data relations, or decision logic. Intelligibility and comprehensibility refer more directly to whether an account can be cognitively processed by an intended audience. These concepts overlap, but they should not be treated as equivalent because they support different design objectives and evaluation approaches [5].
A multiform capability links explanation purpose, audience, presentation, and evaluation. Developers may require diagnostic information about model behaviour; domain experts may need evidence aligned with professional reasoning; operators may need timely indications of abnormal system behaviour; and affected individuals may need understandable reasons and meaningful routes for challenge. Explanation design should therefore connect the user group and intended goal with an appropriate explanation form and evaluation method rather than beginning with a preferred technical technique [6].
Interpretability is also multidimensional. A model or explanation may be descriptively accurate yet irrelevant to the stakeholder’s task, practically useful yet incomplete, or simple enough to inspect while concealing important interactions. Predictive performance, descriptive fidelity, domain relevance, and human usability can diverge and may require separate evaluation [7]. Explanation quality should consequently be specified relative to the intended purpose instead of being represented as a single universal property.
Explanations may be static, such as a fixed feature-attribution display, or dynamic, such as an evolving dialogue that responds to follow-up questions. They may be uniform across users or adapted according to expertise, task state, cognitive needs, or interaction history. However, adaptive and personalized explanations introduce risks of stereotyping, selective omission, privacy intrusion, and inconsistent disclosure. A taxonomy can distinguish explanatory objects, communicative functions, audiences, and epistemic claims, but cannot establish the sufficiency of any explanation type without contextual evaluation [8].
Global explanations address questions about how a model generally behaves, which variables or structures influence its outputs, and where broad decision patterns or failure regions may occur. Local explanations address why a particular prediction was produced for a specific case. Local feature attributions may be aggregated to support broader model analysis, but aggregation does not make local and global explanation interchangeable because each scope answers a different explanatory question [9]. Stakeholder needs should therefore determine whether model-level understanding, instance-level understanding, or both are required.
Prediction-level feature attribution estimates how selected inputs contribute to an output under particular modeling and attribution assumptions. Such explanations can support case review, comparison, and diagnostic analysis, but their interpretation depends on how feature dependence and background distributions are represented. When dependent features are treated inadequately, attribution values can change substantially and may communicate a misleading account of influence [10]. Attribution should therefore disclose its assumptions and should not be interpreted automatically as causal responsibility.
Saliency explanations highlight input regions or elements associated with a model output, particularly in deep learning applications involving images, signals, or text. Their visual immediacy can assist expert inspection, yet visually plausible maps may not faithfully represent the behaviour of the underlying model. Objective evaluation of relevance visualizations is therefore required alongside human assessment of usefulness and interpretability [11]. Similar caution applies to surrogate explanations and extracted rules, whose apparent simplicity may conceal divergence from the black-box model they approximate.
Model transparency can reduce dependence on post-hoc approximation when an intrinsically interpretable model is appropriate for the task. In consequential settings, a post-hoc explanation should not automatically be treated as an adequate substitute for a model whose decision logic can be directly examined [12]. Nevertheless, transparency to developers does not ensure accessibility to lay users, and a comprehensible local explanation does not establish global safety, fairness, or accountability. Table 1 summarises global and local explanation types, their explanation scope, stakeholder needs, potential uses, failure risks, evaluation needs, and taxonomy roles.
Table 1. Global and Local Explanations in Stakeholder-Oriented Explainable AI: Model-Level Explanation, Prediction-Level Explanation, Feature Attribution, Saliency, Surrogate Explanation, Rule Extraction, Explanation Scope, Explanation Granularity, Fidelity, Stability, Completeness, and Explanation-Sufficiency Boundaries
Explanation type | Core explanation question | Scope of explanation | Likely stakeholder need | Potential use | Failure or misuse risk | Evaluation need | Taxonomy role |
Global explanation | How does the system generally behave? | Entire model or broad behavioural region | Developer, model builder, auditor, manager, domain expert | Inspection, monitoring, validation, risk review | Aggregate patterns may conceal local or subgroup failures | Fidelity, coverage, stability, subgroup analysis | System-scope explanation |
Local explanation | Why was this output produced for this case? | Individual prediction or decision | Affected individual, decision maker, operator, domain expert | Case review, decision support, contestation | May be unstable, incomplete, or generalized beyond the case | Local fidelity, relevance, stability, uncertainty | Instance-scope explanation |
Model-level explanation | What logic or relationships characterize the model? | Whole model | Developer, auditor, expert user | Debugging, documentation, governance | Simplification may omit interactions or exceptions | Completeness, complexity, global fidelity | System-scope and oversight-oriented explanation |
Prediction-level explanation | Which factors influenced this particular result? | Single output | End user, decision subject, operator | Individual decision understanding | Influence may be mistaken for causation or responsibility | Case fidelity, feature semantics, uncertainty | User-facing instance explanation |
Feature attribution | How much did each input contribute under the selected assumptions? | Local or aggregated global | Analyst, expert, affected person | Factor comparison, debugging, review | Dependence assumptions may distort reported contributions | Correctness, sensitivity, consistency | Attribution subtype |
Saliency explanation | Which input regions or elements were highlighted? | Usually local | Developer, expert, operator | Visual model inspection | Plausible visualization may be unfaithful or unstable | Perturbation tests, stability, expert relevance | Visual instance explanation |
Surrogate explanation | What simpler model approximates the original system? | Global or local approximation | Developer, auditor, expert | Inspection and approximate rule extraction | Surrogate may diverge outside its validated scope | Scope-specific fidelity, coverage, stability | Approximation-based explanation |
Rule extraction | Which conditions appear to govern outputs? | Global or local | Expert, operator, auditor | Traceability and decision review | Rules may oversimplify probabilistic behaviour | Fidelity, exceptions, complexity, coverage | Rule-oriented explanation |
Model transparency | Can internal logic be directly examined? | Intrinsic model | Developer, expert, auditor | Direct verification and documentation | Developer transparency may not equal user comprehensibility | Simulatability, decomposability, domain intelligibility | Intrinsic system property |
Explanation scope | Is the account model-wide, regional, cohort-based, or case-specific? | Cross-cutting | All stakeholders | Preventing inappropriate generalization | Scope may be unstated or misunderstood | Explicit scope declaration and validation | Mandatory taxonomy selector |
Explanation granularity | How much detail is appropriate? | Cross-cutting | Depends on expertise and task | Layered communication | Too little omits relevant evidence; too much causes overload | Cognitive-load and task testing | Presentation and adaptation dimension |
Fidelity, stability, and completeness | Does the explanation accurately, consistently, and sufficiently represent its stated object? | Global or local | All stakeholders | Technical and human evaluation | A plausible account may be inaccurate, unstable, or materially incomplete | Multidimensional, purpose-relative evaluation | Cross-cutting quality requirements |
Global-explanation sufficiency boundary | Can a global account prove that an individual decision was appropriate? | Boundary condition | All stakeholders | Preventing overclaiming | System summaries may not resolve case-specific concerns | Instance-level and contextual validation | Explicit system-scope boundary |
Local-explanation sufficiency boundary | Can a local account establish system-wide safety, fairness, or accountability? | Boundary condition | All stakeholders | Preventing false reassurance | Persuasive case explanations may conceal systemic problems | Global auditing and outcome monitoring | Explicit instance-scope boundary |
Counterfactual and contrastive explanations are closely related but serve distinguishable reasoning functions. A counterfactual typically asks what would need to change for a different output to occur, whereas a contrastive explanation asks why one outcome occurred rather than another selected alternative. The relevance of either explanation depends on the user’s actual question, the selected contrast case, and the decision context [13]. A technically valid alternative may therefore remain unhelpful when it answers the wrong contrast or focuses on factors outside the stakeholder’s concern.
Counterfactual quality cannot be reduced to finding the mathematically smallest change around a decision boundary. A useful account may need to satisfy validity, proximity, sparsity, plausibility, diversity, robustness, and context-sensitive actionability requirements [14]. Minimal change in a normalized feature space may correspond to an unrealistic, inaccessible, costly, or semantically incoherent change in the stakeholder’s life. Feasibility constraints should therefore account for immutable attributes, causal dependencies, institutional rules, unequal burdens, and the possibility that apparently similar changes have different consequences across groups.
Causal explanations address mechanisms, interventions, or pathways rather than only modeled associations. Counterfactual language can resemble causal reasoning, but a model-relative statement that changing a feature would alter a prediction does not independently demonstrate that changing the corresponding real-world condition would cause the desired outcome [15]. Causal claims require justified assumptions, appropriate evidence, domain knowledge, and explicit uncertainty. Without these safeguards, an explanation can convert correlational model behaviour into an unsupported narrative of cause, responsibility, or blame.
Recourse-oriented explanations extend beyond describing an alternative prediction by asking whether a person can perform a feasible action that will produce a meaningful change in the real decision process. Contrastive explanations, counterfactual examples, consequential recommendations, and effective recourse should therefore remain distinct taxonomy categories [16]. An explanation may support contestability by revealing decision boundaries or questionable factors, but contestability also requires accessible procedures, review authority, and a possibility of correction. Counterfactual explanation alone does not guarantee recourse, and causal-looking explanation alone does not guarantee causal truth or accountability.
Example-based explanations communicate model behaviour through representative, similar, or contrasting cases. Case-based accounts can connect a current decision to prior instances, while prototypes summarize characteristic features of a class. Rule-based explanations instead express conditional logic, such as the conditions associated with a prediction. These forms can support concrete reasoning, but comparative evaluation indicates that explanation form may influence persuasion and advice acceptance without necessarily improving understanding or task performance [17].
Natural-language and dialogue-based explanations can translate technical outputs into ordinary or domain-specific language and allow users to ask “why,” “why not,” “what if,” and “what next.” Interactive explanation can progressively disclose detail and refine the explanatory question as a decision develops. However, conversational fluency does not ensure fidelity, and an interactive system may produce inconsistent, incomplete, or overconfident responses across dialogue turns [18].
Explanation interfaces should be designed around the workflow in which decisions occur. Participatory design with intended users can reveal which evidence, terminology, comparisons, uncertainty statements, and interaction controls are meaningful in practice [19]. Domain experts may require detailed evidence and exception handling, whereas affected individuals may need accessible reasons and challenge routes. These needs cannot be inferred reliably from a technical explanation category alone.
Adaptive and personalized explanations may modify granularity, modality, sequencing, or terminology according to expertise and interaction context. Yet user background and initial impressions can alter mental models, trust, and interpretation of AI outputs [20]. Adaptation may therefore create explanation mismatch, overload, stereotyping, or selective omission when it is poorly governed. Personalization should remain inspectable and reversible and does not guarantee understanding or responsible explanation fit. Table 2 compares counterfactual, contrastive, causal, example-based, rule-based, interactive, and adaptive explanation types according to reasoning function, stakeholder use, actionability, accountability role, and evaluation need.
Table 2. Counterfactual, Contrastive, Causal, Example-Based, Rule-Based, Interactive, and Adaptive Explanations: Reasoning Function, Actionability, Recourse, Causal Boundaries, Similarity, Rules, Dialogue, Personalization, Cognitive Risk, Evaluation Needs, and Taxonomy Roles
Explanation type | Core explanation question | Reasoning or interaction function | Likely user or task context | Potential benefit | Failure or overclaiming risk | Validation or evaluation need | Taxonomy role |
Counterfactual | What would need to change for another output? | Alternative-state reasoning | Affected person, decision maker, developer | Clarifies decision boundaries | Infeasible or unstable changes | Validity, plausibility, feasibility, robustness | Actionability-oriented explanation |
Contrastive | Why outcome A rather than B? | Difference-focused reasoning | Lay user, expert, auditor | Answers focused “why” questions | Irrelevant or misleading comparison | Foil relevance, fidelity, completeness | Reasoning-oriented explanation |
Causal | What mechanism or intervention affects the outcome? | Mechanistic reasoning | Expert, auditor, accountability actor | Supports intervention analysis | Correlation presented as causation | Identification, assumptions, uncertainty | Causality-oriented explanation |
Recourse-oriented | What feasible action may improve a future outcome? | Consequential recommendation | Adversely affected individual | Supports possible response | Action may not alter the real process | Cost, accessibility, persistence, effectiveness | Contestability-oriented explanation |
Example-based | Which representative cases clarify the output? | Similarity and analogy | Lay user, expert, decision maker | Concrete comparison | Cherry-picked or biased examples | Representativeness, diversity, similarity validity | Similarity-oriented explanation |
Case-based | Which prior cases resemble this case? | Precedent-style comparison | Domain and operational decisions | Supports experiential reasoning | Historical cases may be outdated or biased | Provenance, relevance, comparability | Similarity-oriented explanation |
Prototype | What representative instance characterizes a class? | Category summarization | Classification tasks | Compact mental-model support | Conceals within-class variation | Coverage and subgroup representativeness | Similarity-oriented explanation |
Rule-based | Which conditions led to the result? | Conditional reasoning | Expert, operator, auditor, affected person | Traceability and concise logic | Rule may oversimplify the model | Fidelity, coverage, exceptions, complexity | Rule-oriented explanation |
Natural-language | How can reasons be communicated accessibly? | Linguistic presentation | Lay user, expert, affected person | Improves accessibility | Fluent but unfaithful explanation | Factuality, fidelity, readability, uncertainty | Cross-cutting presentation form |
Interactive | What follow-up information does the user need? | Iterative exploration | End user, expert, operator | Progressive disclosure and user control | Inconsistency, overload, privacy risk | Task success, coherence, cognitive load | Interaction-oriented explanation |
Dialogue-based | Why, why not, what if, or what next? | Conversational question answering | Decision-support interaction | Clarifies user intent | Contradictory or overconfident answers | Turn-level fidelity and recovery testing | Interactive subtype |
Adaptive | How should explanation content change with context? | Context-sensitive adjustment | Mixed-expertise environments | Potentially improves relevance | Stereotyping or hidden omission | Fairness, privacy, user control, longitudinal testing | Adaptation-oriented explanation |
Personalized | Which explanation properties suit this individual? | Individual tailoring | User-facing intelligent systems | May reduce unnecessary complexity | Preference may conflict with completeness | Preference–performance comparison | Adaptation-oriented subtype |
Dynamic | How should the explanation evolve over time? | Temporal updating | Monitoring and sequential decisions | Reflects changing evidence | Conflicting explanations across time | Temporal consistency and traceability | Timing and interaction dimension |
Explanation-overload boundary | Has detail exceeded processing capacity? | Cognitive-risk control | Time-pressured or non-expert users | Supports layered delivery | Reduced comprehension or verification | Cognitive-load and performance testing | Cross-cutting failure boundary |
Personalization boundary | Does tailoring prove responsible stakeholder fit? | Sufficiency control | All users | Prevents overclaiming | Manipulative, discriminatory, or incomplete adaptation | User override, fairness, privacy, usefulness | No-personalization-guarantee boundary |
Lay users and end users generally need explanations that communicate relevant reasons without unnecessary technical complexity. Accessibility may depend on familiar language, meaningful examples, restrained detail, and explicit uncertainty. End-user research indicates that explanation usefulness must be assessed in relation to the user’s task rather than assumed from the availability of an explanation interface [21]. A concise local explanation may sometimes be sufficient for orientation, while a consequential decision may require layered access to supporting evidence.
Affected individuals and decision subjects may need to understand why a particular outcome occurred, whether relevant information was used correctly, and how the decision can be questioned. Preferences for explanation content and presentation can differ across users and contexts [22]. Preference, however, is not equivalent to fidelity, usefulness, or procedural adequacy. A preferred explanation may still conceal uncertainty, omit material information, or fail to provide a meaningful challenge route.
Trust should be treated as a calibration problem rather than an outcome to maximize. Perceived explainability and causability may influence user acceptance and confidence [23], but a persuasive explanation can increase confidence even when the underlying prediction or explanation is unreliable. Explanation quality therefore requires separation of perceived clarity from technical fidelity, decision usefulness, and the user’s ability to recognize system limitations.
Domain experts, developers, model builders, and operators require explanations aligned with their different responsibilities. Domain knowledge can affect trust, task performance, and reliance on AI assistance [24]. Experts may need detailed causal assumptions, exceptions, uncertainty, and supporting cases, whereas developers may prioritize diagnostic fidelity and reproducibility. Operators may need timely dynamic explanations that identify anomalies and specify when escalation or override is appropriate.
Managers, auditors, regulators, compliance actors, human overseers, and accountability actors require system-level evidence, documentation, traceability, and links between individual decisions and organizational controls. Decision makers additionally need explanations that support verification rather than passive acceptance, because reductions in overreliance depend on whether users engage with and can assess the explanation [25]. High-stakes use demands stronger validation, human control, and contestability than low-stakes orientation. Table 3 maps stakeholder-adaptive explanation requirements across user roles, decision timing, explanation type, explanation quality, failure risks, and governance needs.
Table 3. Stakeholder-Adaptive Explanation Requirements for Explainable Intelligent Systems: Lay Users, Domain Experts, End Users, Affected Individuals, Decision Subjects, Decision Makers, Operators, Managers, Developers, Model Builders, Auditors, Regulators, Compliance Actors, Human Overseers, Decision Timing, Explanation Quality, and Stakeholder-Fit Boundaries
Stakeholder or user role | Core explanation need | Decision timing | Explanation type likely to be relevant | Required explanation quality | Failure risk | Evaluation or governance need | Taxonomy role |
Lay user | Accessible account of what happened | During or post-decision | Local, contrastive, example-based, natural-language | Clarity, relevance, uncertainty | Overload or causal misunderstanding | Comprehension and accessibility testing | User-facing explanation |
Domain expert | Evidence aligned with professional reasoning | Pre-, during-, and post-decision | Global, local, rule-based, causal, interactive | Fidelity, completeness, domain relevance | Plausible but operationally irrelevant output | Domain validation and workflow testing | Expert-facing explanation |
End user | Understand system behaviour sufficiently for safe use | During interaction | Local, example-based, interactive, adaptive | Usefulness, accessibility, consistency | Overreliance or abandonment | Usability and reliance evaluation | User-facing explanation |
Affected individual | Understand and challenge a consequential outcome | Post-decision | Local, contrastive, counterfactual, recourse-oriented | Case relevance, feasibility, procedural clarity | Illusory recourse | Accessible review and correction process | Affected-person explanation |
Decision subject | Know why the system treated this case as it did | Post-decision | Local, rule-based, counterfactual | Fidelity, understandable reasons, uncertainty | Attribution interpreted as blame | Case review and challenge pathway | Affected-person explanation |
Decision maker | Assess whether to accept, question, or override advice | During decision | Local, rule-based, example-based, interactive | Verification support and calibrated confidence | Automation bias or underuse | Reliance and override testing | Decision-support explanation |
Operator | Recognize anomalies and intervention needs | During operation | Global, local, dynamic, rule-based | Timeliness, stability, traceability | Alert fatigue or stale explanations | Monitoring and escalation governance | Oversight-oriented explanation |
Manager | Understand aggregate performance and risk | Pre-deployment and monitoring | Global, risk summary, rule-based | Completeness, comparability, uncertainty | False assurance from summaries | Governance review and outcome monitoring | Manager-facing explanation |
Developer | Diagnose model and data behaviour | Development and monitoring | Attribution, saliency, global, local, surrogate | Technical fidelity and reproducibility | Optimizing explanation appearance | Robustness and version testing | Developer-facing explanation |
Model builder | Inspect learned relationships and failure regions | Development | Global, local, feature attribution, examples | Stability, coverage, diagnostic value | Misdiagnosis from unfaithful outputs | Technical benchmarking | Developer-facing explanation |
Auditor | Reproduce and scrutinize decisions | Pre-deployment and retrospective | Global, local samples, rules, traceability | Provenance, completeness, reproducibility | Selective disclosure | Independent access and audit authority | Auditor-facing explanation |
Regulator, where supported | Assess whether claims and controls are substantiated | Pre-deployment or investigation | Global, accountability-oriented, causal where valid | Scope clarity, evidence quality, uncertainty | Explanation treated as legal sufficiency | Independent technical assessment | Accountability-oriented explanation |
Compliance actor, where supported | Connect system behaviour with internal controls | Pre-deployment and monitoring | Global, documentation-linked, rule-based | Traceability and coverage | Checklist compliance without validation | Control testing and escalation | Oversight-oriented explanation |
Human overseer | Know when and how to intervene | During decision or operation | Local, dynamic, uncertainty-aware, interactive | Timeliness and actionability | Nominal oversight without control | Override usability and authority testing | Oversight-oriented explanation |
Accountability actor | Determine roles, evidence, and responsibility | Post-event | Traceability, global/local evidence, causal where justified | Provenance and role clarity | Responsibility displaced onto the interface | Responsibility mapping and record retention | Accountability-oriented explanation |
High-stakes decision user | Verify consequential advice under uncertainty | Before and during decision | Interpretable, local, uncertainty-aware, causal where validated | Robustness, domain validity, contestability | Serious harm from false reassurance | Independent validation and monitoring | Risk-sensitive explanation |
Low-stakes decision user | Obtain proportionate orientation | During decision | Concise local, example-based, natural-language | Relevance and efficiency | Disproportionate cognitive burden | Proportionate usability evaluation | Low-risk user-facing explanation |
Stakeholder-fit boundary | Avoid assigning one explanation solely by role | All moments | Multiple candidate types | Demonstrated contextual fit | Stereotyping and explanation mismatch | User-centered validation and choice | No stakeholder-fit guarantee boundary |
The proposed taxonomy begins with explanation purpose rather than method availability. It distinguishes system-scope explanations for general model behaviour from instance-scope explanations for particular outputs. Selection then proceeds through stakeholder role, decision timing, consequence, required cognitive accessibility, and the evidence needed to evaluate the explanation. Because explanation quality contains distinct properties, no single evaluation measure can represent fidelity, completeness, stability, plausibility, usefulness, and accessibility simultaneously [26].
A second axis differentiates reasoning functions. Actionability-oriented explanations describe possible changes; reasoning-oriented explanations answer contrastive questions; causality-oriented explanations address mechanisms under justified assumptions; similarity-oriented explanations use cases or prototypes; and rule-oriented explanations express conditional logic. Interaction-oriented and adaptation-oriented explanations describe how explanatory content is explored or tailored. Human-centered evaluation remains necessary because explanation effects depend on the task, interface, user, and study context [27].
A third axis concerns stakeholder and risk orientation. Developer-facing explanations prioritize diagnosis and reproducibility, user-facing explanations prioritize accessible decision support, affected-person explanations prioritize reasons and challenge, and auditor-facing explanations prioritize traceability and reproducibility. Risk-sensitive explanations require stronger evidence where consequences are substantial. In high-stakes domains, technical truthfulness, human plausibility, relevance, and understandability should be assessed separately rather than collapsed into apparent usefulness [28].
A fourth axis covers accountability, contestability, and oversight. Accountability-oriented explanations connect evidence with responsible actors and controls; contestability-oriented explanations support informed challenge; and oversight-oriented explanations support monitoring, escalation, and human intervention. Explainability may contribute to trustworthy AI, but it is only one component among broader requirements concerning robustness, fairness, governance, safety, and human control [29]. The taxonomy therefore organizes explanation requirements without claiming that explanation establishes trustworthy operation.
The categories are connected rather than mutually exclusive. A local counterfactual can be instance-scope, actionability-oriented, affected-person-facing, and contestability-oriented at the same time. More explanation is not always better because comprehensibility, completeness, confidentiality, confidence, and responsible conduct can create competing design pressures [30]. Trust also depends on user, task, system, and relational conditions beyond explanation type [31]. Table 4 presents the proposed stakeholder-oriented explainability taxonomy linking explanation categories, explanation types, stakeholder fit, decision timing, evaluation requirements, failure risks, and boundary statements.
Table 4. Proposed Stakeholder-Oriented Explainability Taxonomy: System-Scope, Instance-Scope, Actionability-Oriented, Reasoning-Oriented, Causality-Oriented, Similarity-Oriented, Rule-Oriented, Interaction-Oriented, Adaptation-Oriented, Accountability-Oriented, Contestability-Oriented, Oversight-Oriented, Developer-Facing, User-Facing, Affected-Person, Auditor-Facing, and Risk-Sensitive Explanations
Taxonomy category | Core purpose | Explanation types included | Primary stakeholder fit | Decision timing | Evaluation requirement | Failure risk | Boundary statement |
System-scope | Describe general model behaviour | Global summaries, transparent models, surrogates, rules | Developer, auditor, manager, expert | Development, pre-deployment, monitoring | Fidelity, coverage, stability | Aggregation hides local failures | Does not prove an individual decision appropriate |
Instance-scope | Explain a particular output | Local attribution, saliency, local rule, example | Affected person, decision maker, operator | During or post-decision | Local fidelity, relevance, stability | Case explanation generalized system-wide | Does not establish global safety or fairness |
Actionability-oriented | Identify possible next steps | Counterfactual, actionable, recourse-oriented | Affected person, operator | Post-decision and planning | Feasibility, cost, robustness | Impossible or ineffective change | Does not guarantee recourse |
Reasoning-oriented | Explain why one outcome rather than another | Contrastive, rule-based, natural-language | Lay user, expert, auditor | During or post-decision | Foil relevance, fidelity, completeness | Wrong explanatory question answered | Requires question-specific validation |
Causality-oriented | Describe mechanisms or interventions | Causal pathways, structural counterfactuals | Expert, auditor, accountability actor | Planning and retrospective analysis | Identification, assumptions, uncertainty | Correlation presented as causation | Does not guarantee causal truth |
Similarity-oriented | Explain through comparable instances | Examples, cases, prototypes, neighbours | Lay user, expert, decision maker | During or post-decision | Representativeness and similarity validity | Biased or cherry-picked examples | Similarity does not establish causation |
Rule-oriented | Communicate conditional logic | Intrinsic rules, extracted rules, local rules | Expert, operator, auditor, affected person | Development, decision, audit | Fidelity, coverage, complexity | False impression of determinism | Extracted rules remain approximations |
Interaction-oriented | Support questioning and exploration | Interactive, conversational, dialogue-based | End user, expert, operator | During or post-decision | Coherence, turn fidelity, task success | Inconsistency or overload | Interactivity does not guarantee understanding |
Adaptation-oriented | Adjust content, detail, or modality | Adaptive, personalized, layered, dynamic | Mixed-expertise users | All moments | Fairness, privacy, user control | Stereotyping or hidden omission | Personalization does not guarantee fit |
Accountability-oriented | Connect decisions with evidence and responsibility | Traceability, documentation, causal where justified | Auditor, manager, accountability actor | Pre-deployment and retrospective | Provenance, completeness, reproducibility | Explanation substitutes for governance | Does not establish accountability alone |
Contestability-oriented | Enable informed challenge and correction | Local, contrastive, counterfactual, evidence-linked | Affected person, reviewer | Post-decision | Accessibility and review effectiveness | Information without remedy | Does not create contestability alone |
Oversight-oriented | Support monitoring and intervention | Dynamic, uncertainty-aware, global/local diagnostics | Operator, overseer, manager | During operation | Timeliness and override usability | Nominal oversight | Human control must be operational |
Developer-facing | Diagnose model and data behaviour | Attribution, saliency, global, local, surrogate | Developer, model builder | Development and monitoring | Technical correctness and reproducibility | Confirmation bias | Developer interpretability is not user comprehension |
User-facing | Support informed system use | Local, example-based, natural-language, interactive | End user, decision maker | During or post-decision | Accessibility, usefulness, uncertainty | Persuasion without verification | Satisfaction does not prove fidelity |
Affected-person | Support understanding, challenge, and response | Local, contrastive, counterfactual, recourse-oriented | Decision subject, affected individual | Post-decision | Case relevance and procedural accessibility | Illusory recourse | Does not ensure remedy |
Auditor-facing | Support independent scrutiny | Global, local samples, traceability, documentation | Auditor, compliance actor | Pre-deployment and retrospective | Access, reproducibility, versioning | Selective evidence | Auditability requires authority and access |
Risk-sensitive | Scale evidence to consequence | Interpretable, uncertainty-aware, causal where valid | High-stakes user and overseer | Pre-, during-, and post-decision | Domain validity, robustness, monitoring | Persuasive explanation masks risk | Explanation does not prove readiness |
Explanation-type sufficiency boundary | Prevent universal method claims | All types | All stakeholders | All moments | Cross-method contextual evaluation | Method-centric overclaiming | No type independently proves trustworthiness |
Stakeholder-fit boundary | Prevent deterministic role matching | All types | All stakeholders | All moments | Empirical fit testing and user choice | Role stereotyping | Role alone is not a sufficient selector |
Deployment-readiness boundary | Separate taxonomy from operational approval | All types | Developer, manager, auditor, operator | Pre-deployment | System, human, domain, and governance evidence | Conceptual classification treated as certification | The taxonomy does not certify deployment readiness |
Figure 1 presents the proposed stakeholder-oriented explainability taxonomy, linking explanation types, stakeholder roles, decision timing, explanation purpose, evaluation requirements, failure risks, and boundary conditions.
Figure 1. Stakeholder-Oriented Taxonomy of Explainable AI Explanation Types
A conceptual taxonomy showing explanation types connected to stakeholder roles, decision timing, explanation purposes, quality criteria, evaluation needs, failure risks, accountability, contestability, and boundaries against explanation sufficiency.
Explanation-type selection should begin by identifying the explanatory question, stakeholder, decision moment, consequence, and intended use. Designers should then compare candidate explanation families against purpose-relative quality requirements. Fidelity, stability, completeness, plausibility, accessibility, and usefulness should be treated as distinct properties rather than compressed into a universal explanation score [26]. Technical evaluation should also disclose the explanation’s valid scope and assumptions.
Stakeholder-fit and decision-timing evaluation require user-centered testing in realistic workflows. Cognitive-accessibility testing should examine comprehension, error detection, cognitive load, and the ability to identify uncertainty. Explanation-usefulness testing should assess whether the account supports the intended task rather than merely increasing satisfaction. Human-centered studies remain necessary because explanation outcomes vary across users, domains, interfaces, and decision conditions [27].
Trust-calibration evaluation should assess whether confidence and reliance track system capability. Reliance monitoring can examine when users accept, reject, verify, or override AI advice, especially when the system is wrong. Actionability assessment should test feasibility, accessibility, cost, and robustness, while recourse evaluation should determine whether proposed actions can affect the real institutional process. Contestability further requires an accessible review route, authority to reconsider the decision, and a mechanism for correction.
Accountability mapping should connect explanations with data provenance, system versions, responsible actors, review authority, documentation, escalation, and human control. Uncertainty communication and explanation-failure detection should cover instability, inconsistency, causal ambiguity, and misleading fluency. Adaptive-explanation governance should include privacy, fairness, user inspection, and override controls because contextualization can create both benefits and adverse effects [30]. These are conceptual research and design implications, not legal, compliance, certification, procurement, platform-selection, model-selection, or deployment instructions.
This article proposes a stakeholder-oriented explainability taxonomy linking global, local, counterfactual, contrastive, causal, example-based, rule-based, interactive, and adaptive explanations with stakeholder roles, decision timing, explanatory purpose, quality requirements, evaluation needs, contestability, accountability, and explicit boundary conditions. Its central premise is that explanation selection should begin with the stakeholder’s question, responsibility, expertise, decision context, cognitive needs, potential for action, reliance risk, and accountability requirements rather than with method availability alone. The taxonomy can organize design choices and clarify evaluation responsibilities, but it does not independently prove understanding, fairness, causal truth, recourse, trustworthiness, legal sufficiency, accountability, or deployment readiness. Explanation selection therefore remains a context-sensitive design and evaluation problem requiring technical validation, user-centered assessment, domain evidence, uncertainty communication, governance mechanisms, and meaningful human control.
None
None
None
None
Open Access The author(s) retain copyright. This article is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. It may be shared and adapted for non-commercial purposes with appropriate attribution, an indication of changes, and distribution of adaptations under the same license. Third-party material may be subject to separate terms identified in its credit line. View the license at https://creativecommons.org/licenses/by-nc-sa/4.0/.
Transparent Intelligence Publishing
