Why standard deontic modalities are not enough.
It is common in deontic logic to represent norms with the obligation, prohibition and permission modalities. For instance, it is forbidden to steal.
In some of my publications I used a standard rule engine to program the activation and deactivation of normative positions (a representation of these modalities further restricted with arithmetical constraints) and their enforcement, namely some forbidden actions were sanctioned and other prevented.
However, in computer and robotic systems, deontic modalities are ambiguous since they do not state the type of enforcement the system will perform. For instance, what does it means that it is forbidden to steal? Will the system prevent all my attempts of stealing or will it punish them?
To overcome this situation, I proposed new types of rules with different enforcement meanings. That is, each rule has associated a different resulting behaviour when the system executes them.
I came up with these types of enforcement:
- Obligations
- Expecting: it is the softest type of obligation enforcement. Some agents are waiting for a certain obligation to be fulfilled and the agents that are expected to fulfill it are warned.
- Sanctioning: if the agent have not fulfilled a certain obligation yet, a punishment is applied.
- Forcing: it is the harshest type of obligation enforcement. Given some conditions and currently generated brute events, new brute events are generated in order to fulfill the obligation.
- Prohibitions
- Expecting: it is the softest type of prohibition enforcement. Some agents are waiting for the prohibition to do not be violated, and the agents that are expected to violate it are warned.
- Sanctioning: If an agent violates a prohibition, a punishment is applied. The difference resides in what types of events are sanctioned. Punishing brute events is harder than sanctioning institutional events.
- Ignoring: it is the harshest simple type of enforcement for prohibitions. However, the combination of all types of enforcement for prohibitions is even harder. Some brute events, as they cannot be prevented, are ignored in the process to translate them into institutional events.
- Permissions
- Expecting: some agents are waiting for some institutional events to be generated. The agents that are expected to generate them are informed.
- Allowing: brute events are allowed to be translated into institutional events that cause modifications in the context (or institution).
- Reward: If an agent generates a brute event that is translated into an institutional event, a reward is applied. The difference resides in what types of events are rewarded. Rewarding brute events is softer than reinforcing institutional events.
In language [1][2], I captured all this system behaviour in the following way:
Expectations are captured with normative positions, i.e. representations of obligations, prohibitions and permissions.
Allowing, sanctioning and rewarding are modelled through Event-Condition-Action (ECA) rules. Their meaning is that on the occurrence of some brute events, if conditions hold, then a list of actions are performed by the system. For instance, on waiving a hand if where are in an English auction then the system may consider that I’ve bidded for the auctioned good, it may punish me because the waiving hands is forbidden, or it may reward me as the winner of the auctioned good.
Force rules behave like ECA-rules but also generating new forced brute events.
Then, ignore rules specify the brute events that must not be taken into account when evaluating ECA and force rules.











