Paper deep dive
CRAFTER: Causality-based Self-adaptation for Autonomous IoT Systems
Houssam Hajj Hassan, Ajay Kattepur, Denis Conan, Georgios Bouloukakis
Intelligence
Status: not_run | Model: - | Prompt: - | Confidence: 0%
Entities (0)
Relation Signals (0)
No relation signals yet.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:This paper presents CRAFTER, an automated framework for designing and deploying self-adaptive IoT systems using Causal Reinforcement Learning (CRL). As IoT devices increasingly populate pervasive computing spaces, smart environments are enabled with advanced monitoring and interactive services. The dynamic nature of these environments, such as fluctuating workloads and evolving application demands, poses significant challenges in maintaining consistent Quality of Service (QoS) levels of IoT applications. While existing self-adaptation techniques offer adaptive capabilities, they are often designed to deal with specific application domains, hindering the design of self-adaptive solutions that can be re-used across multiple IoT verticals. In addition, there is a lack of automated pipelines that act on identifying key performance drivers to take effective adaptation decisions. CRAFTER addresses these issues by using Causality as a formal framework for performance analysis of IoT systems. CRAFTER generates causal graphs to uncover dependencies among system components and guide adaptation decisions based on cause-effect relationships. Then, adaptation agents can leverage this knowledge to take more effective adaptation decisions in dynamic situations. Our experimental evaluation demonstrates how CRAFTER enables deriving causal graphs spanning diverse IoT use cases. Furthermore, we showcase how CRAFTER improves self-adaptation performance by 25% compared to state-of-the-art Reinforcement Learning-based approaches.
Tags
Links
- Source: https://arxiv.org/abs/2610.06320v1
- Canonical: https://arxiv.org/abs/2610.06320v1
Trouble viewing inline? Open PDF directly →
Full Text
78,970 characters extracted from source content.
Expand or collapse full text
CRAFTER: Causality-based Self-Adaptation for Autonomous IoT Systems Houssam Hajj Hassan houssam.hajj_hassan@telecom-sudparis.eu Télécom SudParis, Institut Polytechnique de Paris France Ajay Kattepur ajay.kattepur@ericsson.com Ericsson Research Artificial Intelligence India Denis Conan denis.conan@telecom-sudparis.eu Télécom SudParis, Institut Polytechnique de Paris France Georgios Bouloukakis gbouloukakis@upatras.gr Department of Electrical and Computer Engineering, University of Patras Greece Télécom SudParis, Institut Polytechnique de Paris France Abstract This paper presents CRAFTER, an automated framework for de- signing and deploying self-adaptive IoT systems using Causal Re- inforcement Learning (CRL). As IoT devices increasingly populate pervasive computing spaces, smart environments are enabled with advanced monitoring and interactive services. The dynamic nature of these environments, such as fluctuating workloads and evolving application demands, poses significant challenges in maintaining consistent Quality of Service (QoS) levels of IoT applications. While existing self-adaptation techniques offer adaptive capabilities, they are often designed to deal with specific application domains, hinder- ing the design of self-adaptive solutions that can be re-used across multiple IoT verticals. In addition, there is a lack of automated pipelines that act on identifying key performance drivers to take effective adaptation decisions. CRAFTER addresses these issues by using Causality as a formal framework for performance analysis of IoT systems. CRAFTER generates causal graphs to uncover depen- dencies among system components and guide adaptation decisions based on cause–effect relationships. Then, adaptation agents can leverage this knowledge to take more effective adaptation decisions in dynamic situations. Our experimental evaluation demonstrates how CRAFTER enables deriving causal graphs spanning diverse IoT use cases. Furthermore, we showcase how CRAFTER improves self-adaptation performance by 25% compared to state-of-the-art Reinforcement Learning-based approaches. CCS Concepts • Computer systems organization→Sensor networks; Reconfig- urable computing;• Computing methodologies→Reinforce- ment learning; Causal reasoning and diagnostics; Intelligent agents. This work is licensed under a Creative Commons Attribution 4.0 International License. SEAMS ’26, Rio de Janeiro, Brazil © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2445-9/2026/04 https://doi.org/10.1145/3788550.3794868 Keywords Self-adaptive systems, IoT, Causal discovery, Reinforcement Learn- ing ACM Reference Format: Houssam Hajj Hassan, Ajay Kattepur, Denis Conan, and Georgios Bouloukakis. 2026. CRAFTER: Causality-based Self-Adaptation for Autonomous IoT Sys- tems. In 21st International Conference on Software Engineering for Adaptive and Self-Managing Systems (SEAMS ’26), April 13–14, 2026, Rio de Janeiro, Brazil. ACM, New York, NY, USA, 13 pages. https://doi.org/10.1145/3788550. 3794868 1 Introduction In today’s pervasive computing environments, Internet of Things (IoT) devices enable smarter spaces that offer enhanced monitor- ing and interactive services. Such IoT services and applications have become mainstream within multiple systems, such as smart homes, smart agriculture, or smart building automation. With the increasing integration of IoT sensors within consumer devices, a new generation of devices has emerged: virtual, augmented and mixed reality (XR). Software and inter-networking of these XR devices, along with advances in Edge computing and novel net- working technologies (6G) have led to the emergence of Metaverse applications [49]. The Metaverse provides a realistic way to reflect real-world en- vironments that include famous landmarks (Eiffel tower, Statue of Liberty) or places that are familiar to individuals (home, school) through Digital Twin (DT) replicas. For this purpose, Metaverse applications rely on IoT devices to capture real-time data from phys- ical spaces, which is then synchronized with virtual environments to create immersive and interactive experiences. The integration of these applications with physical environments relies on advanced IoT platforms consisting of devices that sense physical phenomena and generate data. This data is then processed, filtered, or aggre- gated before being used by applications [46]. Given this complexity, the performance of IoT applications largely depends on the ability of IoT systems to meet stringent Quality of Service (QoS) require- ments, such as low latency, high availability, and accuracy. arXiv:2610.06320v1 [cs.AI] 5 Oct 2026 SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. However, modern smart spaces are inherently dynamic and un- predictable. Changes in the number of IoT devices, network condi- tions, and available computational resources create a continuously evolving environment. For example, during major public events such as concerts or sports games in a large-scale smart city infras- tructure, the influx of thousands of visitors can cause a significant surge in demand for IoT-enabled services such as real-time traffic management, public safety surveillance, and smart parking systems. This sudden spike in data traffic and sensor activity can result in network congestion and resource bottlenecks at Edge servers. To ensure that IoT systems can effectively adapt to changes while maintaining strict QoS requirements, it is essential to leverage self- adaptation techniques within these systems. Self-adaptive solutions monitor system performance and respond to changes, adjusting configurations in real-time to avoid performance degradation. Sev- eral existing approaches [1,3,22,31,33,46,56] have explored self-adaptive mechanisms for IoT systems, focusing on monitor- ing QoS metrics like network congestion and resource utilization. However, these solutions often fall short by neglecting the broader context in which IoT systems operate. They typically rely on re- active measures, failing to predict and prevent issues before they lead to QoS violations [1]. In addition, the majority of these works do not offer formal approaches for investigating the causes of QoS violations; adaptation decisions are often solely based on changes in QoS metrics [1,22,31,56]. Nevertheless, context information provides valuable insights into when and how to take adaptation decisions. More importantly, adaptation logic in prior work is typ- ically tailored to specific application domains, limiting reuse and requiring domain expertise. This paper introduces CRAFTER, a causality-based self-adaptation solution for autonomous IoT systems. The core contribution of CRAFTER lies in its application-independent approach for causal graph generation, enabling the identification of context and per- formance variables that influence system behavior. This enables creating a semi-automated pipeline that allows IoT system develop- ers to follow the same approach for designing self-adaptation solu- tions approaches across diverse environments, whether in smart cities, homes, or industrial settings. In addition, the causal graph generation process requires minimal domain expertise, reducing human intervention in the self-adaptation pipeline. To enable the design of such an automated pipeline, CRAFTER first relies on Causality [35] as a theoretical framework for the anal- ysis of IoT systems’ performance. This enables defining a formal methodology for identifying causal relationships among the differ- ent variables in a smart space. CRAFTER then integrates Causal models with decision-making approaches such as Reinforcement Learning (RL) [44] to take informed adaptation decisions that ac- count for both QoS and contextual factors affecting performance. CRAFTER enhances the reliability of modern autonomous IoT sys- tems through the following key contributions: –A semi-automated approach for designing self-adaptive IoT sys- tems across heterogeneous smart environments. –A formal methodology for performance analysis using Causal Models. – An automated Causal RL (CRL) pipeline to take informed adapta- tion decisions in dynamic environments. # occupants Visitor Guiding Application Maintenance App Security App Sub-Metaverse(s) Apollo Gallery Greek Antiquities Occupant detection QoS QoS QoS QoS Figure 1: Smart museum scenario – An open-source prototype implementation showing CRAFTER’s effectiveness in self-adaptive IoT systems. The remainder of the paper is organized as follows. Section 2 presents an overview of CRAFTER starting from a motivating use case to highlight the need for autonomous adaptation in IoT environ- ments. Section 3 formally presents the CRAFTER IoT system model. We detail our solution in Section 4, and provide an experimental evaluation of CRAFTER in Section 5. In Section 6, we provide an overview of related work. Section 7 goes over the limitations of CRAFTER, and Section 8 concludes the paper with future directions. 2 The CRAFTER Approach We first highlight the challenges in maintaining QoS requirements of applications in dynamic environments in Section 2.1 through a motivating use case. We then illustrate in Section 2.2 the chal- lenges designing generic self-adaptation solutions across different IoT domains. Finally, we provide an overview of how CRAFTER addresses these challenges in Section 2.3. 2.1 Le Louvre Scenario To illustrate the complexity and challenges involved in designing self-adaptive IoT systems, we consider a representative example: the Louvre Museum in Paris. This scenario exemplifies the operation of a large-scale, dynamic IoT environment where diverse devices and applications are deployed to serve multiple stakeholders, each with distinct QoS requirements. In addition, this scenario demonstrates the challenges associated with low-latency requirements and how CRAFTER addresses such challenges. Le Louvre is divided into three sectors (Richelieu, Sully, and Denon), and each sector comprises several exhibition rooms that contain sculptures, artifacts, and paintings spanning various civilizations and cultural movements. Le Louvre administrators wish that ev- eryone, including people not physically present in Paris, is able to explore works of art displayed in the museum and participate in interactive events. For this purpose, a DT replica of Le Louvre is created and deployed in the Metaverse, where remote visitors (meta-occupants) are able to visit Le Louvre virtually. The DT replica (Le Louvre sub-metaverse) captures static properties of Le Louvre including the organization of sectors, and placements of works of art. Additionally, to provide a realistic and immersive experience, Le Louvre sub-metaverse should accurately reflect the dynamic conditions of Le Louvre in real-time. For this purpose, IoT devices are used to provide: (i) data from light sensors for a realistic light- ing conditions, (i) noise data for a realistic acoustic experience, CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil (i) visitors’ movements to reflect crowd conditions in exhibition rooms, and (iv) location of artifacts (e.g., temporary exhibitions). As shown in Figure 1, to provide such monitoring and inter- active capabilities, IoT devices are deployed to monitor artifacts (motion sensors, RFID tags), visitors (cameras), and ambient con- ditions (temperature/humidity sensors, smoke detectors). Device data may additionally be processed by Virtual Sensors before being consumed by applications [46]. For example, video frames may be analyzed and aggregated with motion and WiFi data to provide more accurate estimations of the occupancy in each exhibition room. Finally, applications receive data to provide services for dif- ferent stakeholders. For instance, Le Louvre security personnel may use a dashboard that shows monitoring information in different sectors of the museum, and visitors may use a dedicated application for checking waiting times in different exhibition rooms. 2.2 Challenges in Designing Portable and Generic Self-adaptation Solutions The Louvre scenario illustrates the complexity of deploying self- adaptive IoT applications in dynamic, multi-stakeholder environ- ments. While many approaches for deploying self-adaptive systems exist in the literature, they are often designed in an ad hoc, domain- specific manner, making them difficult to generalize or reuse across different application domains (e.g., smart museums, factories, or cities) [51]. We identify two key limitations in existing approaches for designing self-adaptive IoT systems: (1)Designing effective self-adaptation logic today still requires significant domain expertise [52,55]. Developers must iden- tify – either manually or with the help of a domain expert – which context and performance variables are most relevant, understand their relationships, and encode specific adaptation strategies. This process is often manual, time-consuming, and difficult to replicate across different domains. (2)Existing self-adaptive systems lack a systematic and reusable approach for identifying what to adapt and when [19,51]. Most solutions rely on reactive, rule-based mechanisms or machine learning models trained on domain-specific datasets. These approaches often fail to generalize or provide explainability. Given these challenges, there is a clear need for self-adaptation frameworks that are not only capable of responding to dynamic environments, but that also facilitate re-usability and that are gen- eralizable across domains. CRAFTER addresses this gap through Causal Reinforcement Learning techniques to automate the design of adaptation logic and enable its reuse across deployments. We provide next an overview of CRAFTER’s high-level architecture. 2.3 CRAFTER Overview CRAFTER offers causality-based self-adaptive capabilities for mod- ern IoT systems to enhance their autonomy, reliability, and ensure that QoS levels of applications are maintained, even in dynamic environments. This is achieved by identifying causal relationships among variables that affect the performance of the IoT system. This knowledge drives more efficient decision-making at runtime. To achieve this, Figure 2 shows how CRAFTER is exploited in two phases: (1) at design-time for its deployment in smart environments; Figure 2: CRAFTER’s high-level architecture Figure 3: CRAFTER’s integration within the MAPE-K loop and (2) at runtime for enabling autonomous and efficient decision- making of adaptation agent. Figure 3 shows CRAFTER’s integration within the MAPE-K adaptation loop [25]. Design-time phase. CRAFTER can be deployed in any IoT envi- ronment at design-time to extract causal relationships within the IoT system. For this purpose, an IoT metrics dataset is required: this can be realistic historical data collected through prior monitoring of the smart environment, and/or synthetic datasets generated with DT approaches or ML-based dataset generation techniques [21,48]. For a more comprehensive understanding of the system behavior, it is important that the dataset is also enriched with context infor- mation, such as date/time of day, location of devices, number of occupants, and other contextual information that is relevant to the smart environment. Such context information allows the genera- tion of richer causal graphs, and subsequently enables adaptation agents to take better quality adaptation actions. However, note that this is not mandatory and we do not require any additional processing or labeling of the dataset. CRAFTER accepts as input regular datasets that can be collected from monitoring platforms deployed in smart spaces (incsvformat, which requires minimal processing). Then, Causal Models are generated through Causal Dis- covery [54]; these represent the dependencies among the different features (e.g., resource consumption, number of visitors) captured in the dataset (more details are provided in Section 4.1). To obtain more accurate causal graphs, domain knowledge may be incorpo- rated through expert elicitation, and/or IoT representations of smart spaces, such as Ontologies [4,5,40]. The obtained causal model serves a dual purpose. First, the graph is used by the Performance Explainer to explain the behavior of the IoT system to domain ex- perts by showing causal relationships that can enhance business decisions or enable better tuning of configuration parameters for SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. improved QoS of applications. Second, the causal graph enables efficient self-adaptation in dynamic situations by identifying the leading causes of performance degradation, including both QoS metrics (e.g., resource consumption) and context information (num- ber of occupants, day and time, etc.). These are then used by the States Modeller to model the most important states to be observed by the Adaptation Agent. Runtime phase. At runtime, the deployed IoT system and its applications become autonomous, guided by a generated causal graph that enables precise and effective adaptation actions. Unlike traditional RL models that may react to changes only when QoS metrics change, the causal graph allows the Adaptation Agent to identify and act on key factors that lead to such degradation. By observing states defined by the causal relationships, the Adaptation Agent can take preemptive and more efficient actions through the Action Selector, addressing potential issues before they manifest as performance problems. For instance, in Le Louvre scenario, a higher number of occupants leads to a higher workload on pro- cessing nodes. When this relationship is learned, the Adaptation Agent can monitor the number of occupants as a leading indicator of potential QoS degradation. Instead of waiting for processing nodes to become overloaded, which could lead to higher latency or data loss, CRAFTER enables early adaptation by reconfiguring resources as the number of occupants increases. This automated approach reduces the likelihood of QoS degradation, ensuring that applications’ QoS levels are maintained in changing conditions. The causal graph also helps in resolving hidden dependencies that might not be immediately apparent, allowing the system to adjust in ways that would otherwise be overlooked by purely reactive methods. For instance, if an increase in noise level is found to be an indicator of a high number of occupants, the system can proactively increase available resources to avoid performance degradation. CRAFTER’s integration within the MAPE-K loop. Figure 3 shows how CRAFTER components fit within the different phases of the MAPE-K loop [25]. The Monitor (M) phase includes the collection of the IoT metrics dataset through IoT monitoring platforms. This dataset is then used in the Analyze (A) phase by causal discovery algorithms to generate the causal graphs. The IoT metrics dataset and the generated causal graph constitute the Knowledge Base (KB – K), and are continuously updated to account for changes. The Planning (P) phase involves the RL agent taking adaptation actions in response to changing conditions of the environments, and the Execute (E) phase applies the adaptation actions to the Managed System (i.e., the IoT environment). 3 Modelling Dynamic IoT Environments This section presents a formal description of target IoT systems for which CRAFTER is designed, followed by a formal definition of the self-adaptive QoS problem in the IoT. 3.1 IoT System Formal Model We rely on the publish/subscribe architecture [17] to model data exchange between the components of the IoT system. For this pur- pose, a dedicated message broker is deployed for receiving, filtering, and forwarding messages based on topic-based subscription filters. We consider that a smart space is divided into various locations L, where each location푙 푖 ∈ Lcontains a set of deployed IoT de- vicesD(푙 푖 ). A device푑 푗 provides one (or more) observation표 푗 capturing a physical property that is specific to its location. For ex- ample, a smoke detector provides an observation related to “smoke” in “exhibition hall 1”.푑 푗 publishes data to one or more topics푇 푑 푗 ; we compose topics by coupling the observation표 푗 with the loca- tion푙 푖 where the device is deployed. Hence, a temperature sensor that is deployed in “exhibition hall 3” publishes data to the topic hall3/temperature. Devices either generate data periodically (e.g., temperature sensors), or in an event-driven manner (e.g., a motion sensor) following a probability distribution (e.g., normal distribu- tion). The data generation rate of each device is defined as휆 푑 푗 . Therefore, the total traffic generated by all devices in a location is the sum of the individual rates, denoted as휆 푙 푖 = Í 휆 D(푙 푖 ) . Note that this traffic can be collected and processed from CRAFTER components to create an IoT metrics dataset D. Devices in the same location connect to a shared network switch X 푖 that has specific QoS characteristics such as bandwidth푤 푖 , link delayΔ 푖 and loss rate휔 푖 . To enhance sensing capabilities, a set of virtual sensors푉푆is deployed to process data from IoT devices and produce high-level observations. For example, motion and camera data may be combined to create a new “room occupancy” observa- tion. For this purpose, a set of dedicated Edge nodes퐸are available for hosting virtual sensors. Each edge node푒 푖 ∈ 퐸offers resources related to processing power, memory, and disk space; we denote these characteristics by the tuple휌(푒 푖 )=(푒 푖 .푝푟표푐,푒 푖 .푚푒푚,푒 푖 .푑푖푠푘). Each virtual sensor푣푠 푗 ∈ 푉푆subscribes to a set of topics푇 푠푢푏 푣푠 푗 to receive and process relevant data, and publish new observations to 푇 푝푢푏 푣푠 푗 . The processing time of a virtual sensor휏 푣푠 푗 depends on the rate at which it receives data, the processing algorithm/technique used, and the available resources of the Edge node where푣푠 푗 is deployed. To offer monitoring capabilities and interactive services to the smart space administrators and occupants, a set of applica- tions퐴are deployed. Each application푎 푖 ∈ 퐴subscribes to a set of topics푇 푎 푖 to receive data of interest from devices and virtual sensors. Since applications may be used by different stakeholders, an application defines a set of requirements푎 푖 .푞표푠representing QoS metrics that need to be satisfied. For instance, a security dashboard application specifies that the tail latency훿 푡푎푖푙 should be less than 2푠푒푐표푛푑푠, and the minimum throughputΘ 푚푖푛 greater than 4푀푏푝푠. As described in Section 2.1, a DT replica of the smart space may also be available for meta-occupants to virtually join the space. We denote such applications by 푎 푚푒푡푎 푖 ∈ 퐴 푚푒푡푎 . 3.2 The Self-Adaptive QoS Management Problem To ensure correct application behavior, space administrators typ- ically configure their systems to sustain the required QoS levels. However, as smart spaces are dynamic environments, multiple changes usually occur that affect the QoS requirements of applica- tions. These can be changes in휆 푙 푖 , the utilization of Edge resources 푈(푒 푖 ), or changing QoS requirements푎 푖 .푞표푠and thus, self-adaptive solutions should be deployed to adapt to these changes. Hence, for an application푎 푖 with QoS requirements푎 푖 .푞표푠=(훿 푚푎푥 ,Θ 푚푖푛 ,휔 푚푎푥 ), CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil Table 1: Parameters notations in CRAFTER’s IoT model. NotationDescriptionNotationDescription 푙 푖 ∈ Llocations푒 푖 ∈ 퐸Edge nodes 푑 푗 ∈ D(푙 푖 )devices in 푙 푖 휌(푒 푖 )Edge Resources 표 푗 observations from푑 푗 푣푠 푗 ∈ 푉푆virtual sensors 푇 푑 푗 푑 푗 ’s topics푇 푠푢푏 푣푠 푗 ;푇 푝푢푏 푣푠 푗 푣푠 푗 ’s topics 휆 푑 푗 푑 푗 ’s publication rate휏 푣푠 푗 푣푠 푗 ’s processing delay 휆 푙 푖 data traffic per 푙 푖 푎 푖 ∈ 퐴applications 푤 푖 bandwidth푇 푎 푖 푎 푖 ’s topics Δ 푖 link delay(훿,Θ,휔)latency, throughput, loss rate 휔 푖 loss rate(휇 푞표푠 ,휇 푐표푛푡푒푥푡 )system, context properties the following conditions must be satisfied at any time 푡 : 훿 ≤ 훿 푚푎푥 ;Θ≥Θ 푚푖푛 ; 휔 ≤ 휔 푚푎푥 ∀푡(1) Typically, to detect performance issues, a set of metrics are con- tinuously monitored to provide insights into the performance of the system [1]. In addition to the QoS requirements of applications, this set contains (i) network characteristics (푤 푖 ,Δ 푖 ,휔 푖 , . . . ); (i) re- source usage of Edge nodes푈(푒 푖 ); (i) number of devices|D|and applications|퐴|. We refer to this set of monitored QoS metrics by 휇 푞표푠 [1]. Usually, when changes in휇 푞표푠 cross a threshold, adaptation actions are executed manually or through an automated process [1]. However, when such changes are detected, this often implies that QoS violations already occurred. This happens because휇 푞표푠 are chosen arbitrarily or through experts’ domain knowledge. To solve these issues, CRAFTER relies on a formal methodology for identifying key variables driving the performance of the IoT system and affecting the QoS requirements of applications. In par- ticular, CRAFTER leverages Causal Discovery for identifying, along- side휇 푞표푠 , context variables (denoted by휇 푐표푛푡푒푥푡 ) that contribute to fluctuations of the IoT system performance. Such variables may include day, time, weather, location, number of occupants in loca- tion, noise levels, and other context information found to affect the system performance. Monitoring휇 푐표푛푡푒푥푡 in addition to휇 푞표푠 contributes to the early detection of QoS violations. The identified variables empower the decision-making process of the Adaptation Agent that is able to take more efficient adaptation actions. The next section provides further details about this process. 4 Enabling Causality-based Adaptation CRAFTER leverages the causality framework [35] as a formal theo- retical methodology for identifying cause-and-effect relationships in IoT systems through observational data, including context infor- mation. More specifically, based on an IoT metrics datasetD, causal models are generated to identify휇 푞표푠 and휇 푐표푛푡푒푥푡 . These are then used as drivers for informed decision-making. 4.1 Identifying Causal Relationships in IoT Systems Causality relies on a formal description of the interactions between observed variables in the form of a causal graph. Unlike black- box techniques, where predictions about an outcome are made with a pure data-driven approach, such graphical representation is effective when it comes to explainability [6,35,54]. For this purpose, CRAFTER generates a causal graph to: (i) help domain experts understand the behavior of their IoT systems, (i) identify key metrics influencing the performance of the system, and (i) take more effective adaptation actions in response to changes. Definition 1. (Causal graph). A causal graph퐺(also called Causal Graphical Model) is the graphical representation that depicts the cause-effect relationships among variables in a given system. 퐺= (V,E)is structured as a Directed Acyclic Graph (DAG), where V= 휇 푞표푠 ∪ 휇 푐표푛푡푒푥푡 are variables in the system and E⊆V×V show causal effects (increase/decrease in latency, etc.).퐺represents a joint probability distribution 푃 over a set of random variables X= (푋 1 ,푋 2 , ...,푋 푑 ) where 푃 is Markovian with respect to 퐺. Through causal graphs, CRAFTER is able to recognize the causes of QoS violations. This happens by identifying direct and indirect causes of QoS changes: Definition 2. (Direct and indirect cause) For each directed edge (푋,푌) ∈ E,푋is a direct cause of푌and푌is a direct effect of푋. Recursively, every cause of푋that is not a direct cause of푌, is an indirect cause of 푌. visitor’s behavior day of the week latency computing resources data traffic Endogenous variable Exogenous variable Figure 4: Causal Graphical Model Consider Figure 4 with a sample causal graph that represents possible causal relationships in an IoT system. The graph shows that thecomputing resourcesanddata trafficare a direct cause oflatency. In addition, since there is a direct path fromday of the weektolatency, we defineday of the weekas an indirect cause of latency. We can further quantify the effects of causes on variables by building on the language of Structural Causal Models to describe the collection of mechanisms underpinning a phenomenon. Definition 3. (Structural Causal Model (SCM)). A structural causal modelM is defined by a 4-tuple⟨V, U,F, P(U)⟩: – Vis a set of endogenous variables i.e., observable variables within the system that are determined by variables in the model. In IoT sys- tems, these are the variables included in the set휇 푞표푠 ∪ 휇 푐표푛푡푒푥푡 . – Uis a set of exogenous variables, i.e., unobservable variables where 푉∩푈=∅. As shown in Figure 4, even thoughvisitor’s behavior (e.g., preferences regarding exhibition halls) directly affects la- tency, CRAFTER would not observe this variable since it can neither be controlled nor monitored by the system. Such vari- ables cannot be found in휇 푞표푠 ∪ 휇 푐표푛푡푒푥푡 . – Fis a set of functions푓 푖 , ..., 푓 푛 , where each푓 푖 ∈ Fis defined as 푓 푖 :(V∩ U) 푝 → V, with푝the ariety of푓 푖 so that푓determines completely the value of푉 푖 .푓 푖 enables quantifying the effect of changing a variable in퐺on its child. For instance, a 2×increase innetwork trafficmay result in a 1.5×increase inlatency, i.e., 푓(latency)= 1.5× network traffic. SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. – 푃(U)is the joint probability distribution over the exogenous vari- ables 푃(U)= Î 푖 푃(푈 푖 ). In most application domains, the causal graph may only be par- tially known by experts. To better understand a system behavior, CRAFTER recovers the complete causal graph. Definition 4. (The causal discovery problem). The causal discov- ery problem consists in recovering the true graph퐺 ∗ from a given dataset D. This requires CRAFTER to findV=휇 푞표푠 ∪ 휇 푐표푛푡푒푥푡 by relying on a causal discovery algorithm. Definition 5. (Causal Discovery Algorithm). A causal discovery algorithm is said to solve the causal discovery problem iff. it converges to the true graph 퐺 ∗ in the limit of the sample size of the dataset D. Such algorithms aim to identify the underlying DAG represent- ing the causal influences in a system. Popular examples include the Peter and Clark (PC) [43], Greedy Equivalence Search (GES) [11], and the Fast Causal Inference (FCI) [43] algorithms. Note that causal discovery algorithms are typically non-deterministic, and therefore it is necessary to validate the generated causal graph with domain experts to validate their correctness. The dataset quality and richness affects the graph quality, and therefore it is better to include as many relevant variables as possible when collecting the dataset. In some systems, a cause-effect pair is known to exist (or to not exist) a priori, e.g. through domain expert’s elicitation. With CRAFTER, domain experts can explicitly represent such pairs via a knowledge base used by the causal discovery algorithm to inform and con- strain the structure of the causal graph. This can be achieved either manually by domain experts, or by using existing Ontologies that represent the IoT system. Definition 6. (Knowledge base). A knowledge baseKis defined as an ordered pair(R, F)whereRis the set of required directed edges, while F is the set of forbidden directed edges. 4.2 CRL-based Adaptation CRAFTER relies on Reinforcement Learning [44] as a decision- making approach for taking adaptation actions for satisfying the QoS requirements of applications in IoT environments. However, unlike traditional approaches where states and actions are chosen regardless of causal relationships, CRAFTER enhances decision- making abilities by using the insights gained from causal graphs. The generated causal graph is used to define the set of states and actions that the CRAFTER adaptation agent can act upon. This process can be achieved either manually, or by using automated approaches to convert nodes in the causal graph to states and actions. We provide next a formal definition of the RL problem this paper deals with. Reinforcement Learning requires an agent to interact with an environment over time to learn the best action(s) to take under spe- cific situations, to optimize an objective function (e.g., minimizing latency). At each time step푡, the agent receives a state푠 푡 in a state spaceSand selects an action훼 푡 from an actions spaceA, following a policy휋(훼 푡 | 푠 푡 ). The policy represents the agent’s behavior, i.e., a mapping from푠 푡 to훼 푡 . When an action is taken, the agent receives a scalar reward푟 푡 according to a reward functionR(푠,훼), and tran- sitions to the next state푠 푡+1 following a state transition probability P(푠 푡+1 | 푠 푡 ,훼 푡 ). For instance, an agent may decide to allocate more bandwidth to network switches in high-traffic areas (action훼 푡 ) to reduce data exchange latency (state푠 푡 ). The reward푟 푡 can be based on how effectively the bandwidth allocation reduces latency while maintaining overall network efficiency. After this action, the system transitions to the next state푠 푡+1 , where new metrics such as up- dated latency and network load are observed. The state transitions and rewards are stochastic and are assumed to have the Markov property. In an episodic problem, this process continues until the agent reaches a terminal state and then it restarts. This can be a state where QoS requirements of all IoT application are satisfied. The return푅 푡 = Í inf 푘=0 훾 푘 푟 푡+푘 is the discounted, accumulated reward with the discount factor훾 ∈ (0,1]. The agent aims to maximize the expectation of such long term return from each state, which leads to learning the optimal policy 휋 ∗ to follow. In existing approaches, the state spaceSis usually modelled based on휇 푞표푠 , which may include network link congestion, data traffic, and resource consumption [1]. However, CRAFTER identifies additional relevant variables (including휇 푐표푛푡푒푥푡 ) that affect system performance through Causal Discovery, as discussed in Section 4.1. Hence, based on the obtained causal model, CRAFTER defines the RL problem as follows: –The set of statesSis defined using휇 푐표푛푡푒푥푡 (e.g., location, number of occupants, day and time). –The set of actionsAincludes the available actions that can be taken for adaptation (e.g., bandwidth/resource allocation). –To satisfy the QoS requirements of applications, CRAFTER de- fines a reward functionRto minimize the deviation between the QoS requirements and the observed performance of the system. R=−( ∑︁ 푎 푖 ∈퐴 휙 푖 훿 푎 푖 −훿 푞표푠 훿 푞표푠 +푐 1 .휔+푐 2 .휌(푒 푖 ))(2) where휙 푖 represents the “priority” of the application (i.e., how im- portant the application is), and 훿 푎 푖 −훿 푞표푠 훿 푞표푠 represents the deviation between the latency defined by the application’s QoS require- ments and the actual latency perceived by the application. To avoid over-allocation of resources, we add penalty terms (푐 1 and 푐 2 ) to the bandwidth and resources allocated in the system. Two main approaches exist for solving RL problems. Value-based methods — such as Q-learning/Deep Q-learning — focus on learn- ing an optimal value function by mapping states and actions to rewards [44]. However, these methods are more suited for environ- ments where states and actions can be modelled as discrete values. In more complex environments with a continuous action space (e.g., controlling resource allocation in complex IoT systems), such methods may struggle to find the best policy [44]. For this purpose, CRAFTER relies on policy-based methods, such as Proximal Policy Optimization (PPO) [41], to directly learn the optimal policy휋 ∗ without having to learn a value function. 5 Experimental Evaluation This section presents the evaluation of CRAFTER using a realistic smart museum scenario. For this purpose, we first implement the CRAFTER prototype for simulating IoT data exchange in smart CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil Figure 5: The CRAFTER prototype implementation Table 2: Device and visitor allocation per location Location# devices% visitors B2535 C115 D175 E1815 G1615 S1510 V1015 spaces (Section 5.1). This enables modeling spaces and defining the deployed devices, virtual sensors, and applications. In addition, the prototype supports controlling the networking infrastructure, resource allocation parameters, and number of occupants in each location of the smart space. Then, we model several exhibition halls in the Louvre by relying on the analysis done in [53], which monitors visitors’ movement patterns throughout various loca- tions. Using the developed prototype and models, we emulate IoT data exchange and generate an IoT metrics dataset containing re- sponse times per data flow (Section 5.2). CRAFTER then extracts causal relationships between the different variables in the smart museum scenario (Section 5.3). To showcase CRAFTER’s decision- making capabilities, we feed the smart museum causal graph to CRAFTER’s Adaptation Agent for taking adaptation decisions to keep the response time of applications under the QoS requirements that they define (Section 5.4). Finally, we compare our solution against state-of-the-art approaches (Section 5.5). The prototype developed, the models and datasets used for the following experi- ments, along with the solution and results are publicly available on https://github.com/satrai-lab/crafter/. 5.1 CRAFTER Prototype Implementation For evaluating CRAFTER, we implement a Java-based prototype for emulating IoT data exchange in smart spaces. As shown in Figure 5, we model properties of smart spaces, devices, virtual sen- sors, and applications and their QoS requirements in JSON format. We consider that a space is divided into multiple physical loca- tions that may have different characteristics. These include the area of the space, the number of occupants in the space, and the type and number of IoT devices deployed. Then, we model devices’ properties: their type (e.g., temperature sensor, motion sensor), the observation(s) they provide (e.g., temperature, humidity, number of occupants), and the distribution and rate at which they generate data. Virtual sensors define observations that they receive and pro- cess using simple rule-based algorithms or more complex ML-based approaches. Finally, applications deployed in the space specify ob- servations to be received from devices and virtual sensors, which Figure 6: Causal graph for the smart museum scenario are then translated to topic subscriptions. They also define QoS requirements related to latency, throughput, energy consumption, and other metrics that have to be satisfied. Communication between the different components of the IoT system takes place through a publish/subscribe architecture. For this purpose, we use the MQTT Paho Library [34] for implementing MQTT clients (devices, virtual sensors, and applications), and EMQX 5.6.1 [15] as a message broker for handling topic-based data exchange. To emulate the networking infrastructure, we rely on Containernet [37], a fork of the Mininet network emulator that supports using Docker containers as net- work hosts. Each location is packaged and deployed as a Docker container (i.e., network host) connected to its dedicated switch; this allows controlling the characteristics of each location’s network link separately. In addition, Edge and Cloud resources are emulated to host virtual sensors and heavyweight computing tasks. 5.2 Experimental Setup To evaluate our approach, we rely on the analysis done in [53] to model 7 exhibition halls in the Louvre, containing popular paintings and artifacts such as Da Vinci’s Mona Lisa and Canova’s Psyche and Cupid, and to distribute visitors across locations. We consider that each exhibition hall contains IoT devices deployed for monitoring various space properties; in total, 112 devices are deployed across the smart space. Table 2 shows the allocation of the number of devices and visitors per location, and Table 3 shows the properties of the virtual sensors and applications deployed. We consider that each visitor carries a mobile device that connects to the Louvre infrastructure for receiving visitor guiding information, and period- ically sends its location information to help Louvre administrators’ analyze visitor’s movements and the most visited artifacts. Two Edge nodes are available to host 4 types of virtual sensors. Finally, we consider 5 representative application types that are deployed in the museum, and that define latency QoS requirements to be met. As described in Section 2.1, the Louvre sub-metaverse applica- tion enables remote visitors to visit the Louvre in real-time via VR equipment. 5.3 Extracting Causal Models As described in Section 2.3, at design-time, CRAFTER extracts causal relationships in the IoT system. Recall from Section 4.1 that gen- erating causal models involves collecting an IoT metrics dataset D. For this purpose, we use the CRAFTER prototype to emulate IoT data exchange in the Louvre setup presented in Section 5.2. To generate the dataset D, we emulate data exchange in the Louvre for each day of the week (excluding Tuesday, when the Louvre is SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. Table 3: Properties of virtual sensors and applications Virtual SensorReceived dataProcessing techniqueApplicationReceived dataQoS requirements Occupancy Prediction Camera feed, visitor’s location CNN for people detection, aggregation with visitors’ locations MetaverseLighting, noise, visitors’ locations20 ms Queue ManagementVisitor’s location Estimation of waiting times using linear regression Smart lightingLighting100 ms Visitor guidingOccupancy, queueing times400 ms Security Analysis Camera feeds, motion , door sensors Aggregation of data for security threat detectionArtifact maintenanceMaintenance date2 s Predictive Maintenance Temperature, humidity, air quality, proximity Estimation of maintenance date using linear regression SecuritySecurity alert1s closed) and for two time periods each day: the morning period (AM) and evening period (PM). We vary the number of visitors based on the day and time period, with the weekend days (Friday, Saturday, Sunday) being the most crowded of the week [53]. For each day and time period, we vary the bandwidth value from each location from 20 Mbps to 500 Mbps, and vary the percentage of resources allocated to virtual sensors from 10% of total resources to 100%. In total, we generate a dataset that captures 1560 different possible configurations of the system. For each configuration, we record the response time for individual messages received by each application, as well as the resource consumption per Edge node. Once the dataset is generated, we use CRAFTER to extract causal models. We use the Causal-Learn Python library [61] for gener- ating the causal graph inDOTformat from the IoT dataset D. For this purpose, we rely on the Peter-Clark (PC) [26,43] algorithm using Kernel-based Conditional Independence [58] for testing for independent variables. PC is known for its ability to easily identify conditional independencies, and offers scalability and flexibility in handling various kinds of data. PC starts with a complete graph where each node represents a variable in V, and each edge rep- resents a causal relationship. The algorithm then iteratively tests for conditional independencies and removes edges between nodes that are conditionally independent given any subset of the other nodes. Rules such as orientation based on V-structures and propa- gation of direction [43] are then applied to orient edges following the existing independencies between variables and the provided knowledge base. The generated causal graph for the smart museum setup is shown in Figure 6. We can see that bandwidth allocation, resource allocation, and resource consumption are a direct cause of response time. Naturally, changing these parameters usually results in better/worse response time values for messages. However, we can also observe the context variables that have direct and indirect effects on the response time experienced by applications. For in- stance, the day and time are direct causes of response time, since they are also causes of fluctuations of the number of visitors. Loca- tion, on the other hand, is an indirect cause of response time, since visitors’ distribution across exhibition halls in the museum varies based on the popularity of artifacts and paintings. Hence, when more visitors are present in a hall, data traffic will increase in that location, leading to more congested network links, and a need for more computing power for virtual sensors to process the generated data in a timely manner. We define휇 푐표푛푡푒푥푡 = day of the week, time of the day, number of visitors, and휇 푞표푠 = bandwidth, resource allocation, resource consumption. 010203040506070 Episode 30 20 10 0 10 20 30 40 Reward value SOTA-RL CRAFTER-Context Only CRAFTER-Mixed Figure 7: Reward per training episode The causal graph enables more formal explanation of the per- formance of IoT systems, without the need for assumptions and trial-and-error testing. In more complex deployments, such causal models are not trivial to retrieve only through expert elicitation, hence the need for causal discovery approaches. To highlight CRAFTER’s ability to generate causal graphs across different IoT domains with minimal domain expertise, we eval- uate CRAFTER on three different real-world datasets spanning different IoT use cases. These include: (i) an Autonomous Moving Robot (AMR) scenario with network throughput and latency re- quirements, (i) a smart factory scenario involving a copper produc- tion manufacturing plant with energy consumption requirements, and (i) an anomaly detection scenario in a production cell with latency and throughput requirements. Our evaluation shows that CRAFTER manages to generate relevant causal graphs for three use cases, illustrating how the same self-adaptation can be applied to different IoT domains. The generated causal graphs and more information regarding the evaluation scenarios can be found on: https://github.com/satrai-lab/crafter/. 5.4 Learning Self-adaptation with Causal RL CRAFTER’s Adaptation Agent is guided by the causal graphs gen- erated in Section 5.3 for taking efficient adaptation actions. We train two CRAFTER Adaptation Agents using the obtained causal graph: a first agent (calledCRAFTER-Context Only) that observes states based only on the휇 푐표푛푡푒푥푡 identified by the causal model. The second agent (calledCRAFTER-Mixed) observes both휇 푐표푛푡푒푥푡 and 휇 푞표푠 . The possible actions to be taken include allocating a specific CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil 010203040506070 Reward Value 0.000 0.025 0.050 0.075 0.100 0.125 0.150 0.175 Probability Density SOTA-RL CRAFTER-Context Only CRAFTER-Mixed Figure 8: Distribution of evaluation rewards bandwidth to network links for the different locations, and allocat- ing computing resources to Edge nodes where virtual sensors are deployed. Training the RL agents involves interacting with the IoT environment to learn the optimal policy. When an agent selects an action to be performed, the CRAFTER prototype is simulated under the configuration chosen by the agent, and the reward function value and the next state values are returned to the agent through a feedback loop. We use the Stable-Baseline3 library [39] to design the RL agents, and Gymnasium [45] for creating the training en- vironment. We train the agents using the PPO algorithm [41] to optimize the reward function defined in Equation 2, which aims to reduce each application’s response time deviation w.r.t. its QoS requirements, while avoiding over-allocation of network and com- puting resources. The agents are trained for 70 episodes using a learning rate of 0.0003 and a clip range of 0.2. 5.5 CRAFTER Against Existing Approaches We evaluate CRAFTER against (i) state-of-the-art RL-based ap- proaches commonly used for adaptation in IoT systems [10,30,46], (i) approaches that use genetic algorithms for adaptation [27], and (i) rule-based approaches [22, 31]. We first evaluate the training performance of RL agents. In ad- dition toCRAFTER-Context OnlyandCRAFTER-Mixed, we train an RL agent to take adaptation decisions based solely on휇 푞표푠 (called SOTA-RL).SOTA-RLis trained in the same environment as CRAFTER agents, using the same hyperparameters and for the same num- ber of episodes. For all three agents, the training algorithm, the action space and reward function (Eq. 2) are the same. Figure 7 shows the reward value per training episode for each of the agents. CRAFTER-Context Onlyachieves a 22% improvement in training compared toSOTA-RL. This is due to the incorporation of key con- text variables in the observed states identified through the causal models. By exploiting valuable cause-effect relationships, RL agents are able to make better and more informed adaptation decisions. The improvement is even more pronounced when we combine휇 푞표푠 and 휇 푐표푛푡푒푥푡 : theCRAFTER-Mixedapproach achieves up to 30% improve- ment in training overSOTA-RL, albeit with a lower training stability thanCRAFTER-Context Only. We next evaluate the three models over 100 episodes, and record the mean and standard deviation of the obtained rewards for each episode. Figure 8 shows the distribu- tion of rewards during the evaluation episodes.CRAFTER-Context Only once again achieves a better performance thanSOTA-RL, with a 25% better mean reward value. The standard deviation of reward distribution is also smaller forCRAFTER-Context Only(2.21) than for the SOTA-RL approach (2.33). Next, we evaluate the adaptation capabilities of CRAFTER us- ing the setup presented in Section 5.2. To compare with genetic programming approaches, we use the NSGA-I algorithm [13] imple- mented with the DEAP [12] Python library, with a population size of 50, 70 generations, a mutation probability of 0.2 and a crossover probability of 0.5. To compare with rule-based approaches, we train a Decision Tree implemented with Scikit-learn [36]. For each appli- cation type, we plot the average response time per day and time period under the following conditions: (i) without adaptation, i.e., the same configuration (bandwidth and resource allocation) is used throughout the whole week, (i) with adaptation using the state- of-the-art approaches, (i) using theCRAFTER-Context Onlyand CRAFTER-Mixed adaptation approaches. Figure 9 shows the average response time per application. As expected, without any adaptation solution, the QoS requirements of most applications are violated when the properties of the smart environment change. For example, as the number of visitors and devices increases in the museum starting from Thursday afternoon, the response time of applications increases significantly for all ap- plications. The Decision Tree approach provides better results than static configurations, but its rule-based structure limits its ability to cope with more dynamic and complex fluctuations in traffic and resource demand. This results in high response times during peak conditions (with a response time of up to 47푚푠for Metaverse ap- plications). This shows that simply using rule-based approaches for adaptation purposes is not enough for satisfying the QoS re- quirements of applications in highly dynamic IoT environments. The Genetic Algorithm, on the other hand, enables more effective adaptation actions as the number of visitors and the workload vary. For example, it manages to keep the latency of visitor guiding appli- cations (478푚푠) under the QoS requirements of 500푚푠. However, it struggles to maintain the required QoS consistently for other ap- plications, especially under a high workload. On weekend days, the latency for Metaverse applications reaches up to 49푚푠during peak visiting hours. While the Genetic Algorithm can adapt to some de- gree, it fails to keep response times under strict thresholds for more demanding applications. In response to changes,CRAFTER-Context Onlymanages to keep the response time for all applications under their defined QoS requirements, even when the number of visitors reaches a peak, on Saturday and Sunday, as shown in Figure 9. Even for Metaverse applications that require an ultra-low latency of less than 20푚푠, CRAFTER effectively adapts to the changing properties of the IoT system. TheCRAFTER-Mixedapproach also manages to offer appropriate adaptation in dynamic situations, keeping the response time of Metaverse under 20푚푠as well. On the other hand, theSOTA-RLapproach fails to keep the response time of messages under 20푚푠, resulting in a response time of over 35푚푠(75% higher than the QoS requirements of Metaverse applications), especially during the busiest periods. The same trend is observed for other applications, whereCRAFTER-Context Onlysucceeds in keeping SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. Monday-AM Monday-PM Wednesday-AM Wednesday-PM Thursday-AM Thursday-PM Friday-AM Friday-PM Saturday-AM Saturday-PM Sunday-AM Sunday-PM Period 15 20 25 30 35 40 45 50 Average Response Time (ms) No adaptation QoS requirements Decision Tree Genetic Algorithm SOTA-RL CRAFTER-Context Only CRAFTER-Mixed (a) Metaverse application Monday-AM Monday-PM Wednesday-AM Wednesday-PM Thursday-AM Thursday-PM Friday-AM Friday-PM Saturday-AM Saturday-PM Sunday-AM Sunday-PM Period 0 2000 4000 6000 8000 10000 Average Response Time (ms) No adaptation QoS requirements Decision Tree Genetic Algorithm SOTA-RL CRAFTER-Context Only CRAFTER-Mixed (b) Security application Monday-AM Monday-PM Wednesday-AM Wednesday-PM Thursday-AM Thursday-PM Friday-AM Friday-PM Saturday-AM Saturday-PM Sunday-AM Sunday-PM Period 10 20 30 40 50 Average Response Time (ms) No adaptation Decision Tree Genetic Algorithm SOTA-RL CRAFTER-Context Only CRAFTER-Mixed (c) Smart lighting application Monday-AM Monday-PM Wednesday-AM Wednesday-PM Thursday-AM Thursday-PM Friday-AM Friday-PM Saturday-AM Saturday-PM Sunday-AM Sunday-PM Period 0 1000 2000 3000 4000 5000 Average Response Time (ms) No adaptation QoS requirements Decision Tree Genetic Algorithm SOTA-RL CRAFTER-Context Only CRAFTER-Mixed (d) Visitor guiding application Monday-AM Monday-PM Wednesday-AM Wednesday-PM Thursday-AM Thursday-PM Friday-AM Friday-PM Saturday-AM Saturday-PM Sunday-AM Sunday-PM Period 0 1000 2000 3000 4000 5000 6000 7000 8000 Average Response Time (ms) No adaptation QoS requirements Decision Tree Genetic Algorithm SOTA-RL CRAFTER-Context Only CRAFTER-Mixed (e) Maintenance application Figure 9: Average response time per application response time values of applications under the specified require- ments. By exploiting relevant context information that have an effect of the performance of the system, CRAFTER can effectively adapt to changes in dynamic environments. 6 Related Work This section provides an overview of literature related to self- adaptive IoT systems and causal discovery. Self-adaptive IoT. Significant research has been carried out on self-adaptive systems recently. Application layer approaches such as [31], [16] focus on dynamically adapting sensor deployment and data source assignment using quality evaluation and opportunistic sensing to meet application requirements and system changes. Dis- tream [56] introduces dynamic workload balancing for low-latency, high-throughput live video analytics. However, it only focuses on task distribution for video streaming application. [3] proposes a goal-driven architecture for adapting to sudden device unavail- ability and changing deployment topologies, while [2] employs a machine learning for user activity recognition for the deployment of goal-driven IoT systems. [22,23] leverage AI planning for adaptive data flow configuration in IoT environments based on QoS require- ments and dynamic application changes. Middleware approaches such as Sora [29] introduce a Scatter-Concurrency-Goodput method that focuses on adapting soft resources to critical microservices, while [32] offers a framework for adaptation of cloud computing continuum configurations in dynamic mobile settings. Similarly, [8] provides a framework for ensuring autonomous AIoT operation in complex deployments spanning the computing continuum. RL-based methods have become prominently used for self-adaptive IoT systems [10]. For instance, the authors of [33] present an archi- tecture using LSTM networks for forecasting data traffic and RL for adaptation to enhance energy efficiency in IoT systems. REAM [46] provides a publish/subscribe middleware for resource monitoring based on application priority and employs RL agents for monitor- ing and adaptation actions. [30] uses Deep RL for load-balancing computing tasks in IoT Edge systems while taking into account the communication requirements of applications. [60] introduces safety-aware adaptive RL for autonomous mobile assistive robots, where the agent must adapt actions at runtime while respecting safety constraints and environmental changes. The approach is designed for real-world robotic agents operating in dynamic envi- ronments typical of self-adaptive systems. While this approaches emphasizes runtime safety constraints and robotics adaptation, CRAFTER targets IoT systems and couples RL with design-time causal models to reduce exploration overhead and identify causal drivers of performance issues. [59] proposes a meta-reinforcement learning approach for self-adaptive systems that can quickly adapt policies across multiple possible environment dynamics. It learns a meta-policy across models so that when the real environment appears, the system can adapt faster. On the other hand, CRAFTER uses causal discovery and RL in a unified framework to try and anticipate root causes of performance issues, and not just quickly re-learn policies, but understand what drives adaptation needs. [42] CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil uses online learning and monitoring techniques in an IoT context to achieve antifragility — systems that can improve performance under stress through continuous learning. [14] proposes a proac- tive approach for the self-adaptation of non-linear cyber-physical systems based on Adaptive Model Predictive Control (AMPC), and is designed primarily for autonomous moving robots. While the above approaches support self-adaptation when sys- tem performance is degraded, adaptation actions are reactive (i.e., after the QoS violations are detected). They also fail to identify the causes of QoS violations. CRAFTER supports proactive adaptation by understanding the variables that impact IoT system performance. Causal discovery. Causality has been traditionally used in vari- ous fields, such as genomics, social sciences, economics, among oth- ers [54]. However, with the growing need for explainable systems, causality-based approaches are being more widely used in network- ing and AI-based approaches. For example, [47] proposes wireless traffic prediction using Granger Causal Discovery and a GNN-based model to explore spatio-temporal causal relationships between net- work variables. [20] introduces CaFANet that uses causal analysis and attention mechanisms for network equipment fault predic- tion. [9] explores Knowledge Representation in causal discovery, in enhancing constrained devices and IoT systems. However, their ap- proach is only suited for small scenarios and not clearly applicable for complex dynamic systems. [28] used Partial Information Decom- position to differentiate information types in Causal Discovery for wireless IoT, but does not account for dynamic environments that require runtime adaptation. [38] presents a comprehensive evalua- tion of causal inference-based Root Cause Analysis (RCA) methods for microservice systems using metrics data. The authors assess various causal discovery algorithms and RCA techniques on a com- bination of synthetic and real-world microservice system datasets, highlighting that no single method performs optimally across all scenarios and that current synthetic datasets may not accurately re- flect real-world system behavior. [50] proposes a metric-level RCA approach that utilizes multi-modal data from traces, logs, and met- rics to achieve a more comprehensive system understanding and localize root causes. The authors employ methods such as ranking abnormal services based on multi-modal data and building causal graphs of abnormal metrics with a reward mechanism to identify metric-level root causes efficiently and accurately. The application of causal discovery for IoT remains largely limited to anomaly de- tection and intrusion detection [7,18,28,57,61], while its use in self-adaptive systems (i.e., systems that use the discovered causal structure to adapt themselves) remains sparse [24]. Existing approaches leverage Causality at the network-layer as well as in small-scale static IoT systems. To the best of our knowledge, this is the first work that leverages Causal RL through an automated pipeline to analyze the key causes of QoS violations in dynamic IoT systems and take tailored adaptation actions. 7 Limitations While CRAFTER demonstrates promising results for causality- based self-adaptation in autonomous IoT systems, several limita- tions must be acknowledged: Dependence on dataset quality. CRAFTER relies on IoT perfor- mance metrics datasets to perform causal discovery at design-time. As with all data-driven approaches, the quality, diversity, and rep- resentativeness of the collected IoT metrics dataset directly affect the accuracy of the generated causal graph. If important variables are missing, poorly measured, or insufficiently varied, the resulting causal model may be incomplete or biased. Although CRAFTER can incorporate domain knowledge through expert elicitation or ontologies, fully mitigating data sparsity and hidden confounders remains challenging in complex real-world deployments. Scalability of causal discovery algorithms. Although the PC- based causal discovery used in CRAFTER scales reasonably for the evaluated scenarios, causal discovery algorithms are known to face scalability issues as the number of variables and the dataset size increase. Large datasets collected from large-scale smart environ- ments with thousands of devices, metrics, and contextual variables may require dimensionality reduction, hierarchical causal model- ing, or incremental causal discovery techniques, which are not yet integrated into CRAFTER. Stability of RL-based adaptation. CRAFTER employs Reinforce- ment Learning for runtime adaptation, which introduces training overhead and potential instability during learning phases. Although causal graphs contribute to reducing the state space and improve convergence, online retraining or frequent environment changes may still incur adaptation delays or transient QoS degradation. Fur- thermore, the current implementation does not explicitly enforce safety constraints during exploration, which may be required in critical IoT deployments. Simulation-based evaluations. Our experimental evaluation re- lies primarily on emulated environments and realistic datasets. While this allows controlled experimentation and reproducibility, real-world deployments may exhibit additional sources of noise, failures, and non-stationarity that are difficult to fully emulate. As a result, a sim-to-real gap may exist when deploying CRAFTER in production IoT systems, particularly for safety-critical or latency- sensitive applications. 8 Conclusion and Future Work This paper presents CRAFTER to enable causal-based self-adaptation for autonomous IoT systems. We propose a formal approach based on Causal Discovery for identifying the causes of performance degradation in IoT systems. This results in causal models that are used for modelling states for an Adaptation Agent that is trained to take adaptation decisions in dynamic environments. The ex- perimental results show that CRAFTER achieves a performance improvement of 25% over state-of-the-art RL approaches used for self-adaptation. Our future work includes adding a Model Agnostic Meta-Learning (MAML) component for predicting future states of the system, in terms of context and QoS. We shall also investigate causal inference techniques for quantifying causal effects among the different vari- ables. Finally, we will evaluate CRAFTER in real-life deployments. Acknowledgments This work has received funding from the European Union’s Horizon Europe research and innovation actions under grant agreements No. 101135775 (PANDORA) and No. 101168560 (CoEvolution). SEAMS ’26, April 13–14, 2026, Rio de Janeiro, BrazilHajj Hassan et al. References [1]Iván Alfonso, Kelly Garcés, Harold Castro, and Jordi Cabot. 2021. Self-adaptive architectures in IoT systems: a systematic literature review. Journal of Internet Services and Applications 12, 1 (2021), 14. [2]Fahed Alkhabbas, Sadi Alawadi, Romina Spalazzese, and Paul Davidsson. 2020. Activity recognition and user preference learning for automated configuration of IoT environments. In Proceedings of the 10th International Conference on the Internet of Things. 1–8. [3]Fahed Alkhabbas, Ilir Murturi, Romina Spalazzese, Paul Davidsson, and Schahram Dustdar. 2020. A goal-driven approach for deploying self-adaptive IoT systems. In 2020 IEEE International Conference on Software Architecture (ICSA). IEEE, 146–156. [4]Smart Appliances. 2017. SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping. RTS/SmartM2M-103264v2, Rev 2, 1 (2017). [5]Bharathan Balaji, Arka Bhattacharya, Gabriel Fierro, Jingkun Gao, Joshua Gluck, Dezhi Hong, Aslak Johansen, Jason Koh, Joern Ploennigs, Yuvraj Agarwal, et al. 2016. Brick: Towards a unified metadata schema for buildings. In Proceedings of the 3rd ACM International Conference on Systems for Energy-Efficient Built Environments. 41–50. [6]Elias Bareinboim, Juan D Correa, Duligur Ibeling, and Thomas Icard. 2022. On Pearl’s hierarchy and the foundations of causal inference. In Probabilistic and causal inference: the works of judea pearl. 507–556. [7] Srividya Bhaskara and Santosh Singh Rathore. 2023. Causal effect analysis- based intrusion detection system for IoT applications. International Journal of Information Security 22, 4 (2023), 931–946. [8] Georgios Bouloukakis, Ajay Kattepur, Dusan Jakovetic, Alexandros Iosifidis, Konstantinos Tserpes, and Maria Pateraki. 2025. Unlocking AIoT Efficiency in the Computing Continuum-the PANDORA framework. In Proceedings of the 15th International Conference on the Internet of Things. 201–209. [9]Phillip G Bradford, Himadri N Saha, and Marcus Tanque. 2021. Knowledge Representation for Causal Calculi on Internet of Things. In Artificial Intelligence to Solve Pervasive Internet of Things Issues. Elsevier, 125–145. [10] Wuhui Chen, Xiaoyu Qiu, Ting Cai, Hong-Ning Dai, Zibin Zheng, and Yan Zhang. 2021. Deep reinforcement learning for Internet of Things: A comprehensive survey. IEEE Communications Surveys & Tutorials 23, 3 (2021), 1659–1692. [11]David Maxwell Chickering. 2002. Optimal structure identification with greedy search. Journal of machine learning research 3, Nov (2002), 507–554. [12]François-Michel De Rainville, Félix-Antoine Fortin, Marc-André Gardner, Marc Parizeau, and Christian Gagné. 2012. Deap: A python framework for evolutionary algorithms. In Proceedings of the 14th annual conference companion on Genetic and evolutionary computation. 85–92. [13] Kalyanmoy Deb, Amrit Pratap, Sameer Agarwal, and TAMT Meyarivan. 2002. A fast and elitist multiobjective genetic algorithm: NSGA-I. IEEE transactions on evolutionary computation 6, 2 (2002), 182–197. [14]Farid Edrisi, Diego Perez-Palacin, Mauro Caporuscio, and Raffaela Mirandola. 2025. Approaching Proactive Self-Adaptation in Nonlinear Cyber-Physical Sys- tems. In 2025 IEEE/ACM 20th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS). IEEE, 25–31. [15] EMQX [n. d.]. https://w.emqx.io/. [16] Elif Eryilmaz, Frank Trollmann, and Sahin Albayrak. 2019. Quality-aware service selection approach for adaptive context recognition in IoT. In Proceedings of the 9th International Conference on the Internet of Things. 1–8. [17] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermar- rec. 2003. The many faces of publish/subscribe. ACM computing surveys (CSUR) 35, 2 (2003), 114–131. [18]Ibrahim Gad. 2025. TOCA-IoT: Threshold optimization and causal analysis for IoT network anomaly detection based on explainable random forest. Algorithms 18, 2 (2025), 117. [19]Omid Gheibi, Danny Weyns, and Federico Quin. 2021. Applying machine learning in self-adaptive systems: A systematic literature review. ACM Transactions on Autonomous and Adaptive Systems (TAAS) 15, 3 (2021), 1–37. [20]Zhenwen Gui, Shuaishuai He, Yao Lin, Xin Nan, Xiaoyan Yin, and Chase Q Wu. 2023. Cafanet: causal-factors-aware attention networks for equipment fault prediction in the internet of things. sensors 23, 16 (2023), 7040. [21]Houssam Hajj Hassan, Georgios Bouloukakis, Ajay Kattepur, Denis Conan, and Djamel Belaïd. 2023. EDICT: simulation of edge interactions across IoT-enhanced environments. In 2023 19th International Conference on Distributed Computing in Smart Systems and the Internet of Things (DCOSS-IoT). IEEE, 161–165. [22]Houssam Hajj Hassan, Georgios Bouloukakis, Ajay Kattepur, Denis Conan, and Djamel Belaïd. 2023. PlanIoT: A framework for adaptive data flow management in IoT-enhanced spaces. In 2023 IEEE/ACM 18th Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS). IEEE, 157–168. [23]Houssam Hajj Hassan, Georgios Bouloukakis, Luca Scalzotto, Nirmine Khaled, Denis Conan, Ajay Kattepur, and Djamel Belaïd. 2024. A Message Broker Archi- tecture for Adaptive Data Exchange in the IoT. In 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C). IEEE, 151–158. [24]Raj Kashikar. 2025. Causally-Aware Safe Reinforcement Learning for Long- Horizon Partially Observable Environments in IoT Systems. In Proceedings of the 2025 5th International Conference on Internet of Things and Machine Learning. 97–102. [25]Jeffrey O Kephart and David M Chess. 2003. The vision of autonomic computing. Computer 36, 1 (2003), 41–50. [26]Thuc Duy Le, Tao Hoang, Jiuyong Li, Lin Liu, Huawen Liu, and Shu Hu. 2016. A fast PC algorithm for high dimensional causal discovery with multi-core PCs. IEEE/ACM transactions on computational biology and bioinformatics 16, 5 (2016), 1483–1495. [27] Jia Li et al.2022. Learning Self-adaptations for IoT Networks: A Genetic Program- ming Approach. In Proceedings of the 17th Symposium on Software Engineering for Adaptive and Self-Managing Systems. Association for Computing Machinery, New York, NY, USA, 13–24. [28] Jessica E Liang. 2024. Partial information decomposition for causal discovery with application to internet of things. IEEE Internet of Things Journal 11, 13 (2024), 24289–24299. [29]Jianshu Liu, Qingyang Wang, Shungeng Zhang, Liting Hu, and Dilma Da Silva. 2023. Sora: A latency sensitive approach for microservice soft resource adaptation. In Proceedings of the 24th International Middleware Conference. 43–56. [30]Qingzhi Liu, Tiancong Xia, Long Cheng, Merijn Van Eijk, Tanir Ozcelebi, and Ying Mao. 2022. Deep Reinforcement Learning for Load-Balancing Aware Network Control in IoT Edge Systems. IEEE Transactions on Parallel and Distributed Systems 33, 6 (2022), 1491–1502. doi:10.1109/TPDS.2021.3116863 [31]Majid Lotfian Delouee, Boris Koldehofe, and Viktoriya Degeler. 2023. Aqua-cep: Adaptive quality-aware complex event processing in the internet of things. In Proceedings of the 17th ACM International Conference on Distributed and Event- Based Systems. 13–24. [32]Matteo Mendula, Paolo Bellavista, Marco Levorato, and Sharon Ladron de Gue- vara Contreras. 2024. Furcifer: a context adaptive middleware for real-world ob- ject detection exploiting local, edge, and split computing in the cloud continuum. In 2024 IEEE International Conference on Pervasive Computing and Communica- tions (PerCom). IEEE, 47–56. [33] Henry Muccini and Karthik Vaidhyanathan. 2020. Leveraging machine learning techniques for architecting self-adaptive iot systems. In 2020 IEEE International Conference on Smart Computing (SMARTCOMP). IEEE, 65–72. [34] Paho MQTT Java Client [n. d.]. https://eclipse.dev/paho/index.php. [35] Judea Pearl, Madelyn Glymour, and Nicholas P Jewell. 2016. Causal inference in statistics: A primer. John Wiley & Sons. [36]Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, et al.2011. Scikit-learn: Machine learning in Python. the Journal of machine Learning research 12 (2011), 2825–2830. [37]Manuel Peuster, Holger Karl, and Steven Van Rossem. 2016. MeDICINE: Rapid prototyping of production-ready network services in multi-PoP environments. In 2016 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). IEEE, 148–153. [38] Luan Pham, Huong Ha, and Hongyu Zhang. 2024. Root Cause Analysis for Mi- croservices based on Causal Inference: How Far Are We?. In 2024 39th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 706–718. [39]Antonin Raffin, Ashley Hill, Adam Gleave, Anssi Kanervisto, Maximilian Ernestus, and Noah Dormann. 2021. Stable-baselines3: Reliable reinforcement learning implementations. Journal of machine learning research 22, 268 (2021), 1–8. [40]Mads Holten Rasmussen, Maxime Lefrançois, Georg Ferdinand Schneider, and Pieter Pauwels. 2020. BOT: The building topology ontology of the W3C linked building data group. Semantic Web 12, 1 (2020), 143–161. [41]John Schulman et al.2017. Proximal Policy Optimization Algorithms. arXiv preprint arXiv:1707.06347 (2017). [42]Vincenzo Scotti, Diego Perez-Palacin, Valerio Brauzi, Vincenzo Grassi, and Raf- faela Mirandola. 2025. Antifragility via Online Learning and Monitoring: an IoT Case Study. 2024 IEEE International Conference on Autonomic Computing and Self-Organizing Systems (ACSOS) (2025). [43]Peter Spirtes, Clark N Glymour, and Richard Scheines. 2001. Causation, Prediction, and Search. MIT press. [44]Richard S Sutton. 2018. Reinforcement Learning: An Introduction. A Bradford Book (2018). [45]Mark Towers, Jordan K. Terry, Ariel Kwiatkowski, John U. Balis, Gianluca de Cola, Tristan Deleu, Manuel Goulão, Andreas Kallinteris, Arjun KG, Markus Krimmel, Rodrigo Perez-Vicente, Andrea Pierré, Sander Schulhoff, Jun Jet Tai, Andrew Tan Jin Shen, and Omar G. Younis. 2023. Gymnasium. [46] Praveen Venkateswaran, Kyle E Benson, Chia-Ying Hsieh, Cheng-Hsin Hsu, Sharad Mehrotra, and Nalini Venkatasubramanian. 2021. REAM: A Framework for Resource Efficient Adaptive Monitoring of Community Spaces. Pervasive and Mobile Computing 76 (2021), 101459. [47] Dan Wang, Yingjie Liu, and Bin Song. 2024. A credible traffic prediction method based on self-supervised causal discovery. Science China Information Sciences 67, 5 (2024), 152303. [48]Tianshi Wang, Jinyang Li, Ruijie Wang, Denizhan Kara, Shengzhong Liu, Davis Wertheimer, Antoni Viros i Martin, Raghu Ganti, Mudhakar Srivatsa, and Tarek Abdelzaher. 2023. Sudokusens: Enhancing deep learning robustness for iot CRAFTER : Causality-based Self-Adaptation for Autonomous IoT SystemsSEAMS ’26, April 13–14, 2026, Rio de Janeiro, Brazil sensing applications using a generative approach. In Proceedings of the 21st ACM Conference on Embedded Networked Sensor Systems. 15–27. [49]Xiaojie Wang, Qi Guo, Zhaolong Ning, Lei Guo, Guoyin Wang, Xinbo Gao, and Yan Zhang. 2024. Integration of sensing, communication, and computing for metaverse: A survey. Comput. Surveys 56, 10 (2024), 1–38. [50]Yidan Wang, Zhouruixing Zhu, Qiuai Fu, Yuchi Ma, and Pinjia He. 2024. MRCA: Metric-level Root Cause Analysis for Microservices via Multi-Modal Data. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 1057–1068. [51]Danny Weyns, Ilias Gerostathopoulos, Nadeem Abbas, Jesper Andersson, Stefan Biffl, Premek Brada, Tomas Bures, Amleto Di Salle, Matthias Galster, Patricia Lago, et al.2023. Self-adaptation in industry: A survey. ACM Transactions on Autonomous and Adaptive Systems 18, 2 (2023), 1–44. [52]Danny Weyns, Omid Gheibi, Federico Quin, and Jeroen Van Der Donckt. 2022. Deep learning for effective and efficient reduction of large adaptation spaces in self-adaptive systems. ACM Transactions on Autonomous and Adaptive Systems (TAAS) 17, 1-2 (2022), 1–42. [53] Yuji Yoshimura, Anne Krebs, and Carlo Ratti. 2017. Noninvasive Bluetooth monitoring of visitors’ length of stay at the louvre. IEEE Pervasive Computing 16, 2 (2017), 26–34. [54]Alessio Zanga, Elif Ozkirimli, and Fabio Stella. 2022. A survey on causal discovery: theory and practice. International Journal of Approximate Reasoning 151 (2022), 101–129. [55]Edith Zavala, Xavier Franch, Jordi Marco, Alessia Knauss, and Daniela Damian. 2018. SACRE: Supporting contextual requirements’ adaptation in modern self- adaptive systems in the presence of uncertainty at runtime. Expert Systems with Applications 98 (2018), 166–188. [56]Xiao Zeng, Biyi Fang, Haichen Shen, and Mi Zhang. 2020. Distream: scaling live video analytics with workload-adaptive distributed edge intelligence. In Proceedings of the 18th Conference on Embedded Networked Sensor Systems. 409– 421. [57] ZengRi Zeng, BaoKang Zha, Xuhui Liu, and Xiaoheng Deng. 2025. Causal Interpretability Methods for IoT Anomaly Traffic Detection. IEEE Internet of Things Journal (2025). [58]Kun Zhang, Jonas Peters, Dominik Janzing, and Bernhard Schölkopf. 2012. Kernel- based conditional independence test and application in causal discovery. arXiv preprint arXiv:1202.3775 (2012). [59]Mingyue Zhang, Jialong Li, Haiyan Zhao, Kenji Tei, Shinichi Honiden, and Zhi Jin. 2021. A Meta Reinforcement Learning-based Approach for Self-Adaptive System. In 2021 IEEE International Conference on Autonomic Computing and Self- Organizing Systems (ACSOS). 1–10. doi:10.1109/ACSOS52086.2021.00024 [60]Qi Zhang, Ioannis Stefanakos, Javier Cámara, and Radu Calinescu. 2024. Safety- Aware Adaptive Reinforcement Learning for Mobile Assistive-Care Robots. In 2024 IEEE International Conference on Autonomic Computing and Self-Organizing Systems Companion (ACSOS-C). IEEE, 115–120. [61]Yujia Zheng, Biwei Huang, Wei Chen, Joseph Ramsey, Mingming Gong, Ruichu Cai, Shohei Shimizu, Peter Spirtes, and Kun Zhang. 2024. Causal-learn: Causal discovery in python. Journal of Machine Learning Research 25, 60 (2024), 1–8.