Operationalising Normative Rules in Autonomous Robotic Systems Through Context-Oriented Programming

1 Introduction

Autonomous and artificial intelligence (AI) systems interacting with or affecting humans with their behaviour come with associated risks that must be properly addressed. Namely, autonomous agents should transparently behave in accordance with recognised social and human values, and adapt ethically to different users in different contexts [Dignum, 2025]. At the time of global AI policy frameworks and regulations [Soler Garrido et al., 2024; UNESCO, 2022; Radanliev, 2025], the mounting sensitivity on these aspects is driving research on ethical AI [Mittelstadt, 2019; AI HLEG, 2019] and so-called ethical-aware autonomous systems (EthicASs) [Autili et al., 2026]. EthicASs can be framed as normative AI

systems [Chopra et al., 2018] where the behaviour of participants is regulated by contextual norms.

In this direction, [Townsend et al., 2022] proposed a methodology to elicit social, legal, ethical, empathetic, and cultural (SLEEC) rules for autonomous systems. Then, recent research has provided ways for turning high-level normative principles into explicit, formalised, consistent sets of SLEEC rules [Yaman et al., 2025; Troquard et al., 2024], aimed at supporting automated and informed decision-making of EthicASs. For instance, [Troquard et al., 2024] provide a mapping from SLEEC rules expressed in natural language to classical logic, enabling automated normative reasoning. [Yaman et al., 2025] provide the SLEEC-TK toolkit, which offers a domain-specific language (DSL) for the specification of SLEEC rules, as well as tools for consistency validation of rulesets and conformance verification of design models formalised in tock-CSP [Miyazawa et al., 2019]. However, such existing research targets specific formalisms and metamodels, while to foster the adoption of EthicASs it is key to support general-purpose programming environments.

Decoupling AI system design from norms is useful, as it enables ethics experts without programming skills to define the norms and accounts for the separate evolution of norms and systems. However, there is currently a lack of contributions on the actual operationalisation (i.e., mechanisms and procedures to turn principles into design and then implementations) of SLEEC rules in EthicASs. Indeed, existing approaches either (i) reason about ethical rules abstractly without executing them, or (ii) hard-code ethical behaviour, without ensuring the SLEEC semantics is preserved.

With these premises, we provide a solution to implement SLEEC rulesets in multi-service robots. Starting from the observation that SLEEC rules ground ethical concerns in specific execution contexts, we argue that their operationalisation requires programming abstractions that explicitly represent context and support runtime adaptation. Building on our preliminary work [Casadei et al., 2026b], we propose Context-Oriented SLEEC (CO-SLEEC), an approach that maps SLEEC rules to context abstractions and enables their semantics-preserving enactment at runtime using the context-oriented programming (COP) paradigm [Salvaneschi et al., 2012; Elyasaf et al., 2023].

CO-SLEEC provides (i) a principled mapping from SLEEC rule constructs to COP mechanisms, and (ii) a reusable runtime approach for ROS-based robotic systems, based on two novel open-source Python libraries: pysleec, for parsing and managing SLEEC rules, and sleec4ros, for integrating ethical rule enactment into robot execution.

We evaluate CO-SLEEC in the scenario of a multi-service assistive robot working in the hospital and household domains. Results show that CO-SLEEC enacts domain-specific ethical rules correctly, with negligible runtime overhead, and grants maintainability on evolving ethical rulesets.

The paper is organised as follows. Section 2 provides background concepts and reference scenarios. Section 3 covers the contribution. Section 4 shows the implementation for robotic systems. Section 5 presents experiments and results. Section 6 covers related work. Section 7 concludes the work.

2 Background andMotivation

Here, we introduce SLEEC rules, COP and the reference scenarios of a multi-service care robot in two different settings.

2.1 SLEECRules

