2.1 Specification of a basic organization

JaCaMo organizations are programmed in Moise (Hübner et al., Reference Hübner, Sichman and Boissier2007). The organizational model structures the specification of an agent organization along three dimensions (Hübner et al., Reference Hübner, Boissier, Kitio and Ricci2010). The structural dimension specifies roles, groups, and links between roles in the organization. The functional dimension encompasses one or more schemes that elicit how the global organizational goals are decomposed into subgoals and how these subgoals are grouped in coherent sets, called missions, to be distributed to the agents. The normative dimension binds the previous two by specifying the role permissions and obligations for missions. Agents, in fact, are held to explicitly commit to the missions defined in the scheme, thereby taking responsibility for mission goals. Organizational goals are mapped into individual agent goals. Obligations to achieve organizational goals are issued according to the normative specification of the organization and the current state of the system. An obligation is fulfilled when the corresponding goal is achieved by the recipient agent before a given deadline. During the execution of a scheme, the involved goals can be in the state waiting (the goal cannot be pursued yet because it depends on the satisfaction of other goals), enabled (the goal can be pursued; its preconditions have been satisfied), or achieved (the agents were able to achieve the goal). The organizational infrastructure is designed as a part of the environment in which agents are situated by means of some dedicated organizational artifacts, upon which agents can perform operations.

At runtime, the organizational specification is translated into a normative program, written in a specific language, called NOPL (Hübner et al., Reference Hübner, Boissier and Bordini2009, Reference Hübner, Boissier, Kitio and Ricci2010, Reference Hübner, Boissier and Bordini2011). The interpretation of such a program is performed by a dedicated interpreter, included in each organizational artifact, and regulates the functioning of the organization. A normative program in NOPL is composed of: (i) a set of normative facts, either translated from the specification or added dynamically during the execution, (ii) a set of inference rules, and (iii) a set of norms. The specification of normative facts and inference rules follows a syntax that is similar to the ones used in Jason and Prolog. In case of prohibition, norm activation results in the failure of the action which triggered the norm. Otherwise, the result is the emission of an obligation directed toward some agent and concerning a state of the world that the agent ought to bring about.

Let us, now, introduce the running example that we will use along the paper. It is inspired by Christie et al. (Reference Christie2021), an article concerning fault tolerance in MAS. With reference to Figure 1:

Figure 1. The Therapy scenario

In order to implement the example in JaCaMo, it is necessary to realize an organization that involves agents playing the roles patient, doctor, and pharmacist. Such roles are part of the structural specification of the organization (Lines 3–7 in Listing 1). The functional specification of the organization (Lines 16–39) tells how the organizational goal ( $\mathsf{therapy}$ ) is structured into subgoals that are grouped into missions and assigned to roles by way of the normative specification (Lines 40–44). In our case, the subgoals are $\mathsf{consult}$ and $\mathsf{follow\_therapy}$ (assigned to patient), $\mathsf{prescribe}$ (assigned to doctor), and $\mathsf{fill\_prescription}$ (assigned to the pharmacist). In this context, explain(symptoms), send(prescription), and deliver(drugs) are actions executed while pursuing the goals associated with the roles (see Listings 3, 4 and 5). The agents playing the various roles will have plans that allow them to achieve their goals. In our example, in the plan for achieving the subgoal $\mathsf{consult}$ , the patient will explain the suffered symptoms to the doctor, while in the plan for achieving goal $\mathsf{prescribe}$ , the doctor will send the prescription to the pharmacist. Last but not least, for achieving goal $\mathsf{fill\_prescription}$ , the pharmacist will deliver the drugs to the patient. Besides this, we require that $\mathsf{follow\_therapy}$ be achieved within five days after the consult.

Listing 1. Organization structural, functional, and normative specifications.

As usual in JaCaMo, the execution of such plans is coordinated, within the organization, by the emission of obligations, whose activation depends on what occurred that far. By means of a built-in library (see Listing 2), obligations are mapped into agents internal goals that can, then, be practically pursued by the agent, for example, by executing some operations over the environment. In case of success, the corresponding organizational goals are set as achieved by means of the $\mathsf{goalAchieved(...)}$ primitive that is made available by the organizational infrastructure.

Listing 2. JaCaMo library that maps organizational obligations onto agents’ internal goals.

