Social, Legal, Ethical, Empathetic and Cultural Norm Operationalisation for AI Agents

This paper proposes a systematic framework for operationalizing social, legal, ethical, empathetic, and cultural (SLEEC) norms into concrete, verifiable requirements for AI agents, while surveying current methods and outlining a research agenda to bridge the gap between abstract normative principles and practical implementation in high-stakes domains.

The Gist

Imagine you are building a robot butler named "Robo-Bob." You want him to help an elderly person cook dinner, call for help if they fall, and chat about their day. But here's the catch: Robo-Bob isn't just a machine; he's entering a human world.

If Robo-Bob gets it wrong, the consequences aren't just a "404 Error." They could be a violation of privacy, a breach of trust, or even a life-or-death situation.

This paper by Calinescu and colleagues is essentially a blueprint for teaching robots how to be "good citizens." It argues that we can't just program a robot to be efficient; we have to program it to respect Social, Legal, Ethical, Empathetic, and Cultural (SLEEC) norms.

Here is the simple breakdown of their idea, using some everyday analogies.

The Problem: The "Vague Rulebook"

Currently, we have big, fancy rulebooks for AI (like the UN's guidelines or the EU's AI Act). These are like saying, "Be kind," "Respect privacy," and "Don't hurt anyone."

The Analogy: Imagine you hire a new employee and tell them, "Be a good person." That's great in theory, but if you don't give them specific instructions on how to be good in specific situations (e.g., "If the boss is crying, offer a tissue, don't ask for a raise"), they might accidentally do the wrong thing.

The authors say: "We need to translate 'Be a good person' into specific, checkable code." They call this Operationalisation.

---

The Solution: The 5-Step "Robot Training Camp"

The paper proposes a strict, 5-step process to ensure the robot is ready for the real world. Think of this as a rigorous training camp for Robo-Bob.

Step 1: The "What Can You Do?" Check (Capability Specification)

Before we teach the robot rules, we need to know what tools it has.

• The Analogy: Before you teach a driver how to navigate a city, you need to know if they have a car, a map, or just a bicycle.
• In the Paper: Does the robot have a camera? A microphone? Can it call 911? If it has a camera, it must respect privacy. If it can call 911, it must know when it's safe to do so.

Step 2: The "Stakeholder Roundtable" (Requirement Elicitation)

This is where we turn vague ideas into specific rules. The authors suggest gathering ethicists, lawyers, doctors, and regular users to write the rules together.

• The Analogy: Imagine a town hall meeting to write the rules for a new park. The lawyer says, "No dogs off-leash." The parent says, "Kids need to run free." The dog owner says, "My dog is friendly." They negotiate until they have a clear rule: "Dogs must be on a leash unless in the fenced area."
• In the Paper: They translate "Respect Autonomy" into a specific rule: "If the user falls, call for help UNLESS the user says 'No, I'm fine' (and is conscious)."

Step 3: The "Logic Police" (Well-Formedness Checking)

This is the most critical step. Humans are bad at spotting contradictions in complex rules. Computers are good at it.

• The Analogy: Imagine you write a rulebook that says:
  1. "If it rains, close the window."
  2. "If it's windy, open the window."
  3. "If it's raining AND windy, do nothing."
     A human might miss that these rules fight each other. A computer checks the logic and says, "Wait, if it's raining and windy, you can't do nothing; you have to choose!"
• In the Paper: They use special math tools to find "bugs" in the ethical rules. For example, they found a conflict where a robot might be told not to call help if a user says "no," but what if the user is unconscious? The computer spots this gap and forces the team to fix the rule before moving on.

Step 4: The "Coding & Guardrails" (Implementation)

Now, we actually build the robot with these rules baked in.

• The Analogy: You don't just tell the driver "Drive safely." You install speed limiters and blind-spot sensors in the car. These are "guardrails." Even if the driver (the AI) tries to speed, the car stops them.
• In the Paper: The rules are turned into code that runs alongside the AI. If the AI tries to do something unethical, the "guardrail" blocks it.

Step 5: The "Final Exam" (Verification)

Before the robot goes to the user's house, it takes a test.

• The Analogy: Before a pilot flies passengers, they do a simulator check. The computer runs thousands of scenarios: "What if the user falls? What if the fire alarm goes off? What if the user is asleep?"
• In the Paper: They mathematically prove that the robot cannot break the rules. If it fails the test, the project is cancelled. Yes, cancelled. It's better to stop a robot than to let a "bad" robot loose.

---