Autonomous agents interacting with humans are required to comply with the human contexts to avoid potential negative consequences arising from their own behaviour or decisions [Dignum, 2025]. To aid in the design of systems with this capability, [Townsend et al., 2022] introduced social, legal, ethical, empathetic, and cultural (SLEEC) rules and a methodology for domain experts to elicit actionable constraints on the system behaviour from high-level norms and principles. It particularly builds on research on machine ethics [Anderson and Anderson, 2011] and defeasible reasoning [Horty, 2012]. Unlike deontic logics [Gabbay et al., 2013], SLEEC rules do not aim to reason about normative systems. SLEEC rules also do not define the system's overall goal and behaviour but rather specify the system's response to contextual conditions at execution time. Specifically, a SLEEC rule consists of a single default rule possibly followed by one or more hedge clauses (a.k.a. defeaters [Brunero, 2022]). The default rule follows the structure "WHEN trigger THEN response". This specifies an event (the trigger) whose occurrence indicates the need to satisfy the constraints defined in the response [Yaman et al., 2023]. However, a rule can be "defeated" by hedge clauses (exceptions) [Townsend et al., 2022]. These are specified via construct UNLESS condition IN WHICH CASE obligation. Each hedge clause specifies a condition in which the original response should be preempted, with the obligation to perform an alternate response, thus enabling contextual reasoning. Notably, SLEEC rules are elicited and defined over Boolean propositions. Still, they can be applied to fuzzy contexts by instantiating fuzzy predicates to crisp values at evaluation time.

As an example, consider the rule from the assistive robotics scenario (introduced next in Section 2.3), which governs a robotic agent's response to user requests to open curtains:

WHEN CurtainOpenRequest THEN OpenCurtains UNLESS UserUndressed IN WHICH CASE (RefuseRequest AND ExplainWhy) 1⃝ UNLESS UserDistressed IN WHICH CASE (WarnUser AND OpenCurtains) 2⃝

According to the default rule, the robot opens the curtains when asked. However, two context-dependent hedge clauses apply: if the user is undressed, the robot refuses and explains the reason, to respect privacy and cultural sensitivity 1⃝; if the user is highly distressed, this clause is overridden and the curtains are opened 2⃝, prioritising emotional state and autonomy. The order in which hedge clauses are listed specifies their importance and priority. In this work, we follow the evaluation order defined in [Troquard et al., 2024], by which hedge clauses are evaluated in a top-down manner, with the last one whose condition holds taking precedence over the others. E.g., if the user is both undressed and distressed, then 2⃝ is activated, as it is the last one that evaluates to true.

2.2 Context-Oriented Programming (COP)

Context-oriented programming (COP) [Salvaneschi et al., 2012] is a language-based paradigm for context-aware systems development supporting adaptation by explicit context modelling and management. Being SLEEC rules contextdependent, we find it natural to investigate this approach.

COP languages have abstractions and mechanisms for (i) modularising context-dependent behavioural variations, and (ii) supporting their dynamic activation upon context change. Though various flavours of COP exist [Elyasaf et al., 2023], the most popular model is the one based on layers in object-oriented settings. A layer is a named modular unit that groups partial class or method implementations, and can be explicitly or implicitly activated at runtime (several activation mechanisms exist). Specifically, multiple implementation variants of a given method are bound to different layers to define behavioural variants. When a layer is activated, the default behaviour is overridden by the one prescribed by the implementation bound with the active layer. This way, COP improves modularisation w.r.t. if-then and object-oriented dispatch [Kamina et al., 2016]. Also, when the target system is highly context-dependent (cf. EthicASs), COP helps to identify a mapping from requirements to implementation in explicit contextual terms, thus fostering understandability, inspection, and maintenance [Salvaneschi et al., 2012].

In this work, we adopt ContextPy3 [Schubert et al., 2015] as the supporting COP framework, as it provides a general and flexible layer activation mechanism and integrates naturally with ROS-based Python implementations. Consider the following minimal self-contained example of Listing 1.

Listing 1 Context-Oriented-Programming example

1 import contextpy3 as cop 2 PC LAYER = cop.Layer('Polite Conversation') 3 @cop.base 4 def hello(): # base version 5 print('Hello!') 6 @cop.around(PC LAYER) 7 def hello(): # when PC LAYER is active 8 print('Hope you're having a wonderful day!') 9 hello() # Hello! (No layer active) 10 cop.global activate layer(PC LAYER) 11 hello() # Hope you're having a wonderful day!

It defines a layer PC_LAYER (instance of class Layer) and two implementation variants of the method hello.