Below, we report a skeleton implementation of a patient agent. The agent can handle two goals, $\mathsf{consult}$ (the doctor) and $\mathsf{follow\_therapy}$ . The former is achieved by executing a plan that simply sends a message to the doctor, which explains the suffered symptoms. The latter involves waiting for medicine delivery, and then taking the prescribed drugs.

Listing 3. Excerpt of the patient agent’s code.

Figure 2. JaCaMo’s conceptual meta-model extended for exception handling. The newly added concepts are highlighted in orange. Orange lines also highlight the mapping among concepts belonging to different dimensions

Similarly, the doctor and the pharmacist pursue their assigned goals as sketched hereafter.

Listing 4. Excerpt of the doctor agent’s code.

Listing 5. Excerpt of the pharmacist agent’s code.

2.2 Adding exceptions

Let us, now, see how exception specification and exception handling are introduced in the picture. Figure 2 reports the meta-model of our proposal. It enriches a previous meta-model, described in Baldoni et al. (Reference Baldoni, Baroglio, Micalizio and Tedeschi2022), with elements that were disregarded in that proposal, like the environment dimension and the mapping between concepts belonging to different dimensions, thus providing a complete picture. Such a mapping is central in the implementation of the infrastructure (for details, please, check Section 3).

In Baldoni et al. (Reference Baldoni, Baroglio, Micalizio and Tedeschi2022), an exception is a piece of information that concerns the result of an operation, which is needed to interpret such a result and to identify the right prosecution. The functional specification of the organization includes, in the scheme, a set of notification policies, whose general template is reported in Listing 6. A notification policy concerns an organizational goal (target) and specifies an activation condition (condition): a logical formula that encodes the state of the organization, and the target goal in particular, in which the policy must be applied. Such conditions can amount to the failure, the delay, the achievement of a goal or some combination. Table 1 contains some relevant types of condition together with their corresponding NOPL formulas: clause $\mathsf{scheme\_id(S)}$ identifies the functional decomposition scheme instance to which the condition refers. Placeholders starting with $ represent goal identifiers. Other conditions can be expressed as well, by directly specifying the corresponding NOPL formula as attribute. Note that it is possible to define many notification policies having the same goal as target, each having a different activation condition. In addition, a notification policy includes the definition of one or more exceptions that can possibly be raised, by means of the dedicated tag $\mathsf{report}$ . Each report specifies the structure of the information that will be exchanged, together with some raising and handling goals. Raising and handling goals are subject to further conditions that control their use.

Table 1. Condition types for notification policies. When the organization is made of a single functional decomposition scheme instance $\mathsf{scheme\_id(S)}$ can be omitted

Listing 6. XML template for notification policies. $+$ indicates one or more occurrences of the element between square brackets, $*$ indicates zero or more occurrences, and $?$ indicates optional elements.

Let us now explain each field of a notification policy.

Reports capture the shape of the information that the agents responsible for raising the exception have to provide to those in charge for handling it (i.e., the feedback Hagen & Alonso, Reference Hagen and Alonso2000; Alderson & Doyle, Reference Alderson and Doyle2010). More in detail, reports include a set of arguments—predicates (with their arity) that must be instantiated and made available by the raising agents. Intuitively, a report is a form to be filled in by the agents in charge of raising the exception. The filled form amounts to the actual exception that is raised and made available to the handling agents. If a report includes multiple arguments, we assume that all of them will be instantiated. Each report also includes at least one raising goal and at least one handling goal. These are the organizational goals through which the exception is managed. Note that a single notification policy may include many reports. This feature is, for instance, handy when the system designer deals with events showing many facets, with possibly many consequences on the system. It will require several (generally uncoordinated) actions, by different agents, to properly tackle all of them at system level.

Raising goals and handling goals, denoted by tags $\mathsf{raise-goal}$ and $\mathsf{handle-goal}$ , are the organizational goals that allow managing exceptions. As standard goals in JaCaMo, raising and handling goals are included in missions, to which the agents, that play organizational roles, commit. Each report contains at least one raising goal and one handling goal, but it may encompass many of both types. So, the same exception could be raised (and handled) in different ways in different circumstances, which are captured by the optional when clause, whose value corresponds to a state of the organization in which it makes sense to pursue that goal. Such a state amounts to a logical formula in NOPL, just like policy conditions (see Table 1).

