IoXT: The Internet of Explainable Things
Why Explainability in IoT Requires a New System-Level Paradigm and Protocol Design

IoT has moved beyond isolated sensing toward distributed systems that sense, communicate, infer, decide, and act. A useful progression is

where the proposed Internet of Explainable Things (IoXT) denotes an architectural stage in which intelligent Things must also preserve the evidence required to explain their behaviour end to end.

There is already a substantial XAI-for-IoT literature (Kök et al., 2023; Jagatheesaperumal et al., 2022; Moss et al., 2025; Mohammad et al., 2025; Ambritta P. et al., 2024). IoXT does not replace model-level XAI. Methods such as LIME and SHAP can be used as examples of local explanation and feature attribution (Ribeiro et al., 2016; Lundberg and Lee, 2017); feature-importance methods can rank influential inputs (Altmann et al., 2010); and intrinsic models such as Self-Explaining Neural Networks (SENN) can expose concepts and relevance scores during prediction (Alvarez-Melis and Jaakkola, 2018). C-SENN illustrates how concept learning can be further differentiated in more complex environments (Sawada and Nakamura, 2022). These techniques can provide the model part of an IoXT explanation, but they do not by themselves establish which physical sensor produced the evidence, how that evidence travelled and changed, which contemporaneous model/policy state consumed it, or which actuator executed the resulting command.

That distinction is especially important in IoT because both the data and the communication of the data may be explanation-relevant. Cross-layer IoMT work shows that preserving packet-, application- and sensing-related semantics can reveal explanatory evidence lost by single-layer abstractions (Georgiades and Hussain, 2025). More broadly, provenance and distributed tracing research shows the value of retaining data origin, processing history and cross-component relationships (Hu et al., 2020; Lomotey et al., 2018; Fonseca et al., 2007); XAI-for-cyber-physical-systems research similarly recognizes that physical, sensing, control, safety and security context complicate explanation (Hoenig et al., 2024).

The systems challenge is reinforced by the broader IoT literature. IoT commonly joins sensors, informational processing and actuators so that informational failures can have physical consequences (Allhoff and Henschke, 2018). Ethical and legal work highlights pervasive sensing, cloud processing, actuation, transparency, privacy, safety, trust and accountability (Baldini et al., 2018; Tzafestas, 2018; Popescul and Georgescu, 2013; AboBakr and Azer, 2017; Berman and Cerf, 2017; Karale, 2021; Atlam and Wills, 2020; Wachter, 2018). Management and orchestration research adds identity, monitoring, configuration, fault handling, heterogeneous lifecycle state, service migration and edge–cloud coordination (Aboubakar et al., 2022; Sinche et al., 2020; Wen et al., 2017; Shahid et al., 2026). Governance research further emphasizes transparency, accountability, interoperability and oversight (Weber, 2013). Together, these strands motivate the core IoXT claim: if explainability is required across a distributed, time-varying sensing–intelligence–actuation path, it must be engineered into the architecture from the beginning.

Explainability-by-design research provides an important methodological precedent for building explanatory capability into systems rather than treating it only as a post-hoc activity (Huynh et al., 2022). Likewise, streaming-data research shows that model and data distributions can change over time, so explanations detached from the event-time system state can be misleading (Lu et al., 2019; Hu et al., 2024). IoXT therefore focuses on what must be captured while the system is operating.

The paper makes five contributions. First, it explains why IoT explainability is a system problem rather than only a model problem. Second, it defines a requirements- and design-principles-first IoXT architecture. Third, it formalizes end-to-end traceability, incident reconstruction, no-orphan actuation and measurable system properties. Fourth, it motivates XTP as a category of explanation-telemetry mechanisms without prescribing a single protocol. Fifth, it outlines assurance concepts and research questions for future standardization and domain-specific certification.

IoXT is deliberately requirements-first. The requirements state what a system must preserve; design principles guide how future architectures and standards should satisfy them.

Figure 1 places the common Sensors–Cloud/Intelligence–Actuators path in the horizontal plane. Four cross-cutting planes intersect the whole path: explainability; security and privacy; management and orchestration; and governance and compliance. Where actuator actions influence the environment, the feedback shown in the figure represents the next sensing cycle; it is a common cyber-physical case, not a requirement for every IoT deployment. The main architectural claim is not that these concerns are new individually. It is that explainability must be elevated to the same system-level status.

Within the intelligence stage, the model may use any suitable explanation mechanism. For example, LIME and SHAP can provide local explanations or feature attributions (Ribeiro et al., 2016; Lundberg and Lee, 2017); permutation feature importance can rank influential variables (Altmann et al., 2010); SENN can expose concepts and relevance scores intrinsically (Alvarez-Melis and Jaakkola, 2018); and C-SENN can encourage more differentiated concepts in complex environments (Sawada and Nakamura, 2022). IoXT does not prescribe one of these. It requires whichever explanation is produced to remain connected upstream to the sensor-derived evidence and communication path, and downstream to the decision, actuator execution and physical outcome.

The following definitions make the IoXT requirements measurable without fixing an implementation.

For a sensor, the minimum trace state includes identity, measurement time, calibration/configuration version, and quality/uncertainty where available. For an actuator, it includes identity, command/execution time, decision reference, local execution state and outcome. Gateways and intelligence components preserve the transformations and versioned state connecting the two ends.

If $s_{i}$ denotes a sensor entity or observation, the sensor observations that participated in the action path are

A reverse query should recover $\mathcal{S}(a_{t})$ together with timing, calibration, transformations, communication state, model/policy state, model-level explanation and actuator state.