The method implementation decorated with @base defines the default behavior to be selected when no layers are active. Instead, the implementation variant decorated with @around(PC_LAYER) (i.e., bound with PC_LAYER layer) is executed when PC_LAYER is active, to greet in a polite way. Layers can be (de)activated by calling global_(de)activate_layer(L). Thus, contextdependent behaviour is accomplished.

2.3 Reference Scenario: Assistive Robotics

As a reference scenario, we target an assistive multi-service humanoid care robot aimed at providing assistance and companionship to humans across different contexts. As an EthicAS, it should behave in accordance with human values and ethical aspects while fulfilling its mission. SLEEC rules have been proposed precisely to organise and constrain system behaviour from high-level norms and ethical principles. Operationalising SLEEC rules would enable the robot to respect the ethical considerations of the different contexts in which it may be deployed. This work considers two representative domains for a humanoid care robot, each governed by multiple SLEEC rules, some of which are shared across contexts. To ground our scenario, we draw on the work in [Feng et al., 2024], from which we extract a set of already elicited and validated SLEEC rules. Specifically, we selected eight rules: three per domain plus two cross-domain rules. The reference scenario intentionally relies on a ruleset defined and analysed in prior work [Feng et al., 2024], where the authors apply a systematic methodology for eliciting SLEEC rules and verifying them through satisfiability checking. Thus, the rules we use have already been checked for conflict- and redundancy-freeness, rather than being "just assumed" to be correct. Here, we discuss two representative rules. The full ruleset, the CO-SLEEC implementation, all software artifacts, and data sets used is available online [Casadei et al., 2026a].

Hospital Triage In the hospital domain, a care robot operates within a socio-technical system to support patients during clinical workflows. The robot assists patients in the triage process by gathering subjective information (e.g., selfreported symptoms) and objective data (e.g., blood pressure, temperature), and then guides them back to the waiting area.

The selected illustrative SLEEC rule specifies a contextdependent behavioural constraint during patient preparation for examination. The rule enforces that patient preparation is conducted in a private space. However, if the patient is below the legal age, the presence of a legal tutor is required, in accordance with clinical protocols. Formally:

WHEN PreparingExamination THEN EnsurePrivateSpace

UNLESSUserAge < LegalAgeIN WHICH CASEAskLegalPresence

Household Dress Assistance In the home domain, the care robot works to assist humans, e.g., the elderly or people with disabilities. It may collaborate with human caregivers or operate autonomously, with the main role of providing daily support (e.g., assisting in dressing). Beyond functional assistance, the robot should also contribute to the human's emotional well-being by offering companionship and comfort.

As an example rule for this scenario, consider the rule previously introduced in Section 2.1, which governs the robot's response to user requests to open curtains during dressing.

3 The CO-SLEECApproach

CO-SLEEC consists of a principled mapping from SLEEC rulesets to COP concepts. This section presents the mapping and the formal definition of the CO-SLEEC semantics.

3.1 Operationalising SLEECRules Through COP

The core idea of CO-SLEEC is to map SLEEC rule elements to COP concepts, as shown in Table 1. In this way, the developer can define behavioural variations through method implementation variants, each corresponding an obligation of the SLEEC rules. They are dispatched based on how the current context relates to the rules' triggers and hedge clause conditions. Specifically, hedge clauses are mapped to COP layers. This allows each layer to identify the method implementation for the behaviour prescribed by the associated hedge clause obligation. Then, when a layer is activated, its method implementation variant preempts the base method, like a hedge clause defeats the default rule response with its obligation.

In detail, the SLEEC elements are mapped as follows. Each SLEEC rule corresponds to a set of implementations of the same method (i.e., methods with the same name, signature, and scope). The base method implements the system's response to the trigger event (default rule response → base method implementation). The same method has a different implementation variant for each hedge clause associated to a COP layer (hedge clause →COP layer) implementing the clause's obligation. The method is dispatched when the trigger event occurs (default rule trigger → event triggering a method call), and COP will ensure the proper variant is selected (hedge clause condition → runtime context and hedge clause obligation → layer-specific method implementation).