Note that the act of raising an exception may require the joint efforts of many agents, as well as many agents may be involved in handling a raised exception. The involved agents may each be requested to carry out the same action, or they may be distributed different tasks which altogether produce the desired outcome. Thus, for each raising and handling goals, there may be many committed agents (exploiting JaCaMo’s mission cardinality). Finally, raising and handling goals (like all goals in JaCaMo) might be structured, that is, they might be composed of many sub-goals, requiring the collaboration of many agents to collect and make the relevant information available.

The management of exception raising and handling through obligations and through the normative system of the MAO clearly identifies agents’ responsibilities. In general, the agent that detects the conditions that will lead to raising an exception might not be equipped with the means to properly address the situation. It might not be able to determine the impact of the situation on the overall system. The exception handling mechanism we have introduced allows conveying relevant contextual information to those agents that are actually equipped with the means to promptly tackle them. This might be a complex process, involving many agents engaged in complex workflows. This is achieved by exploiting JaCaMo’s standard notions of goal cardinality and decomposition.

Let us, now, illustrate the specification of notification policies with reference to the Therapy scenario and to Figure 3.

Figure 3. The Therapy scenario extended with exception handling

The failure of the patient’s goal $\mathsf{follow\_therapy}$ may be due to different circumstances:

1. 1. The doctor did not receive the symptoms sent by the patient;

2. 2. The doctor received the symptoms, but did not produce the prescription;

3. 3. The pharmacist filled the prescription, but the medicine did not arrive to the patient;

4. 4. The pharmacist delayed the preparation of the medicine;

5. 5. The pharmacist did not receive the prescription produced by the doctor.

These situations cause the failure of one or more organizational goals. We use these failures to discriminate between alternative exceptions and how to handle them. At the level of the organizational specification, we specified a notification policy (Listing 7) and added it to the scheme in Listing 1, with target $\mathsf{follow\_therapy}$ and with activation condition unfulfilled(obligation(_, _, done(_, follow_therapy, _), _)). In our scenario the deadline was missed, and indeed this condition corresponds to the condition type ‘goal delay’ in Table 1 (the scheme reference is omitted for brevity).

Cases (1) and (2) are detected by goal $\mathsf{prescribe}$ not being satisfied. In these cases, the patient is the one who must raise the exception, informing the doctor that the symptoms went lost: the patient will supply the date of the sending so that the doctor will sort out what happened (the doctor handles the exception). In Figure 3, this part is represented by the dotted red arrows. In the notification policy, the exception is specified with the name $\mathsf{exception\_lost\_symptoms}$ (see Lines 3–8 in Listing 7). The report includes two arguments, the date and the list of symptoms, the raising goal $\mathsf{raise\_exception\_lost\_symptoms}$ that can be raised when condition not satisfied(_, prescribe) holds, and the handling goal $\mathsf{handle\_exception\_lost\_symptoms}$ . The raising and handling goals are part of missions, see Lines 27–38 in Listing 7. Missions are associated with roles through the normative specification at Lines 40–44 in Listing 1.

Cases (3) and (4) become of interest when $\mathsf{prescribe}$ is satisfied, but the patient has not received the medicines. The patient should, in this cases, raise an exception toward the pharmacist (who will have the role of exception handler). This is possible because in JaCaMo a goal state is a public observable property of the organizational artifacts, so a patient can know whether a prescription was done by looking at the state of the organizational goal $\mathsf{prescribe}$ . The patient will supply the date of the consult and the doctor’s name, so that the pharmacist can sort out what happened.