The "Running Example": The Care Robot

The paper uses a real example: A robot helping an elderly person with Alzheimer's.

• Scenario A: The robot sees the person fall.
  • Bad Robot: Calls 911 immediately. (Maybe the person just sat down and is annoyed).
  • SLEEC Robot: Checks if the person is conscious. If yes, asks, "Do you need help?" If they say "No," it waits. If they say "Yes" or don't respond, it calls 911.
• Scenario B: The fire alarm goes off.
  • Bad Robot: Asks the user for permission to call the fire department. (Too slow!).
  • SLEEC Robot: Has a "Defeater" rule. Even if the user says "No," the fire alarm overrides the "No" because safety is the highest priority.

The Big Challenges (The "But..." Section)

The authors admit this is hard. Here are the hurdles:

1. The Translation Gap: Turning "Human Dignity" into computer code is like trying to translate a poem into a spreadsheet. It's messy.
2. The "What If" Problem: You can't write a rule for every possible situation in the universe (as Alan Turing noted).
3. The Speed Problem: Human ethics take seconds to think about; robots make decisions in milliseconds. How do you make a robot "think" ethically that fast?
4. The Team Problem: We need engineers who understand ethics, and ethicists who understand code. Right now, they speak different languages.

The Bottom Line

This paper is a call to action. It says: "Stop treating AI ethics as a fluffy afterthought."

If we want AI to be safe and trusted, we need a systematic, rigorous, and mathematical process to build it. It's not enough to hope the robot is "nice." We have to prove, step-by-step, that it is compliant with our human values. If we can't prove it, we shouldn't build it.

In short: It's the difference between hoping your car has brakes and actually testing them before you let your kids ride in it.

Technical Summary

1. Problem Statement

As AI agents are deployed in high-stakes domains (healthcare, law enforcement, autonomous vehicles), they face a critical engineering challenge: translating abstract, high-level Social, Legal, Ethical, Empathetic, and Cultural (SLEEC) norms into concrete, verifiable technical requirements.

• The Gap: International frameworks (e.g., OECD, UNESCO, IEEE) provide high-level principles (e.g., privacy, autonomy, non-maleficence) but lack mechanisms to operationalize these principles for specific AI contexts.
• The Limitation of Current Methods: Traditional requirements engineering is ill-equipped to handle the complexity of SLEEC norms. It fails to engage diverse stakeholders (ethicists, lawyers, users), manage subtle conflicts between norms, and provide formal guarantees of compliance.
• The Consequence: Without a systematic process, AI agents may violate human values, prioritize conflicting goals incorrectly, or fail to adapt to cultural and empathetic nuances.

2. Methodology: The SLEEC-Norm Operationalisation Process

The authors propose a systematic, iterative five-stage process to bridge the gap between abstract principles and deployed AI agents. The process is illustrated in Figure 1 of the paper and is demonstrated using a running example: the ALMI (Ambient Assisted Living for Long-term Monitoring and Interaction) assistive care robot.

Stage 1: AI Agent Capability Specification

• Goal: Define the functional capabilities of the agent that influence SLEEC norms.
• Activities:
  1. Identify capabilities determining which norms are relevant (e.g., a camera implies privacy concerns).
  2. Identify capabilities needed to satisfy norms (e.g., a "duty of care" requires communication channels to alert help).
• Output: A list of informally specified capabilities and use cases (e.g., MealTime, HumanOnFloor, userOccupied).

Stage 2: SLEEC Requirements Elicitation

• Goal: Translate abstract principles into actionable operational rules.
• Activities:
  1. Identification: Select high-level principles (e.g., autonomy, beneficence) from governance frameworks.
  2. Proxy Derivation: Map principles to actionable placeholders (e.g., "Human Autonomy" $\rightarrow$ "Obtaining Assent").
  3. Rule Definition: Formulate rules using a SLEEC Domain-Specific Language (DSL).
     • Base Rule Structure: id when triggerEvent [and triggerGuard] then response [within timeframe]
     • Defeaters: Mechanisms to handle exceptions: unless defeaterGuard [then defeaterResponse].
• Output: A comprehensive set of SLEEC rules (e.g., Rule R3: Call emergency support if a fall is detected, unless the user does not assent).

Stage 3: SLEEC Requirements Well-Formedness Checking