At runtime, in CO-SLEEC, the SLEEC rules are evaluated against the current context conditions to determine the active hedge clause of each rule. An active hedge clause is the hedge clause to be enforced when, in the current runtime context (and according to the SLEEC semantics [Troquard et al., 2024]), the default rule's trigger occurs. Thus, following the COP paradigm, the layer associated to the active hedge clause is activated, and the bound method is executed, instead of the base one. If no hedge clauses are active for a given SLEEC, when the trigger occurs, the base method is executed. For instance, considering the SLEEC rule in Section 2.1, when the user is both undressed and distressed, then the active hedge clause is 2⃝. Here, the current runtime context is defined by the conditions undressed and distressed evaluating to true. If the user asks to open curtains (i.e., the default rule's trigger occurs), the behaviour implemented by the layer associated to the hedge clause 2⃝ is run. This allows the system to behave according to the defined SLEEC ruleset.

Next, we provide, as an overview, a lightweight formalisation of SLEEC elements in the CO-SLEEC approach (more details are in Section 3.2). A SLEEC rule R is of the form: WHEN C0 THEN O0 UNLESS C1 IN WHICH CASE O1 . . . UNLESS Cn IN WHICH CASE On. A context χ is a valuation of atomic variables that characterise a situation, and of which Ci (i ∈ {0, . . . , n}) are Boolean combinations. We write χ |= Ci to indicate that a context χ makes a condition Ci true, and naturally extend it to conjunctions.

A hedge clause hci in a SLEEC rule R can be represented as a triplet ⟨ℓ(R)i,Ci,Oi⟩, where ℓ(R)i is the layer label, while Ci and Oi denote the hedge clause condition and obligation, respectively. Given a SLEEC rule R and its set of hedge clauses HC = {hc1, . . . , hcn}, a hedge clause hci = ⟨ℓ(R)i,Ci,Oi⟩ ∈ HC is said to be active if and only if one of the following holds:

Intuitively, the active hedge clause is the last clause in the ordered sequence whose condition holds in the context χ, as defined in the semantics by [Troquard et al., 2024].

Algorithm 1 SLEEC evaluation algorithm

1: Input: SLEEC rule R = WHEN C0 THEN O0 UNLESS C1 IN WHICH CASE O1 . . . UNLESS Cn IN WHICH CASE On, and context χ 2: Output: active hedge clause label 3: for i ∈ {1, . . . , n} do 4: if χ |= Ci then continue 5: else 6: if i = 1 then return ϵ 7: else return ℓ(R)i-1 8: return ℓ(R)n

Operatively, Algorithm 1 presents the pseudocode of the SLEEC evaluation logic. This procedure is run upon each context change for every SLEEC rule and returns the label of the active hedge clause associated with that rule. The algorithm iterates over the entire set of hedge clauses, continuing until the condition of a hedge clause is evaluated to false (lines 3-7). Whenever a condition is false (lines 5-7), two cases can be identified. If the condition evaluated to false belongs to the first hedge clause, an empty label ϵ is returned, indicating that no hedge clauses are active (line 6). Otherwise, the algorithm returns the label of the previous hedge clause, which represents the layer to be activated (line 7). Finally, if all conditions evaluate to true, the label of the last hedge clause is returned (line 8).

3.2 Formal Aspects

Here we provide a formal presentation of SLEEC rules and their translation into CO-SLEEC instances.

Formal setting Let T be a finite set of atomic triggers. A trigger is considered true when the corresponding event occurs. Let C be a finite set of atomic conditions. They serve to build conditions in the left-hand side of hedge clauses. Let O be a finite set of atomic obligations and responses. They serve to build the right-hand side of clauses.

A context is an element of 2T ∪C , i.e., a set of elements taken from T and C. A context χ specifies the set of atomic triggers and conditions that are considered true, while atomic triggers and conditions in the set χ = (T ∪ C) \ χ are considered false in the context χ.

We use |= to denote the classical logical entailment. A truth assignment, or interpretation, is a complete function val : T ∪C∪O → {⊤, ⊥}. It is extended to arbitrary Boolean combinations of T ∪C ∪O-we also call them formulas-as it is usual in classical propositional logic. An interpretation val is a model of a formula ϕ if val(ϕ) = ⊤. The statement S1, . . . , Sk |= ϕ means that ϕ is entailed from the sets of formulas S1, . . . , Sk. More precisely, the statement holds exactly when, for every interpretation, if it is a model of all the formulas in ∪iSi, then it is also a model of ϕ.