The pharmacis has two handling goals because it may either be the case that the prescription was filled (and the delivery failed), or the prescription for some reason has not been filled yet. The latter case may be due to the pharmacist, who is late and will then solve the problem. However, it may also be due to some error in the communication of the prescription from the doctor, which amounts to case (5). In this case, the pharmacist will, in turn, raise an additional exception toward the doctor, containing the patient’s and doctor’s names and the date of the consultation at issue, to solve the problem. This can be done by declaring the failure of the pharmacist’s goal $\mathsf{fill\_prescription}$ . In Figure 3, dotted blue arrows capture cases (3) and (4), while dotted green arrows capture case (5). In the notification policy, $\mathsf{exception\_no\_delivery}$ includes the date and the name of the doctor, as arguments. It includes the raising goal $\mathsf{raise\_exception\_no\_delivery}$ that can be raised when the condition satisfied(_, prescribe) holds. Such a condition corresponds to the type ‘goal achievement’ in Table 1. The exception specification also includes two handling goals. The first, $\mathsf{handle\_exception\_no\_delivery}$ , is used when the pharmacist has filled the prescription. The second, $\mathsf{handle\_exception\_no\_delivery\_no\_fill}$ , is used when the pharmacist has not satisfied the goal $\mathsf{fill\_prescription}$ , and will have to understand whether it is its fault or a lack of communication from the doctor. This last case calls for the specification of a further report, called $\mathsf{exception\_missing\_prescription}$ , which has two arguments: the patient’s name, and the date of the consultation. It includes the raising goal $\mathsf{raise\_exception\_missing\_prescription}$ that can be pursued when satisfied(_, prescribe) and failed(_, fill_prescription). The handling goal, $\mathsf{handle\_exception\_missing\_prescription}$ , is up to the doctor.

Listing 7. Notification policy for the Therapy scenario.

2.3 Agent programming with exceptions

Now coming to agent programming, Listing 8 shows the extended implementation of the patient agent, where the first two exceptions are raised.

Listing 8. Excerpt of the patient agent’s code extended with exception handling.

The first three plans allow the agent to pursue its assigned goals from the functional decomposition, while the last two are related to exception handling. More in detail, as soon as the scheme execution starts the agent receives two obligations: to pursue goals $\mathsf{consult}$ and $\mathsf{follow\_therapy}$ . The obligations are automatically mapped onto the agent internal goals and the corresponding plans are activated. It is worth noting that the agent is able to successfully complete the plan at Line 7 only if the drugs are received from the pharmacist (see the plan context). Should this not happen before five days, the obligation to achieve goal $\mathsf{follow\_therapy}$ would become unfulfilled. Consequently, the notification policy in Listing 7 would be triggered (see line 1). This causes the emission of new obligations concerning the raising/handling of exceptions.

In our case, the patient is able to raise two exceptions ( $\mathsf{exception\_lost\_symptoms}$ and $\mathsf{exception\_no\_delivery}$ ), but it will actually raise only one of the two, depending on the context. The last two plans in the agent code serve this purpose: the agent raises the appropriate exception by means the primitive $\mathsf{raiseException(...)}$ (Lines 12 and 16), which takes in input a list of arguments that complies with the expected report specification. Such arguments are made available to the handler agents as observable properties of the organizational artifacts.

When raising $\mathsf{exception\_lost\_symptoms}$ , the agent will have to provide the consultation date and the symptoms, while when raising $\mathsf{exception\_no\_delivery}$ , the agent will have to provide the date and the doctor’s name. The reason is that the first exception is to be handled by the doctor, while the second by the pharmacist. Since the pharmacist may receive prescriptions from multiple doctors, the information is needed to identify the right one. This example shows that report arguments encode relevant contextual information that must be provided from the raiser to the handler in order to allow the latter to cope with the exception at hand.

The achievement of a raising goal implies the emission of an obligation toward the agents that should achieve the associated handling goals. In our example, the raising of $\mathsf{exception\_lost\_symptoms}$ enables the handling goal $\mathsf{handle\_exception\_lost\_symptoms}$ , which is in charge to the doctor. The exception $\mathsf{exception\_no\_delivery}$ , in turn, encompasses two different handling goals (in charge to the pharmacist). As explained the two goals are enabled in different circumstances, that are specified by the $\mathsf{when}$ condition.

Listing 9 below reports the code of the pharmacist agent, extended for handling the $\mathsf{exception\_no\_delivery}$ , raised by the patient.

Listing 9. Excerpt of the pharmacist agent’s code extended with exception handling.

The plans at Lines 5, 9, and 14 target the handling goals. The first one is triggered when the agent, which has filled the prescription, receives the exception that was raised by the patient. This means that the drugs went lost before reaching the patient. The exception is handled by organizing another delivery of the prescribed drugs.

