Artificial intelligence is increasingly embedded in smart farming systems, yet explanation requirements are often treated as a single technical attribute rather than as stakeholder-dependent needs. This article develops a conceptual taxonomy of explainability requirements across agricultural decision contexts. The taxonomy approach distinguishes stakeholders by their roles, decision consequences, explanation purposes, required explanation objects, usability expectations, accountability needs, trust risks, and implementation boundaries. Farmers may require accessible, locally relevant, actionable, and uncertainty-aware explanations that preserve autonomy. Agronomists and advisors may require model logic, input relevance, data-quality information, output rationale, limitations, and evidence supporting professional validation. Regulatory stakeholders may require traceability, documentation, auditability, risk justification, and clear responsibility allocation. Platform providers, technology providers, data intermediaries, system operators, and data stewards may require lifecycle transparency, monitoring information, provenance records, version histories, and incident reconstruction. Supply-chain and sustainability actors may require interpretable provenance and decision boundaries without treating explanation as proof of quality, sustainability, or compliance. The taxonomy also identifies failures including under-explanation, over-explanation, misleading explanations, uncertainty omission, explanation overload, false confidence, provenance opacity, accountability gaps, and trust miscalibration. Its main contribution is a structured account of how explanation requirements change across stakeholders and decision settings. The taxonomy is conceptual and requires stakeholder validation, usability testing, governance assessment, and domain-specific evaluation before operational application.
Artificial intelligence applications in smart farming increasingly support crop monitoring, yield estimation, disease detection, irrigation management, soil assessment, livestock monitoring, and farm decision support. Their value cannot be assessed only through predictive accuracy because users may also need to understand influential inputs, output rationales, limitations, and uncertainty. Agricultural explainability therefore concerns how model behaviour and analytical results can be interpreted within domain-specific decisions rather than merely whether a visual explanation can be generated [1].
Explainability is related to, but distinct from, interpretability, transparency, accountability, auditability, and traceability. Interpretability generally concerns the extent to which model behaviour can be understood, whereas explanation may involve an account produced for a particular question or user. Transparency may describe visibility into data, models, processes, or institutional practices, while accountability concerns responsibility, answerability, and remedy. Treating these concepts as interchangeable obscures the different evidential and governance functions expected from smart farming AI systems [2].
A stakeholder-specific approach is necessary because explanation users do not ask identical questions. Farmers may ask whether an output is relevant to their land, production conditions, available resources, and immediate choices. Agronomists may examine whether model relationships are technically and agronomically plausible. Regulatory or accountability stakeholders may require documentation, traceability, and risk justification, while platform operators may need monitoring and incident information. Explanation requirements consequently vary with stakeholder role, objective, expertise, decision context, and potential consequence [3].
This article develops an original conceptual taxonomy that classifies explainability requirements according to stakeholder group, explanation purpose, decision setting, explanation object, usability need, accountability function, trust risk, evaluation requirement, and claim boundary. The taxonomy treats smart farming AI as a socio-technical system in which risks can arise from datasets, modelling choices, platform structures, institutional practices, deployment conditions, and downstream externalities [4]. It is intended to organize design and research questions, not to establish empirical validity, legal sufficiency, stakeholder approval, sustainability verification, or deployment readiness.
Smart farming AI operates within data ecosystems linking sensors, farm-management systems, analytical services, machinery, advisory actors, technology providers, platforms, and downstream value-chain organizations. Explanation may therefore concern more than an individual prediction. Users may need to understand where data originated, how they were transformed, which model version was applied, why an output was produced, and how that output entered a broader decision process. These system relationships make data and institutional explanations as important as model-level interpretation [5].
The social setting of digital agriculture also shapes what counts as an adequate explanation. Unequal digital access, technical capability, bargaining power, infrastructure, and participation can determine whether an explanation is understandable or usable. An interface may be technically sophisticated while remaining inaccessible to farmers with limited connectivity, time, or specialist knowledge. Explainability must therefore be considered within wider questions of inclusion, autonomy, institutional responsibility, and the distribution of benefits and risks [6].
At the technical level, explanation objects include data inputs, provenance, data quality, model logic, feature relevance, output rationale, confidence, uncertainty, and limitations. Data explanations may identify missing observations, sensor coverage, temporal relevance, or processing steps. Model explanations may describe learned relationships or decision structures. Output explanations may address a particular recommendation or alert. These forms remain dependent on the quality, integration, and lifecycle management of agricultural data, and an explanation cannot repair incomplete or unrepresentative inputs [7].
Explainability should consequently be treated as a configurable requirement rather than a universal feature. A feature-contribution display may support analytical examination but may not answer a farmer’s practical question or a platform operator’s incident-investigation need. Explainable analyses can also help identify factors associated with technology requirements or readiness, but such associations do not prove causality, usefulness, adoption, or acceptance. Explanation design must therefore specify its intended user, purpose, context, and evaluation standard [8].
Farmers are both data contributors and decision stakeholders, and their explanation needs often extend beyond model mechanics. They may need clarity regarding why data are collected, who can access them, how outputs are generated, which limitations apply, and how benefits or risks are distributed. Trust concerns can arise when systems provide recommendations without explaining data use, commercial relationships, or opportunities for challenge and recourse. Clear explanations may support informed engagement, but they cannot independently establish warranted trust [9].
Agronomists, advisors, and cooperative or knowledge-network actors frequently interpret digital information between technical systems and farm decisions. Their requirements may include data-quality indicators, feature relevance, output rationale, uncertainty, alternatives, and escalation conditions. Responsible explanation design must also consider farmer autonomy, privacy, consent, power asymmetries, and the possibility that transparent information may still be embedded in an unfair or weakly accountable arrangement [10].
Platform providers, technology developers, model developers, data intermediaries, data stewards, and system operators require different levels of technical and operational visibility. Developers may need model diagnostics and failure cases; data stewards may require provenance and quality records; operators may need logs, versions, thresholds, overrides, and incident histories. Agricultural advisors and knowledge networks additionally require explanation formats that can be translated into locally meaningful discussion rather than transmitted as decontextualized technical output [11].
Regulatory stakeholders, supply-chain organizations, sustainability actors, and other explanation users may require evidence linking decisions to data, models, documentation, responsible actors, and review procedures. Their questions concern accountability and traceability rather than merely user comprehension. Because responsibility is distributed across research, development, implementation, operation, and downstream use, no single explanation can satisfy every stakeholder or resolve every responsibility gap [12]. Table 1 summarises stakeholder-specific explanation needs in smart farming AI systems.
Table 1. Stakeholder-Specific Explanation Needs in Smart Farming AI Systems: Farmers, Agronomists, Advisors, Regulatory Stakeholders, Platform Providers, Technology Providers, Data Intermediaries, Cooperatives, Supply-Chain Stakeholders, Sustainability Actors, Data Stewards, Model Developers, System Operators, and Explanation Users
Stakeholder group | Core explanation question | Decision context | Explanation needed | Potential use | Failure or misuse risk | Evaluation need | Taxonomy role |
Farmers | Why is this output relevant to my farm? | Operational farm decisions | Local rationale, uncertainty, limitations, and data-quality cues | Support deliberation and questions | Generic advice, false confidence, or reduced autonomy | Comprehension, accessibility, local relevance, and trust calibration | Primary farmer-facing user |
Agronomists | Which inputs and relationships produced the result? | Technical and agronomic validation | Model logic, feature relevance, uncertainty, and validation evidence | Examine agronomic plausibility | Correlation interpreted as causation | Fidelity, robustness, and agronomic review | Expert validator |
Agricultural advisors | How should the output be interpreted in this case? | Farmer–advisor decision support | Contextual rationale, alternatives, caveats, and escalation conditions | Mediate between system and farmer | Oversimplification or uncritical transmission | Workflow usability and contextual usefulness | Human intermediary |
Regulatory stakeholders | Can the system and its risks be examined? | Oversight or investigation | Documentation, traceability, audit records, risk rationale, and responsibility allocation | Support structured review | Explanation treated as proof of compliance | Independent technical and governance assessment | Oversight user |
Platform providers | What occurs across models, data flows, users, and incidents? | Platform operation | Architecture, monitoring, versions, data lineage, and incident information | Coordinate lifecycle monitoring | Selective disclosure or dashboard theatre | Monitoring validity and incident reconstruction | System-level operator |
Technology providers | What does the system do and where can it fail? | Design, integration, and support | Intended use, input requirements, limitations, updates, and uncertainty | Improve design and communicate scope | Promotional explanation or hidden limitations | Verification and stakeholder testing | Technical explanation producer |
Data intermediaries | Where did data originate and how were they transformed? | Data aggregation and exchange | Provenance, permissions, quality, transformations, and access conditions | Support responsible exchange and error tracing | Lost provenance or opaque secondary use | Lineage and access review | Data-provenance actor |
Cooperatives | How can shared systems remain understandable to members? | Collective services and procurement | Shared-data arrangements, service logic, risks, and recourse | Support collective deliberation | Unequal participation or centralized authority | Member accessibility and governance review | Collective intermediary |
Supply-chain stakeholders | How did AI-supported evidence enter a downstream decision? | Sourcing, logistics, or quality interpretation | Provenance, transformations, uncertainty, and decision boundaries | Examine evidence flow | Traceability treated as proof of quality | Chain-of-custody and purpose-specific validation | Downstream explanation user |
Sustainability actors | What indicator is being interpreted and within which boundary? | Environmental or social interpretation | Metric definition, assumptions, provenance, uncertainty, and exclusions | Support cautious interpretation | Unsupported sustainability claims | Indicator validation and independent verification | Sustainability-interpretation user |
Data stewards | Are data definitions, quality controls, and permissions documented? | Dataset governance | Metadata, lineage, quality, access, retention, and processing records | Maintain reproducibility and accountability | Undocumented changes or privacy leakage | Dataset audit and governance review | Data custodian |
Model developers | Which model behaviour must be visible to users? | Training, testing, and maintenance | Feature effects, performance limits, failure cases, uncertainty, and versions | Design appropriate explanations | Optimizing for plausibility rather than fidelity | Fidelity, stability, and user-purpose alignment | Model-explanation producer |
System operators | What happened during a run, update, override, or failure? | Deployment and incident response | Logs, model version, data state, thresholds, overrides, and chronology | Diagnose events | Missing records or retrospective rationalization | Logging and incident-response testing | Operational accountability actor |
Explanation users | Does the explanation answer my actual question? | Any AI-supported interaction | Role-appropriate content, format, detail, uncertainty, and limitations | Understand, challenge, or deliberate | Overload, mismatch, or inaccessibility | Comprehension, usefulness, fidelity, and contextual evaluation | Cross-cutting user category |
Farmer-facing explanations should be accessible, locally relevant, and connected to the decision under consideration. They should clarify why an output was generated, which farm or environmental inputs influenced it, what uncertainty remains, and when the system should not be relied upon. Agricultural advisors can help translate digital outputs into farm-specific discussion, identify exceptions, and support escalation to specialist judgment. However, human involvement is meaningful only when advisors and farmers have sufficient authority, knowledge, time, and access to challenge the system [13].
Actionability should not be confused with prescription. A useful explanation may identify the decision to which an output is relevant, the conditions under which it applies, and the alternatives that warrant consideration without directing a specific management action. Farmer autonomy requires the ability to question, disregard, or seek alternatives to an AI-supported suggestion. Explanation formats must also account for language, literacy, connectivity, workload, and unequal access, because technically transparent systems can remain socially inaccessible [14].
Agronomist-facing explanations generally require greater technical depth. Relevant elements include input definitions, data quality, feature effects, model logic, output rationale, uncertainty, confidence calibration, limitations, and known failure conditions. Counterfactual explanations may show how model outputs change under different inputs, while example-based explanations may present comparable cases. Both require feasibility and domain review. Feature-importance outputs can expose influential variables in crop recommendations, but they do not establish causal relationships, field validity, or decision usefulness [15].
Trust calibration requires presenting capability and limitation together. Confidence values should be defined and evaluated for calibration rather than displayed as unqualified certainty. Uncertainty explanations should distinguish uncertainty arising from data, model assumptions, environmental variability, and unsupported conditions. Interpretable yield models can help agronomists examine relationships and identify dangers associated with opaque black-box conclusions, yet interpretability alone does not guarantee accurate inference or better farm decisions [16]. Farmer-facing clarity, agronomist validation, advisor mediation, data-quality assessment, and human oversight must therefore be evaluated separately, with an explicit no-trust-guarantee and no-decision-quality-guarantee boundary.
Regulatory and accountability stakeholders require explanations that permit examination rather than merely improve interface comprehension. Relevant materials include model purpose, data sources, intended use, limitations, uncertainty, version history, decision boundaries, and responsibility allocation. Data explanations should also clarify ownership, access, reuse, privacy, and sharing conditions because unclear governance can discourage farmer participation and weaken accountability [17].
Platform and technology providers require system-level explanations covering data pipelines, model dependencies, updates, monitoring indicators, failures, overrides, and incident histories. These requirements extend beyond a single prediction because digital-agriculture services are shaped by interacting suppliers, platforms, infrastructure providers, and intermediaries. Platform transparency should therefore identify organizational responsibilities as well as technical processes [18].
Supply-chain and sustainability explanations must account for power, access, labor, and control over agricultural information. Provenance records may show where data originated and how they moved, but they do not establish whether data practices were equitable or whether downstream interpretations were valid. Explanation design should therefore expose relevant decision boundaries and institutional relationships rather than presenting technical visibility as complete accountability [19].
Traceability and auditability can connect outputs to data, model versions, system events, and responsible actors. Blockchain-supported records and XAI have been proposed as complementary approaches for smart-agriculture security and decision interpretation, but their integration remains a research prospect rather than verified governance infrastructure [20]. Supply-chain explanation cannot independently prove product quality, sustainability performance, legal compliance, or responsible practice.
Post-hoc explanations may appear understandable while failing to represent the reasoning of a complex model. This risk becomes important when outputs could influence consequential farm, environmental, financial, or supply-chain decisions. In such contexts, inherently interpretable models may sometimes provide stronger examination possibilities, although model choice must still reflect performance, data, consequence, and domain requirements [21].
Misleading explanations can arise from unstable feature attributions, selective examples, implausible counterfactuals, or persuasive narratives unsupported by model behaviour. Similar concerns in other high-stakes domains show that plausible explanations can generate false confidence without providing dependable understanding [22]. Agricultural systems therefore require explanation-fidelity testing and domain review rather than relying on visual plausibility.
Trust can also be miscalibrated. Over-explanation may create authority through technical detail, while under-explanation may conceal uncertainty or limitations. Explanation overload, inaccessible terminology, and mismatched information can produce confusion or unwarranted rejection. Explainability may affect trust and acceptance, but perceived clarity does not establish warranted reliance or system trustworthiness [23].
Evaluation should match the stakeholder, question, explanation object, and decision consequence. Farmers may require comprehension and local-usefulness testing; agronomists may require fidelity and plausibility assessment; regulators may require documentation and auditability; operators may require incident reconstruction. A multidisciplinary evaluation framework is therefore necessary to identify explanation mismatch, accountability gaps, and residual risks [24]. Table 2 maps explainability requirements, governance requirements, failures, and trust risks across smart farming AI stakeholders.
Table 2. Explainability Requirements, Governance Requirements, Failures, and Trust Risks in Smart Farming AI Systems: Farmer-Facing Explanations, Agronomist Validation, Regulatory Review, Platform Monitoring, Supply-Chain Transparency, Data Provenance, Auditability, Uncertainty, Explanation Mismatch, False Confidence, and Trust Calibration
Requirement or risk domain | Core question | Required explanation or documentation | Affected stakeholder | Potential output | Failure or trust risk | Evaluation or oversight need | Boundary statement |
Farmer-facing explanation | Why is this relevant locally? | Plain-language rationale, uncertainty, limits | Farmers | Contextual explanation | Generic advice or overreliance | Comprehension and local testing | Does not guarantee trust |
Agronomist validation | Is the result plausible? | Inputs, model logic, feature effects, limitations | Agronomists | Technical diagnostic | Causal misinterpretation | Fidelity and agronomic review | Does not replace field evidence |
Advisor mediation | How should this be discussed? | Alternatives, caveats, escalation conditions | Advisors | Layered explanation | Uncritical transmission | Workflow evaluation | Does not transfer all responsibility |
Regulatory review | Can evidence and risk be examined? | Documentation, traceability, risk rationale | Regulatory stakeholders | Review dossier | Explanation treated as compliance proof | Independent assessment | Does not establish compliance |
Platform monitoring | What changed or failed? | Versions, logs, drift, incidents, overrides | Platforms and operators | Monitoring record | Selective disclosure | Lifecycle and incident review | Monitoring does not prove safety |
Data provenance | Where did data originate? | Source, custody, processing, permissions | Data stewards and intermediaries | Provenance chain | Hidden transformation | Lineage audit | Provenance does not prove accuracy |
Supply-chain transparency | How did evidence enter a decision? | Chain of custody, transformations, uncertainty | Supply-chain actors | Traceable decision record | Traceability treated as truth | Cross-party verification | Does not prove quality |
Sustainability interpretation | What indicator and boundary apply? | Assumptions, exclusions, provenance, uncertainty | Sustainability actors | Indicator explanation | Unsupported environmental claim | Independent verification | Does not certify sustainability |
Uncertainty omission | What uncertainty is absent? | Data, model, contextual, and prediction uncertainty | All users | Calibrated warning | False certainty | Calibration testing | Uncertainty cannot be eliminated |
Feature misinterpretation | Is importance being read causally? | Method limits and stability information | Farmers and agronomists | Feature-effect summary | Association treated as causation | Sensitivity review | Does not establish causality |
Explanation mismatch | Does it answer the user’s question? | Role-appropriate content and detail | All explanation users | Layered interface content | Irrelevance or confusion | Stakeholder testing | No universal explanation |
Explanation overload | Is detail obstructing use? | Prioritized and layered information | Farmers, advisors, regulators | Tiered explanation | Cognitive burden | Workload and usability testing | More detail is not always better |
False confidence | Does clarity exceed reliability? | Capability, limitation, and calibration evidence | All users | Balanced reliability statement | Trust overcalibration | Behavioural evaluation | Clarity does not prove correctness |
Accountability gap | Who must respond or remedy harm? | Role allocation, handoffs, escalation, recourse | Providers, platforms, operators, users | Responsibility map | Blame shifting | Governance assessment | Transparency alone is insufficient |
Auditability gap | Can events be reconstructed? | Logs, versions, thresholds, overrides | Regulators and operators | Audit trail | Missing or unusable evidence | Independent audit design | Auditability does not ensure accountability |
Deployment-readiness boundary | Has operational suitability been demonstrated? | Validation, usability, safety, and governance evidence | All stakeholders | Readiness evidence plan | Premature implementation | Context-specific evaluation | Taxonomy is not deployment evidence |
The proposed taxonomy begins with the explanation user and the question being asked. Human explanations are commonly selective, contrastive, social, and context-sensitive, so an explanation should identify why an output occurred, why it differed from an alternative, and which information matters in the present decision [25]. This stakeholder-first principle prevents technical outputs from being assumed universally useful.
The second dimension concerns the explanation object. Data explanations address inputs, provenance, transformations, and quality; model explanations address structure or learned relationships; output explanations address particular predictions or recommendations. Counterfactual, example-based, rule-based, and feature-based methods describe different forms and scopes of explanation rather than interchangeable solutions [26].
The third dimension concerns explanation function and presentation. An explanation may support farmer deliberation, agronomist validation, regulatory review, platform monitoring, traceability, accountability planning, or trust calibration. Methods vary in fidelity, comprehensibility, scalability, and technical assumptions, so their limitations must accompany their outputs [27]. A method should be selected by purpose and evaluation need rather than popularity.
The fourth dimension maps stakeholder roles to responsibilities. Farmers, agronomists, advisors, developers, providers, operators, data stewards, regulators, and downstream actors require different explanation depth, timing, access, and documentation. Stakeholder role and explanation objective are therefore core taxonomy dimensions, while conflicting objectives should be documented rather than concealed [28].
The fifth dimension defines evaluation and claim boundaries. Every category requires a specified notion of explainability and an evaluation approach aligned with that claim [29]. Evaluation may concern fidelity, comprehension, usability, accessibility, uncertainty calibration, agronomic plausibility, auditability, or governance adequacy. Table 3 presents the proposed taxonomy of explainability requirements in smart farming AI systems.
Table 3. Proposed Taxonomy of Explainability Requirements in Smart Farming AI Systems: Data Explanation, Model Explanation, Output Explanation, Uncertainty Explanation, Limitation Explanation, Decision-Context Explanation, Risk-Level Explanation, Actionability, Traceability, Auditability, Accountability, Stakeholder-Specific Explanations, Trust Calibration, and Claim Boundaries
Taxonomy category | Core purpose | Stakeholder primary user | Required explanation object | Explanation function | Potential output | Failure risk | Evaluation need | Boundary statement |
Data explanation | Clarify system inputs | Farmers, agronomists, stewards | Definitions, coverage, processing | Support data understanding | Input summary | Hidden deficiencies | Completeness and clarity | Does not prove accuracy |
Data provenance and quality | Show origin and reliability limits | Stewards, regulators, supply chains | Source, lineage, quality, permissions | Support tracing and review | Provenance record | Broken lineage | Lineage and quality audit | Does not validate downstream claims |
Model explanation | Expose model behaviour | Agronomists, developers, regulators | Structure, relationships, assumptions | Support technical examination | Model-behaviour account | Unfaithful interpretation | Fidelity and stability | Does not validate the model |
Output explanation | Explain a specific result | Farmers, advisors, agronomists | Prediction, alert, or recommendation | Support case interpretation | Local rationale | Plausible but incorrect account | Fidelity and comprehension | Does not prove correctness |
Uncertainty and confidence | Communicate reliability limits | All decision users | Prediction and uncertainty sources | Calibrate reliance | Range, probability, warning | False certainty | Calibration and communication | Does not eliminate uncertainty |
Limitation explanation | Define unsupported use | All stakeholders | Scope, exclusions, failures | Prevent misuse | Limitation statement | Hidden or vague limits | Salience and coverage | Disclosure does not ensure safety |
Decision-context explanation | Link output to context | Farmers and advisors | Farm conditions, timing, alternatives | Support contextual deliberation | Context layer | Generic advice | Local relevance testing | Does not prescribe action |
Risk-level explanation | Clarify consequence and oversight | Regulators, platforms, operators | Exposure, reversibility, affected parties | Support proportional review | Risk rationale | Unsupported classification | Independent assessment | Is not certification |
Actionability explanation | Clarify what decision may be informed | Farmers and advisors | Options, conditions, triggers | Connect output to deliberation | Decision options | Prescription disguised as explanation | Scenario evaluation | Is not agronomic advice |
Traceability explanation | Connect data, models, events, and actors | Regulators, platforms, supply chains | Lifecycle lineage | Support reconstruction | Trace record | Incomplete chain | Integrity testing | Does not establish truth |
Auditability explanation | Make evidence reviewable | Regulators and platforms | Logs, versions, thresholds, overrides | Support scrutiny | Audit package | Unusable records | Reproducibility and access review | Does not ensure accountability |
Accountability and oversight | Clarify responsibility and intervention | All affected actors | Roles, handoffs, escalation, remedy | Prevent responsibility gaps | Accountability map | Blame displacement | Governance review | Transparency alone is insufficient |
Farmer-facing explanation | Support accessible deliberation | Farmers | Rationale, uncertainty, limitations | Promote informed engagement | Plain-language layer | Paternalism or overload | Accessibility and local testing | Does not guarantee adoption |
Agronomist- and advisor-facing explanation | Support validation and mediation | Agronomists and advisors | Logic, data quality, alternatives, limits | Enable expert review | Technical and contextual layers | Causal or authority errors | Agronomic and workflow testing | Does not guarantee decision quality |
Regulatory and platform explanation | Support oversight and lifecycle control | Regulators, providers, operators | Documentation, monitoring, incidents | Enable review and response | Evidence dossier | Compliance or safety overclaim | Independent technical review | Does not establish approval |
Supply-chain and sustainability explanation | Clarify downstream interpretation | Supply-chain and sustainability actors | Provenance, boundaries, assumptions | Support cautious scrutiny | Evidence narrative | Quality or green claim overreach | Cross-party verification | Does not verify sustainability |
Trust-calibration explanation | Bound reliance | All users | Capability, evidence, uncertainty, limits | Prevent overtrust or undertrust | Balanced trust statement | Persuasive explanation | Behavioural evaluation | Explainability is not trustworthiness |
Claim boundaries | Prevent conceptual overreach | All stakeholders | Trust, compliance, sustainability, readiness limits | Constrain interpretation | Explicit boundary statements | Premature implementation | Stakeholder and governance validation | No trust, compliance, sustainability, or readiness guarantee |
Figure 1 presents the proposed taxonomy of explainability requirements in smart farming AI systems, linking stakeholder groups, explanation objects, explanation functions, trust risks, governance needs, and decision boundaries.
Figure 1. Taxonomy of Explainability Requirements in Smart Farming AI Systems
Alt-text description: A conceptual taxonomy showing smart farming AI stakeholders connected to data, model, output, uncertainty, limitation, decision-context, traceability, auditability, accountability, and trust-calibration explanation requirements.
For farmers, agronomists, and advisors, future work should test whether explanations answer real questions under local farm conditions. Evaluation should examine comprehension, accessibility, workload, uncertainty interpretation, autonomy, and the ability to challenge or disregard outputs. Longitudinal research is needed because immediate satisfaction does not show sustained usefulness, calibrated reliance, or improved decision quality.
For developers, platforms, data intermediaries, cooperatives, and system operators, the taxonomy can guide documentation and evaluation planning. Priorities include provenance, data quality, version histories, monitoring, override records, incident reconstruction, privacy, and responsibility allocation. These elements require organizational governance and independent assessment; they should not be reduced to interface features or disclosure checklists.
For regulatory, supply-chain, sustainability, research, and policy communities, future studies should compare explanation needs across decision consequences and institutional settings. Research should examine auditability, traceability, stakeholder conflict, power asymmetries, environmental-claim interpretation, and trust calibration. These are conceptual implications and research priorities, not legal, compliance, procurement, platform-selection, certification, agronomic, or deployment instructions.
This article contributes a stakeholder-specific taxonomy of explainability requirements in smart farming AI systems. It links farmers, agronomists, advisors, regulators, platforms, providers, data intermediaries, supply-chain actors, sustainability actors, developers, stewards, and operators to distinct explanation objects, functions, risks, evaluation needs, and accountability boundaries. The taxonomy shows that explainability should be assessed through stakeholder purpose, decision context, consequence, uncertainty, usability, traceability, auditability, trust calibration, and governance rather than through model transparency alone. It remains a conceptual classification requiring empirical, stakeholder, agronomic, usability, organizational, and governance evaluation before operational application.
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/.
Agro Intelligence Research Press