SLEEC rules and obligation entailment A SLEEC rule is of the form: WHEN C0 THEN O0 UNLESS C1 IN WHICH CASE O1 . . . UNLESS Cn IN WHICH CASE On, where n is a nonnegative integer, C0 is a trigger, for every 1 ≤ i ≤ n, Ci is a formula over C, and for every 0 ≤ i ≤ n, Oi is a conjunction of elements in O. Let R be the set of all SLEEC rules.

We will need to refer to specific SLEEC rules programmatically. A SLEEC rule is already uniquely identified by its syntactic form. But for code interpretability and maintenance it will also be convenient to let the developer specify more mnemonic names. Hence, every SLEEC rule R is given a label ℓ(R) that uniquely identifies it. Therefore, we assume that for all R, R′ ∈ R, if ℓ(R) = ℓ(R′ ) then R = R′ .

We adapt the compilation of SLEEC rules into classical logic from [Troquard et al., 2024]. When R = WHEN C0 THEN O0 UNLESS C1 IN WHICH CASE O1 . . . UNLESS Cn IN WHICH CASE On, then we define compile(R) :=

This effectively provides a semantics to SLEEC rules.

In the remainder, we let Γ be a finite set of N SLEEC rules (i.e., N = |Γ|). The SLEEC rules in Γ are of the form Rj = WHEN C j 0 THEN Oj0 UNLESS C j 1 IN WHICH CASE Oj1 . . . UNLESS C jnj IN WHICH CASE Ojnj for every j ∈ {1, . . . ,N}.

Definition 1 (Obligation entailment from SLEEC rules). Given a finite set Γ ⊆ R of SLEEC rules, a context χ, and an obligation O, "Γ entails obligation to do O in χ" when

That is to say, an obligation is entailed in a context from a set of SLEEC rules, exactly when it is classically entailed by their logical representations.

CO-SLEEC instances A CO-SLEEC instance is a tuple ⟨M,L,MM, LM⟩ where M is a set of methods, L is a set of COP layers, MM : Γ → M is a method manager associating a method to every SLEEC rule, LM : 2T ∪C → 2L∪{ϵ} is a layer manager associating a set of layers to every context.

Definition 2 (CO-SLEEC instance execution). Given a COSLEEC instance I = ⟨M,L,MM, LM⟩, and a context χ, "I executes the code impl in context χ" when there is a rule Rj ∈ Γ and a layer ℓ ∈ LM(χ), such that C j 0 ∈ χ and an implementation variant of MM(Rj) is bound with ℓ and contains impl.

We write γ(Γ) the translation of the SLEEC ruleset Γ ⊆ R into a CO-SLEEC instance. γ(Γ) is the CO-SLEEC instance ⟨M,L,MM, LM⟩, such that:

• the set of methods is M = {method(R) | R ∈ Γ};
• the set of layers is L = {ℓ(Rj)i | 1 ≤ j ≤ N, and 1 ≤ i ≤ nj} ∪ {ϵ};
• for every j, MM : Rj ↦→method(Rj);
• for every context χ, LM(χ) = {Algorithm 1(Rj, χ) | Rj ∈ Γ and C j 0 ∈ χ}.

The implementation impl(O) of every obligation O occurring in the SLEEC rules must be placed inside the methods that are bound with corresponding layers, as exemplified in Listing 2. Formally, given a SLEEC rule Rj ∈ Γ, and given Oj i = O0 ∧ . . . ∧ Ok, the code impl(O0); . . . ; impl(Ok) and nothing else will be placed in the implementation variant of method(Rj) bound with ℓ(Rj)i. We say that the implementation of SLEEC rule Rj is properly structured.

Proposition 1 (Semantics preservation). Let Γ be a set of SLEEC rules. Γ entails the obligation to do O in context χ iff γ(Γ) executes impl(O) in context χ.

It follows by mere construction, and the observation that Algorithm 1 lifts the SLEEC semantics represented by Equation (1) to the decision of layer activation.

4 CO-SLEEC for ROS-Based Systems