The remaining two plans capture cases (4) and (5) in Example 2. Here the pharmacist did not fill the prescription. This could be due to many reasons, we consider two alternatives: (1) the preparation for some reason was delayed and (2) the pharmacist did not receive the prescription from the doctor. The two plans in Listing 9 tackle the two cases. While in the first case the exception is handled totally and directly by the pharmacist that will simply fill the delayed prescription, the second case is more complex. The agent cannot activate the plan to achieve the goal $\mathsf{fill\_prescription}$ because the context at Line 1 does not hold. The agent, thus, marks the organizational goal as failed by means of the $\mathsf{goalFailed(...)}$ operation, at Line 15. This operation is provided by our the extended infrastructure and allows agents to proactively signal the failure of their organizational goals. The failure triggers the raising of a further exception (the last one specified in the notification policy). According to the policy, $\mathsf{exception\_missing\_prescription}$ must be raised by the pharmacist and handled by the doctor. The plan at Line 17 allows the agent to raise the exception. It is worth noting that the pharmacist may leverage the arguments provided beforehand by the patient while raising the previous exception (see the plan context). In this case, the date of the prescription and the patient’s and doctor’s names are forwarded to the doctor.

Finally, Listing 10 shows the doctor’s code, extended with exception handling. The agent includes two plans that allow it to handle both the exceptions raised by the patient and by the pharmacist. To do so, the agent must achieve the corresponding handling goals. Here, we see again that the agent can leverage the information provided by the exception (i.e., the list of lost symptoms) to determine what has to be done.

Listing 10. Excerpt of the doctor agent’s code extended with exception handling.

3.1 Encoding notification policies in the normative program

Notification policies are specified in XML, but need to be translated into norms and rules to be interpreted by the normative system at runtime. To allow this to happen, we introduced some new organizational facts which allow capturing the notification policy structure. Table 2 lists them, together with an explanation of their meaning. So, for instance, $\mathsf{notificationPolicy(NP,Target,Condition)}$ is used to capture the fact that $\mathsf{NP}$ is a notification policy that concerns the goal $\mathsf{Target}$ and is activated when the specified condition holds (for instance, when the target goal fails). These facts, however, are not sufficient because we also need to capture dynamic facts that occur at runtime. These dynamic facts are produced as a consequence of specific operations performed by agents on some artifacts and regard the raising and handling goals.

Table 2. Normative facts capturing notification policies

For example, we just mentioned that a notification policy condition may amount to the failure of some goal, but standard JaCaMo only allows agents to mark goals as achieved, and hence we had to extend it to widen the set of goal states. In particular, we introduced the new artifact operation $\mathsf{goalFailed(G)}$ , by which an agent can signal the failure of goal $\mathsf{G}$ . As a consequence, the dynamic fact $\mathsf{failed(S,G)}$ is added in the normative state. Such a fact can appear in conditions triggering notification policies.

3.2 Enabling and accomplishing raising goals

At runtime, the normative systems checks, for each report in an active notification policy (i.e., with $\mathsf{Condition}$ satisfied), the presence of applicable (exception) raising goals. That is, raising goals whose $\mathsf{when}$ clause holds. This check is performed by means of the following rule.

A raising goal $\mathsf{RG}$ is enabled when the $\mathsf{Condition}$ defined for the policy it belongs to, as well as its local $\mathsf{When}$ condition, hold, provided that its dependencies (preconditions) are satisfied. The predicate $\mathsf{dep(...)}$ is built-in NOPL and encodes the dependencies of a given goal, that is, the other goals that must be achieved (or released) before the goal can be pursued. Dependencies are deduced automatically from the functional decomposition.

Once a raising goal is enabled, the normative system issues an obligation to the involved agent(s). Although this mechanism is common to all goals, raising goals are special because they produce a piece of knowledge—an exception—that is compliant with the report that is given in the notification policy, to which the raising goal at issue belongs. To perform this, we introduced a new artifact operation: $\mathsf{raiseException(E,Args)}$ allows an agent to raise an exception $\mathsf{E}$ with a list of arguments $\mathsf{Args}$ . Arguments are a set of ground predicates having the structures specified by facts $\mathsf{reportArgument(E, Functor,Arity)}$ for the report for exception $\mathsf{E}$ . The operation adds to the normative state the dynamic fact $\mathsf{raised(E,Ag,Args)}$ , where $\mathsf{Ag}$ is the name of the agent executing the operation and $\mathsf{Args}$ are the provided exception arguments. Note that the raised exception, together with its arguments is also made available to the other agents as an artifact observable property which has the shape $\mathsf{raised(E,Args)[raiser(Ag)]}$ .