Conversely, if sensor $s_{j}$ is later found faulty or compromised over interval $[t_{0},t_{1}]$, the forward impact set is

Equations (6) and (7) establish participation and reachability, not automatically legal or counterfactual causation. They provide the time-correct evidence on which causal, engineering or forensic analysis can operate.

For action $a_{t}$, let $\Gamma(a_{t})$ denote the required provenance links and $\Gamma^{\mathrm{obs}}(a_{t})$ the verified links available at audit time. Define trace completeness as

For a declared critical action, an IoXT conformance profile should require $C_{\mathrm{trace}}(a_{t})=1$ or an explicit degraded/non-conformant state. The intention is not indefinite retention of all raw sensor traffic; domain profiles may define the minimum evidence, summaries or cryptographic references that must be retained.

For the set $\mathcal{A}_{c}$ of critical actions, the orphan-actuation rate is

A mature critical deployment should target $R_{\mathrm{orphan}}=0$.

The need for protocol design follows from distribution: explanation state must cross devices, brokers, gateways, administrative domains and protocol boundaries. IoXT therefore uses Explainability Telemetry Protocol (XTP) as a category, not a fixed protocol. An XTP realization may be an extension to an existing IoT protocol, a profile standardizing trace metadata, a gateway-preservation rule set, a companion/sidecar channel, or a new lightweight protocol if existing mechanisms cannot efficiently carry the required semantics.

Let $\mathcal{F}_{\mathrm{req}}$ denote the required explanation semantics on a path, such as identity, event time, correlation, parentage, version/context and integrity. For protocol/gateway stage $k$, let $\mathcal{F}^{(k)}_{\mathrm{obs}}$ be the semantics available after the mapping. A simple semantic-preservation score is

For a critical trace, an XTP-capable gateway should either maintain $C_{\mathrm{sem}}^{(k)}=1$ for the required profile or explicitly report the missing semantics. Silent trace degradation is incompatible with explainability-by-design.

At minimum, an XTP-capable mechanism should support operations equivalent to: publish a timestamped explanation/provenance record; link an output to parent evidence; query by identity, trace or time; subscribe to live trace events; and preserve/attest an incident interval. The exact wire representation is deliberately left open.

Existing protocols offer design precedents without defining IoXT. SNMP demonstrates remotely addressable management state (Harrington et al., 2002); CoAP demonstrates resource-oriented communication and discovery for constrained devices (Shelby et al., 2014); and MQTT demonstrates lightweight publish–subscribe messaging for IoT/M2M contexts (Banks et al., 2019). IoXT abstracts the relevant properties – addressability, constrained operation, telemetry, query, subscription and gateway behaviour – while adding the explanation semantics required by the end-to-end cyber-physical trace.

A future conformance test should verify at least: addressable identity; timestamps and clock quality; calibration/configuration/model/policy version state; parent/input lineage; live export or reference of provenance; action-to-decision linkage; incident preservation; reverse and forward traversal; integrity and access control; and explicit reporting of incomplete traces. Equations (8)–(16) provide an initial measurable core.

Explainability cannot be isolated from the other cross-cutting planes in Fig. 1. An unprotected trace can be manipulated; an unrestricted trace can expose sensitive data; an unmanaged trace can become stale; and a trace without governance may be unusable for accountability.

A new term is justified only if it creates a useful research boundary. IoXT changes the unit of explanation from an isolated model to a cyber-physical trajectory; the evidence from only model inputs to both data and their communication/transformation history; the scope from one analytical layer to cross-layer relationships; the time of explanation from predominantly retrospective analysis to streaming and incident-time evidence; the network role from transporting model inputs to preserving explanation semantics; and the engineering status of explainability from an optional analytics component to a cross-cutting design property.

This distinction matters because IoT links informational behaviour to physical consequences. Existing XAI-for-IoT research remains foundational (Kök et al., 2023; Jagatheesaperumal et al., 2022; Moss et al., 2025; Mohammad et al., 2025); IoXT specifies the architectural conditions under which any model-level explanation can remain temporally correct, communication-aware, cross-layer, trackable, traceable and operationally useful across networked Things.

This paper introduced the Internet of Explainable Things (IoXT) as a system-level paradigm for explainability in intelligent IoT. The central observation is that IoT differs from many conventional XAI settings because evidence is often born in the physical world, communicated through heterogeneous layered networks, transformed by distributed computing, interpreted by AI and policy logic, and, in many high-consequence deployments, converted into actuator actions. The explanation problem therefore concerns both the data and the communication of the data, as well as the intelligence, decision and action. When an action changes the environment, subsequent readings can themselves be consequences of the earlier decision, making event-time traceability even more important.

IoXT consequently argues for explainability-by-design and cross-layer explainability. Relevant Things and events must be identifiable and addressable; observations, transformations, decisions, actions and outcomes must be timestamped and linked; compact evidence must be available during live operation; the system must support trace-back and trace-forward; and missing evidence must be explicit rather than silently ignored. XTP is proposed as a category of mechanisms that can carry these semantics rather than as a fixed protocol.

The defining IoXT requirement can be stated succinctly:

Every consequential intelligent IoT action should be explainable and traceable, at the time it occurs, back to the timestamped sensed evidence, communication/transformation history and contemporaneous system state that produced it; questionable source evidence should likewise be traceable forward to the decisions and physical actions it may have influenced.

This requirement is why IoXT is proposed not merely as XAI applied to IoT, but as a system-level paradigm, design discipline and protocol-design problem for trustworthy networked intelligence and cyber-physical action.