We implement CO-SLEEC on top of the ROS framework [Macenski et al., 2022], which structures robotic systems as a set of independent processes (nodes) interacting via message-passing. Communication follows a publish/subscribe model, where nodes exchange messages via topics.

Figure 1 shows the proposed implementation architecture. It involves two main actors: (i) SLEEC Experts, responsible for eliciting SLEEC rules, and (ii) the Developer, responsible for developing CO-SLEEC-augmented ROS nodes.

To support the development, we provide two reusable libraries: (i) pysleec, and (ii) sleec4ros [Casadei et al., 2026a]. The former is built on top of the contextpy3 library (cf. Section 2.2). It provides a parser that translates textual rule definitions, expressed in the form described in Section 2.1, into corresponding Python objects, enabling their use within the system. Also, the library offers features for defining and evaluating SLEEC rules, as well as initialising and managing COP layers. The latter enables the integration of CO-SLEEC within ROS, by providing dedicated nodes, message types, and communication interfaces linking the CO-SLEEC-based reasoning with robotic components.

From SLEEC rules to layers SLEEC experts provide SLEEC rulesets for the target domains, checked for consistency and completeness according to formal approaches as in [Feng et al., 2024]. When the robotic system loads a ruleset, the following steps occur: (1) given a rule, COP layers (hereafter also SLEEC layers) are defined for each hedge clause in it; (2) the rule is automatically mapped to the corresponding COP layers, through the SLEEC Config component. The layers are dynamically managed at runtime according to context changes and the SLEEC semantics.

Dynamic layers management Layer management in ROS is achieved via the Context Manager Node, according to the following event-driven, reactive logic. The Domain Listener subscribes to a /domain ROS topic to determine the robot's current operational domain (e.g., hospital or house). This information is used by the Hedge Clauses Manager to filter the SLEEC rules for the current domain, ensuring that domainspecific rules and behaviours are correctly scoped and applied. To implement context-awareness, the Conditions Updates Listener subscribes to the /conditions ROS topic to monitor system updates, such as user state (e.g., user undressed) or environmental changes (e.g., door opened). On a condition change, this component first triggers the Hedge Clauses Manager, which determines the set of currently active SLEEC layers and forwards them to the Layer Updater, then it publishes over the /layers update topic the list of layers to de/activate. The Layer Listener captures this list and passes it to the COP Layer Manager, responsible for the actual activation/deactivation. To achieve this, the COP Layer Manager employs the global activation mechanism (cf. Section 2.2) of contextpy3 to support the activation and deactivation of SLEEC layers. Simultaneously, the COP Layer Manager maintains a shared knowledge base of active layers.

Normative-aware mission execution In robotic systems, the mission of robots is defined as a set of tasks. At runtime, the Mission Manager Node guides the mission by triggering tasks execution. Following ROS best practices, each task is encapsulated as a ROS node by defining Task Manager Node. When a task is constrained by one or more SLEEC rules, it must include multiple implementations (behavioural variations), overriding or complementing the default behaviour to accommodate hedge clauses. Thus, a Task Implementation is enabled by one of the currently active layers, thereby ensuring that the robot runs the selected implementation, adapting its behaviour to respect normative aspects. Listing 2 shows a ROS node implementing the SLEEC rule of the household dress assistance scenario of Section 2. OpenCurtainNode reacts to messages received on the /open curtains req topic (line 4). It implements open_curtains_request in three variants: (i) a default case that opens the curtains upon request (lines 5-7); (ii) a variant declining the request if the user is undressed, offering an explanation (lines 8-10), cf. hedge clause 1⃝; (iii) a variant for opening the curtains if the user is distressed, after issuing a safety warning (lines 11-13), cf. hedge clause 2⃝.

Importantly, this structure does not constrain the execution of a single obligation at a time. When multiple task triggers occur concurrently, or when a trigger occurs while an obligation is running, the execution of the corresponding actions follows the standard ROS execution model, which allows parallel task execution. The consistency of the enforced obligations is ensured by the conflict-freeness of the underlying SLEEC rules, while the responsibility for checking task executability in a given state is up to the developer.

Listing 2 CO-SLEEC Open Curtain ROS Node code snippet