3.3 Enabling and accomplishing handling goals

Raised exceptions must be handled, so, when an exception is raised, the normative system looks for handling goals that are enabled. This is done by means of the following rule.

Similarly to raising goals, a handling goal is enabled if its $\mathsf{When}$ condition holds, and if the precondition goals are satisfied. We additionally require that an exception has actually been raised, and that the corresponding raising goal has been satisfied. In this way, we ensure that the agent to which the handling goal is assigned, is able to take advantage of the information provided by way of the raising goal. It is possible that many handling goals are concurrently enabled for the same raised exception. Obligations are, then, issued for each enabled handling goal. The involved agents can leverage the information, encoded by the raised exception, to enact the most appropriate countermeasures and handle the exception.

In particular, the achievement of a handling goal could make no longer needed the goal whose failure triggered the exception. In such a case, the failed goal must be skipped. The new artifact operation $\mathsf{goalReleased(G)}$ allows agents to release an organizational goal $\mathsf{G}$ . It adds to the normative state the fact $\mathsf{released(S, G)}$ . Executing this operation allows the appointed agents to notify the organization that the exception was handled. The execution of the scheme $\mathsf{S}$ can proceed because $\mathsf{G}$ is not of interest anymore. This allows resuming the process, aimed at the achievement of the organizational goal, which would, otherwise, remain stuck.

It is worth noting that releasing a failed goal is just a possibility. For instance, as an alternative the handling agent could decide to retry its achievement by resetting it, after the restoration of a consistent context. Of course, the choice for the best way to handle an exception is up to the agent that should handle it.

3.4 Norms for dealing with exceptions

As a final step, we had to provide the normative program with the norms needed to issue obligations toward agents for raising and handling goals and to ensure a set of properties that guarantee the correct functioning of the exception handling mechanism. To illustrate, some of these norms ensure that only designated agents can raise or handle specific exceptions, or that an exception can be raised only if the condition of the enclosing notification policy actually holds. We recall that a norm is composed of a name, a set of facts that represent the activation condition of the norm, and a consequence condition. The consequence of a norm activation can be either the emission of an obligation or a failure. In the latter case, this results in the failure of the action that triggered the norm.

The first addition concerns the achievement of raising and handling goals, which is to be coordinated through obligations by the normative system—as for any other organizational goal. In order to allow a proper management, we had to modify the standard built-in norm for goal achievement, as reported in Listing 11: the norm does not issue anymore obligations concerning goals marked as failed or released (Lines 8–9).

Listing 11. NOPL norm issuing obligations to achieve goals.

Briefly, the norm says that if agent $\mathsf{A}$ is committed to mission $\mathsf{M}$ in scheme $\mathsf{S}$ and $\mathsf{G}$ is one of the mission goals (Line 3), such that $\mathsf{G}$ is either an achievement or a performance goalFootnote ² (Lines 4–5), the scheme is well-formed (Line 6), and $\mathsf{G}$ is ready to be achieved, then an obligation directed toward $\mathsf{A}$ to achieve $\mathsf{G}$ must be emitted (Line 11). Note that in JaCaMo a scheme is well-formed when all the mission minimum and maximum cardinalities are respected, that is, when all the needed role-player agents have committed to their missions. Instead, a goal is considered ready for achievement as soon as it is enabled and it has not been already achieved, marked as failed or released, or its super-goal has been achieved (Lines 7–10).

We finally added some regimented norms to ensure consistency in the treatment of raising and handling goals. Regimented norms in Moise are those norms that result in a failure if the norm preconditions are not holding when the norm is triggered. Such norms ensure that agents cannot perform undesired actions. Specifically, the newly introduced norms are needed in order to ensure that agents only raise and handle exception that follow the specification. They can be divided into three groups: (i) norms that govern when exception can be raised, (ii) norms that govern what agents can raise exceptions, and (iii) what shape raised exceptions need to have.