• Goal: Detect and resolve conflicts, redundancies, and logical flaws in the rule set before implementation.
• Activities: Two complementary formal methods are applied:
  1. Process-Algebraic Approach: Maps rules to tock-CSP (Communicating Sequential Processes). Uses the FDR model checker to detect pairwise conflicts (rules that cannot both be obeyed) and redundancies.
  2. Logic-Based Approach: Encodes the rule set into First-Order Logic with Relational Objects (FOL)*. Uses the LEGOS satisfiability checker to analyze global interactions, detecting insufficiency (failure to prevent harm) and over-restrictiveness (blocking necessary actions).
• Outcome: Debugging and refining rules. For example, the paper identifies that a strict "no assent = no help" rule prevents helping an unresponsive person. The rule is refined to check for userResponsive alongside not humanAssents.

Stage 4: SLEEC-Aware AI Agent Implementation

• Goal: Integrate validated requirements into the agent's design, training, and runtime.
• Activities:
  • Mapping: Translate abstract capabilities into implementable abstractions (sensor events, internal states).
  • Training: Structure dataset schemas to explicitly encode compliant vs. non-compliant scenarios (e.g., falls with/without assent).
  • Runtime Guardrails: Implement the rules as external monitors that constrain agent actions and handle defeaters. These guardrails are decoupled from core logic to allow updates without full retraining.

Stage 5: Verification of AI Agent Compliance

• Goal: Formally verify that the implemented agent satisfies the SLEEC rule set.
• Activities:
  • Use RoboChart (a diagrammatic modeling language with tock-CSP semantics) to model the agent.
  • Apply model checking to verify conformance between the agent model and the SLEEC rules.
  • Generate counterexamples if violations are found (e.g., a trace showing the agent delayed an emergency call because it was finishing a non-critical task).
• Outcome: Successful verification leads to deployment; failure leads to project cancellation or redesign.

3. Key Contributions

1. A Systematic Operationalisation Framework: The paper defines the first end-to-end process (Stages 1–5) for transforming high-level SLEEC principles into verifiable AI requirements.
2. Formal Methods Integration: It introduces the use of tock-CSP and FOL* specifically for SLEEC rule analysis, providing mathematical guarantees for conflict resolution and well-formedness.
3. The SLEEC DSL: A specialized language for expressing normative rules with triggers, guards, responses, and defeaters, making complex ethical logic accessible to both technical and non-technical stakeholders.
4. Tooling Ecosystem: The authors highlight and utilize a suite of tools (SLEEC-TK, LEGOS-SLEEC, RoboChart, FDR) that automate the verification and debugging of normative requirements.
5. Case Study Validation: The framework is rigorously applied to the ALMI assistive robot, demonstrating how to handle real-world conflicts (e.g., privacy vs. safety, autonomy vs. duty of care).

4. Results and Findings

• Conflict Resolution: The methodology successfully identified and resolved a critical conflict in the ALMI robot: a rule preventing emergency calls without assent conflicted with the safety requirement to help an unresponsive person. The formal analysis suggested a refined rule requiring a check for user responsiveness.
• Verification Success: The verification stage successfully detected a timing violation where the robot prioritized a non-critical task over an emergency response, generating a counterexample trace that forced a design revision.
• Process Iteration: The study demonstrated that the process is inherently iterative; failures in Stage 3 (well-formedness) or Stage 5 (verification) necessitate returning to earlier stages to refine capabilities or rules.
• Project Cancellation as a Positive Outcome: The framework acknowledges that if a SLEEC-compliant agent cannot be engineered (due to irreconcilable conflicts or technical infeasibility), the process should halt the project. This is framed as a positive outcome to prevent the deployment of harmful AI.

5. Significance and Future Directions

• Engineering Rigor: The paper shifts AI ethics from philosophical discussion to engineering practice, providing a verifiable path to "Trustworthy Autonomous Systems."
• Research Agenda: It outlines critical open challenges:
  • Reification: Bridging the gap between abstract global principles and specific technical specs.
  • Value Conflicts: Developing deliberative methods to resolve normative frictions and establish value hierarchies.
  • Runtime Adaptation: Enabling agents to dynamically update behaviors based on new cultural or user-specific norms without losing formal guarantees.
  • Competence: The need for multidisciplinary education to ensure engineers, lawyers, and ethicists share a common language.
• Policy Impact: The framework serves as a blueprint for regulators and policymakers to mandate not just "ethical AI" in principle, but "compliant AI" in practice, potentially influencing future iterations of the EU AI Act and other regulations.

In summary, this paper provides a foundational methodology for ensuring that AI agents are not only functionally capable but also demonstrably aligned with the complex web of human social, legal, and ethical norms.