1 class OpenCurtainNode(Node): 2 def init (self): 3 super(). init ('curtain node') 4 self.create subscription( Empty, 'open curtains req', self.open curtains request, 10) 5 @cop.base 6 def open curtains request(self, msg): 7 # implementation: OpenCurtains 8 @cop.around(sleec layers['dress assist.hc1']) 9 def open curtains request(self, msg): 10 # implementation: RefuseRequest AND ExplainReason 11 @cop.around(sleec layers['dress assist.hc2']) 12 def open curtains request(self, msg): 13 # implementation: WarnUser AND OpenCurtains

5 Empirical Evaluation

We evaluate our CO-SLEEC implementation on the multiservice robot scenarios introduced in Section 2.3. Code, data, and results are available online [Casadei et al., 2026a].

Goals Our evaluation assesses:

• E1. Correctness: the implemented system complies with the ethical rules, by respecting the SLEEC semantics.
• E2. Efficiency: CO-SLEEC does not add relevant runtime overhead compared to hardcoded implementations.
• E3. Maintainability: the evolution of SLEEC rulesets (e.g., normative requirements changes, addition of domains) requires little effort to be reflected in the COSLEEC-based system.

Experimental setting We considered the SLEEC rulesets of the two domains and generated 100 test cases with random assignments of rule conditions and active domain. For each case, we derived the ground truth as the expected obligation according to Definition 1. Overall, 800 rule triggers were executed (100 test cases ×8 SLEEC rules). Experiments were run on a Turtlebot 4 equipped with a Raspberry Pi 4B (Ubuntu 22.04, ROS 2 Humble). To isolate CO-SLEEC overhead, robot actions were replaced with logging statements. Correctness is evaluated by comparing executed obligations against the ground truth. Efficiency is measured as the delay between rule triggering and task execution. Maintainability is assessed via lines of code (LoC) required to add or modify rules, and more qualitative observations.

Ablation study We compared the results obtained by running the test cases over CO-SLEEC with the ones obtained over two ablated system implementations: CS-libs and CS-libs-CM. CS-libs ("CO-SLEEC minus libraries") follows the same architecture of CO-SLEEC without using the pysleec and sleec4ros libraries (i.e., Figure 1 except the blue boxes). It leverages a Context Manager Node to evaluate the SLEEC rules when a context update is detected. SLEEC rules logic is manually implemented following the semantics of [Troquard et al., 2024] and the selected hedge clauses are sent to the Task Manager Nodes. On their side, the Task Manager Nodes handle the selection of the actions associated with hedge clauses through if-else statements. CS-libs-CM ("CO-SLEEC minus libraries minus Context Manager node") uses neither the pysleec and sleec4ros libraries nor the Context Manager Node (i.e., Figure 1 except the blue and violet boxes). Instead, the SLEEC rules logic is directly implemented within the Task Manager Nodes. Specifically, the system includes only the Mission Manager Node and a set of Task Manager Nodes. Each Task Manager Node subscribes to domain and condition updates and evaluates them using if-then-else statements to trigger the actions of the default rule or hedge clauses.

Results On correctness (E1) of CO-SLEEC, in all 800 tests, the action run by the robot always matched the ground truth. Concerning efficiency (E2), Table 2 reports the measured