The first group of norms deals with the fact that agents should be prevented from marking as “failed” goals that are not enabled, yet. Similarly, we also impose that exceptions can only be raised when an exceptional situation actually occurs, and not arbitrarily by the agents. The norm in Listing 12 regiments a failure if an agent tries to mark as failed an goal which is not enabled.

Listing 12. NOPL norm regimenting goal failure.

The norm in Listing 13, in turn, ensures that fact $\mathsf{raised(E, Ag, Args)}$ is asserted into the state of the organization only when the condition of the corresponding notification policy holds. It is worth noting that we allow the condition not to hold if the raising goal has been already achieved by some agent (Line 5).

Listing 13. NOPL norm regimenting exception raising conditions.

The rationale is that, after a successful handling of the exception the critical condition will likely stop holding. Nonetheless, the fact $\mathsf{raised(E, Ag, Args)}$ , together with $\mathsf{done(S, RG, Ag)}$ , keeps track of the fact that an exceptional situation occurred (and has been handled). $\mathsf{done(S, G, Ag)}$ is a built-in NOPL dynamic fact that is added to the normative program to denote that agent $\mathsf{Ag}$ has achieved goal $\mathsf{G}$ in scheme $\mathsf{S}$ .

The second group of norms ensure that only the designated agents can raise exceptions. The norm in Listing 14 inhibits the raising of exceptions by agents not committed to the mission including the corresponding raising goal.

Listing 14. NOPL norm regulating agents allowed to raise exceptions.

Finally, the last group of norms checks that exceptions, that are raised, are compliant with the specification. This check is not trivial and requires a number of rules. First of all, since raising goals must produce an exception (which is a piece of knowledge), they can be marked as “achieved” only when the corresponding exception has been provided by the raising agent.

The norm in Listing 15 ensures that a raising goal is marked as ‘achieved’ only when the corresponding $\mathsf{raised(...)}$ fact has been asserted. More in detail, a raising goal $\mathsf{RG}$ is not marked as achieved in those cases when the fact $\mathsf{done(S, RG, Ag)}$ is added to the normative state but the related exception has not been raised (see Line 5), because the goal achievement operation fails.

Listing 15. NOPL norm regulating the achievement of raising goals.

Note that raising goals may be composite, encompassing multiple subgoals, just like standard organizational goals. In this case, before achieving the root goal, all subgoals must be completed. When a raising goal is composite and require multiple subtasks, we require that the exception is actually raised before marking the root goal as achieved (see Listing 15, Line 4).

The norm in Listing 16 ensures that exceptions can be raised only by following a well-defined report specification.

Listing 16. NOPL norm regimenting the raising of unknown exceptions.

Note that a fact of kind $\mathsf{raised(...)}$ can be asserted only when the right number of corresponding arguments has been asserted. Of course, each of them must comply with the expected format. This is verified by the norms in Listings 17–19. The one in Listing 17 ensures that the arguments of a $\mathsf{raised(E, Ag, Args)}$ predicate are ground predicates, i.e., they do not contain variables.

Listing 17. NOPL norm regimenting exception arguments groundness.

The norm in Listing 18 ensures that all the relevant information is provided, that is, that all the required arguments are instantiated.

Listing 18. NOPL norm regulating the absence of required exception arguments.

Like in Prolog, the NOPL construct $\mathsf{P= ..[F, T, A]}$ , used at Line 5, extracts the functor $\mathsf{F}$ , terms $\mathsf{T}$ , and eventually annotations $\mathsf{A}$ from a predicate $\mathsf{P}$ . The norm triggers a failure if at least one of the arguments specified for $\mathsf{E}$ does not unify with one of the terms in the list $\mathsf{Args}$ of dynamic fact $\mathsf{raised(E, Ag, Args)}$ . Indeed, this means that some of the information the agent was requested to provide is still missing.

The last norm, Listing 19 regiments the prohibition, for agents, to include undesired arguments when raising of an exception.

Listing 19. NOPL norm prohibiting undesired exception arguments.

The norm is triggered if an exception $\mathsf{E}$ is raised by some agent with a set of arguments $\mathsf{Args}$ and (at least) one of the arguments included in $\mathsf{Args}$ does not follow the specification for exception $\mathsf{E}$ (i.e., a corresponding $\mathsf{reportArgument(...)}$ fact is not present, see Lines 4–7). The result of all these norms is a failure in the exception raising action.