overhead time statistics across the three system variants. We observe that CO-SLEEC adds negligible overhead (mean 4.81ms) compared to CS-libs (4.69ms) and CS-libs-CM (4.63ms). Even in the worst case, the measured overhead for CO-SLEEC is below 12ms. The differences in measured overhead among the three variants are statistically significant (Mann-Whitney U test [Conover, 1999], p-value = 0.014 for the comparison with CS-libs, p-value = 0.001 for the comparison with CS-libs-CM) but have small effect sizes (Cliff's δ = 0.071 and 0.081 [Meissel and Yao, 2024]).

About maintainability (E3), Figure 2 reports (i) the total number of LoC in the codebases for each implemented variants, (ii) the number of LoC that the system developer needs to write in order to add a new SLEEC rule into the system, and (iii) the number of LoC that the system developer needs to modify to update an existing SLEEC rule. As shown in Figure 2, CO-SLEEC reduces total LoC by 6-9% compared to both baselines. Adding a new rule requires 4 LoC in CO-SLEEC versus 11 in the ablated variants. In addition, maintaining a CO-SLEEC system when the set of SLEEC rules changes is arguably simple, while both baselines require modifications to conditional logic. In CS-libs and CS-libs-CM edits imply the modification of nested stacks of if-then-else statements in different components of the architecture. This highlights the benefits of our solution in terms of modularity and separation of concerns.

6 RelatedWork

With the aim of designing socially responsible AI systems, [Townsend et al., 2022] proposed a methodology to elicit SLEEC rules for multi-agent systems. Subsequent research has focused on formalising high-level normative principles into consistent SLEEC rulesets [Yaman et al., 2025; Troquard et al., 2024], supporting automated ethical decision-making. [Troquard et al., 2024] demonstrated how natural-language SLEEC rules can be translated into classical logic for automated normative reasoning. [Getir Yaman et al., 2024; Yaman et al., 2025] introduced the SLEEC-TK toolkit: it provides a DSL for specifying SLEEC rules and tools for validating rulesets and verifying design model conformance in tock- CSP [Miyazawa et al., 2019]. In [Mirani et al., 2026], the authors extend FRET [Katis et al., 2025] to manage SLEEC rule lifecycles and generate Datalog-based inference engines and runtime monitors for obligations. The work in [Anderson and Anderson, 2015] proposes teaching machines to behave ethically by combining agreed-upon general ethical principles with moral decision examples. [Solanki et al., 2023] propose a framework that bridges abstract ethical principles and their practical implementation in healthcare AI, offering actionable guidance across the entire AI lifecycle from data management to deployment. However, there is still a lack of approaches enabling the operationalisation of ethical principles and rules in EthicASs.

Context-aware systems [Kapitsaki et al., 2009] adapt based on context. In [Zeng et al., 2018], context serves as key driver for decisions, allowing the argumentation-based framework to adapt its reasoning and ground explanations to the situation. [Banna et al., 2025] present an LLM-based framework for context-aware, personality-adaptive human-robot interaction, showing that integrating user personality traits and contextual gestures greatly enhances communication satisfaction and social engagement. In [Bremner et al., 2019], a layered architecture augments the traditional goal-task-action model [Vanderelst and Winfield, 2018] with an ethical layer. This layer, positioned above the robot controller, leverages a belief-desire-intention (BDI) framework to enable ethical reasoning in autonomous systems. However, operationalising values involves transforming abstract human values into actionable and testable software requirements [Mougouei et al., 2018]. Yet, a definitive approach is still lacking, with most existing efforts providing only abstract solutions with little focus on practical methodologies, concrete implementations, and verifiable metrics [Mittelstadt, 2019].

7 Discussion and Conclusion

To support the implementation of EthicASs, we proposed CO-SLEEC, an approach based on context-oriented design and adaptation, targeting the ROS platform. The approach operationalises SLEEC rules in autonomous systems to foster socially responsible behaviour and transparent adaptation. CO-SLEEC has been evaluated in the context of a multiservice robot operating in two different settings, presenting different SLEEC concerns. Evaluation results show that the approach is correct, efficient, and maintainable.

CO-SLEEC relies on a properly structured coding to preserve the intended semantics of SLEEC obligations when operationalised via COP. While this structure is currently assumed during implementation, future work will explicitly enforce it through static analysis techniques. These mechanisms will enable automatic verification that method implementations conform to the expected structure. From an empirical perspective, future work will consider larger SLEEC rulesets and additional case studies to investigate the scalability of CO-SLEEC and to strengthen the generalisability of the results. Moreover, maintainability is currently assessed using LoC as a proxy measure, which may not fully capture developer effort. Hence, future work will include user studies with developers to provide deeper insights.

Ethical Statement

There are no ethical issues.

Acknowledgments

The authors acknowledge the support of the MUR (Italy) Department of Excellence 2023-2027 for GSSI. For UNIBO, the contribution is partially supported by the Italian Science Fund (FIS3) Starting Grant project FoMaSE - Foundations for Macro-programming-based Software Engineering (Grant No. FIS-2024-00174, CUP J53C25002170001).