A Contract Management Framework for Supervised
Interaction
Martin J Kollingbaum, Timothy J Norman
Department of Computing Science, University of Aberdeen, Aberdeen, Scotland, UK, AB24 3UE
{mkolling,tnorman}@csd.abdn.ac.uk
Abstract. This paper introduces a Normative Agent Architecture as an appropriate contract management framework for Supervised Interaction. Supervised interaction is concerned with the problem of establishing trust between contracting agents in electronic markets. It is designed to put safeguards in place that ensure that errant behaviour in business transactions is either prevented or sanctioned. Supervised Interaction consists of three elements: an organisational framework, a contract specification language and a contract management protocol. The normative agent architecture has to meet certain requirements to allow agents to engage in business transactions according to Supervised Interaction. These requirements are, among others: understanding of normative behaviour specifications within contracts and their correct execution, and goal generation and plan selection based on norms.
1 Introduction
The normative agent architecture (NoA) introduced in this paper is designed for the implementation of normative agents. Normative agents are motivated by norms that express their obligations, permissions and prohibitions under specific circumstances towards other agents within an agent society.
Supervised Interaction (introduced in Kollingbaum & Norman 2001, Kollingbaum & Norman 2002) is a form of contract management that supports the automation of business transactions between software agents in electronic commerce environments. Its specific concern is to establish trust relationships between agents acting in open electronic markets. Software agents, under the command of their human organisations, are sent into such environments to engage in business transactions (Dellarocas 2000, Sierra & Dignum 2001). In such markets, agents may take on different roles such as buyers, sellers, auditors, information vendors, financial institutions and other intermediaries.
Contracts are a traditional means to regulate and secure such business transactions. They make explicit the dependencies between the contract participants and contain the norms that govern their interaction. With the automation of business transactions in electronic environments, the reliable automation of contract management procedures becomes critical. The reason is simple: whatever deals agents negotiate are, in effect, contracts between human organizations and, therefore, these organizations will be held responsible for their correct execution. This includes detection of defective behaviour during the complete business transaction and means to enforce either correct behaviour or sanction defection. For agents using Supervised Interaction for their contracting it is paramount that they are able to correctly understand normative statements within such contracts. It is therefore the specific concern of the NoA Normative Agent Architecture to provide agents with an architecture that allows norm-based behaviour and provides them with capabilities to engage in Supervised Interaction. Besides supporting the specific concerns of Supervised Interaction, NoA is a general normative architecture for norm-motivated agents.
The NoA normative agent architecture is intended to provide the necessary reasoning capabilities for processing norms, plans and belief about the world, and in particular contracts specified as a set of norms. NoA is an adaptation of the commonly adopted reactive planning architecture (Firby 1987, Georgeff & Lansky 1987). It incorporates a plan specification language that enables behaviour specifications for normative agents in the form of pre-fabricated plans. This plan specification language is influenced by approaches such as JAM (Huber 1999) and Agentspeak(L) (Rao 1996, d’Inverno & Luck 1998, Machado & Bordini 2001). There are two principal distinctions, however, between these systems and the NoA architecture:
• Multiple effects. Plans formulated in the NoA plan specification language have multiple effects; any of these effects can be the reason for the agent to select a plan to satisfy a certain goal.
• Motivated by norms. Besides desires, a NoA agent is specifically motivated by norms; norms capture state of affairs or actions the agent is obliged or permitted to achieve or perform, or prohibited from achieving or performing.
NoA is also based on the logic of responsibility for states and actions proposed by (Norman & Reed 2001) and therefore captures the distinction between an agent taking responsibility for the achievement of a state of affairs and taking responsibility for the performance of an action. This distinction is reflected both in the NoA plan specification language and in the contract specification language used in Supervised Interaction (see section 3), which is integrated into NoA for contract management.
Subsequent sections explain both Supervised Interaction and the NoA Normative Agent Architecture in more detail. Section 2 gives a brief overview about Supervised Interaction, whereas section 3 describes NoA in detail. The paper concludes with an account on related work (section 4) and conclusion (section 5).
2 Supervised Interaction
Supervised Interaction is a form of contract management designed to create trust between contracting agents. The motivation for this specific form of interaction stems from the fact that current contract management models are unsuited to dealing with defective behaviour of business agents. Agent interaction is often based on the assumption that agents involved will not display unexpected behaviour. Supervised interaction provides the necessary tools for automated contracting: an organizational framework, a contract specification language and a general contract management procedure. These are designed to maintain trust relationships between agents in their contract management.
2.1 Organisation
For its organizational structure, Supervised Interaction uses the concept of a “trusted third party”. Castelfranchi et al. (Castelfranchi 1995, Castelfranchi & Tan 2001) emphasise the importance of a witness or “trusted third party” in the contracting process. As a third force, it enables the creation of relationships between two contracting agents under a situation of trust. Therefore, in Supervised Interaction, agents are organised in a three-party relationship between two contracting individuals (or organisations), the customer and the supplier, and the “authority” as the trusted third party. It is important to note that the contract between a customer and supplier establishes right/duty relationships between agents, but a separate mechanism is necessary so that these rights are actually enforced and duties are correctly executed. It is the authority that has to establish this trust relationship. The authority observes the correct execution of the contract. In the work presented here a contract contains normative characterisations for the three agents participating in an interaction. These norms are expressed in terms of obligations, permissions and prohibitions for the contracting partners, indicating the required and allowed behaviour of each agent. The authority has an exceptional role within such an interaction, as it must have ascribed certain powers to enforce correct contract execution. This kind of empowerment is established by a separate set of behavioural definitions in the contract, called “sanctions”. These are actions an authority commits to deploy in case one agent does not fulfil obligations specified in the contract. The duty for sanctioning eventually backtracks to the human organisation represented by the authority agent in the ongoing interaction. It also means that Supervised Interaction depends on the embedding in a legal and social environment and that legal institutions must extend into electronic environments to provide services of trust and contract enforcement.
2.2 Contract Specification
Contracts are the central means of Supervised Interaction to create norm-governed behaviour of agents within a three-party relationship. Supervised Interaction is designed to facilitate the creation and management of binding contracts between agents, and therefore eventually between the human organisations represented by these agents. These contracts must, therefore, capture the essence of real contracts between human organisations in a form that may be interpreted and executed by agents. Real contracts describe interactions between business partners in such detail that the creation and negotiation of such a contract from scratch in an automated fashion represents a complex problem. Existing negotiation schemes mostly concentrate on achieving agreements on such singular issues as price,
delivery date, quality etc. Real contracts capture complex interaction schemata or business protocols, regulating the correct actions and moves of the business partners.
To allow, on the one hand, the capturing of a complex business protocol with all obligations, permissions and clauses of exceptions and sanctions as in real contracts and, on the other hand, to limit the effort for the actual negotiation task between agents, so-called “Contract Templates” are introduced. These Contract Templates are pre-fabricated contract outlines and encode domain-independent interaction schemata or “business protocols”. Contract templates are domain-independent from a specific business case (independent from the “domain”) and determine the specific protocol for two business partners to follow, but not domain-specific elements such as what type of commodity etc. Contracts are then instantiated from these templates during the negotiation phase of Supervised Interaction.
A contract specification language has been put forward as an integral part of Supervised Interaction (Kollingbaum & Norman 2002). Influences on the layout of this language stem from the Philosophy of Law where formal languages are used to specify legal positions (Lindahl 1977, Pörn 1970). Of specific interest is the use of these languages, and extensions of them, in the specification of computer systems (Jones & Sergot 1992, Jones & Sergot 1996, Pacheco & Carmo 2001). This contract specification language consists of the following main elements: role specifications, agent-role assignments and normative statements. Normative statements are role-specific, they express obligations and permissions and sanctions relevant for agents taking on such roles in the instantiated contract. Beside obligations and permissions, sanctions are explicitly introduced as the third form of normative statement. A BNF syntax specification of this language is given in figure 7 and discussed in more detail in section 3.2.
2.3 Contract Management
For contract negotiation, instantiation and execution, Supervised Interaction provides a detailed contract management procedure. Besides the three-party relationship and contract specification language, this procedure is the third key element of Supervised Interaction. This management activity takes place in three main phases: registration, contract negotiation and contract execution.
• Registration. The purpose of the registration phase is to set up subsequent phases of the contract management procedure. Most important, a customer, a supplier and authority have to create a three-party relationship.
• Contract negotiation. This phase is focused on the domain-specific content of the contract following the template agreed in the registration phase. Issues determined important in the registration phase must be negotiated, for example price, quality or delivery dates.
• Contract execution. The fully negotiated contract is executed by the three agents under the supervision of the authority.
The registration phase has to produce a result that enables the subsequent negotiation of the contract. This requires the clarification of the participants in a contract and their roles, the contract template and the kind of negotiation mechanism that should be used for contract negotiation. The outcome of the registration phase has to be an “Agreement in Principle” between a customer and supplier to pursue a business transaction (figure 1). This agreement is signed with an authority and determines the so-called “Level of Supervision” represented by a chosen contract template and the negotiation mechanism that should be used in the subsequent negotiation phase.
(c, {s}, a, t, n)
Agreement in Principle
(c, s, a, t, n)
Combination of: customer,
supplier, authority, contract template, negotiation mechanism CNP Reverse Auction Auctions Fish Market Argumentation-based Negotiation 1:N N:1 1:1
({c}, s, a, t, n)
The registration phase will yield a set of such agreements. In case of a 1:N relationship between one customer and many suppliers, an agreement is established for each customer with one of the suppliers separately. All these agreements will have the same authority, Contract Template and negotiation mechanism with only the contracting agents varying (in case of the 1:N relationship this will be the supplier). With these elements in place, negotiation can proceed according to the chosen negotiation mechanism.
As already mentioned, the process of Supervised Interaction is not dependent on any particular model of a negotiation dialogue. Anything from the insertion of the cost of commodity or service from a catalogue and the selection between available delivery times through an auction protocol (many customers, one supplier, depicted as N:1 in figure 1) to a sophisticated argument-based dialogue could equally be used. The participants must, of course, support this mechanism.
If the negotiation phase can be finished successfully and it produces a contract between a customer, a supplier and an authority, the execution phase can proceed. If the negotiation phase failed, the contract management process has to be restarted with a new registration attempt.
The completely instantiated contract is known to all three participating agents and is distributed by the authority. It contains declarations of obligations, permissions and sanctions of each party following the template used. These declarations will guide the execution of the contract.
3 Normative Agent Architecture
The NoA Normative Agent Architecture supports the development of agents that understand norm specifications and are, therefore, able to correctly execute contracts, as required by Supervised Interaction. These so-called “normative” agents are motivated by norms in their behaviour. The contract specification language devised by Supervised Interaction is integrated into NoA.
Belief Revision Goal Action Goal/Action Generation Activity Monitor Plan Option Generation Norm Filter
Plan Choice Plan Execution
Set of Plan Activations Goal Action Set of Plan Activations Goal/Action Request Plan Norm Activation Norm Activation Request Perception Action Active Norms Plans Beliefs Subgoal/Action Goal/Action Request Belief Goal/Action Request Beliefs Norms
As NoA agents are motivated by norms, the understanding and correct execution of norms is an essential requirement. The three key requirements of an execution architecture for Supervised Interaction are:
• Distinction of States and Actions. The distinction between an agent taking responsibility for the achievement of a state of affairs in contrast to an agent taking responsibility for the performance of an action (Norman & Reed 2001) must be clearly reflected in the specification and execution of plans and contracts.
• Contract Management. Agents must be able to understand normative statements within contracts and how to correctly execute them.
• Norm-based Behaviour. The goal / action generation and plan selection is based on norms. Norms are brought in as motivators for generating goals / actions and as filters in the plan selection process.
The NoA agent architecture is proposed as a general normative agent architecture and specifically as an executor for Supervised Interaction. Figure 2 gives an overview of its structure and of the basic steps of execution. The main elements that influence the behaviour of an agent are (a) a set of beliefs, (b) a set of pre-specified plans and (c) as set of norms. NoA provides a plan specification language that allows the creation of pre-specified plans, which represent the capabilities of an agent. NoA plans can have multiple effects. Plans are selected according to one of their effects, whereas all other effects represent side-effects of this plan, which occur during its execution. All the effects of a plan must be taken into account when it is considered for execution.
Figure 2 shows the elements of this architecture. Agents act when a new “activity” is created: either a goal to achieve or a plan to perform. This activity generation is either motivated directly by changes in the set of beliefs or because of norms.
Activity generation motivated directly by belief revisions can be described as internally motivated activities. But NoA agents introduce norms as an additional element of influence to their acting and norms represent external motivators. Changes in the set of beliefs may result in a request to the “Goal / Action Generator” (see figure 2) to create a new activity (goal / action) for the agent to pursue. As figure 2 shows, the generation of an activity (goal / action) can also be motivated by norms. Norms are relevant to an agent only if they are “active”. For this purpose, norm specifications are annotated with declarations that determine the exact circumstances under which a norm is active (see the syntax specification in figure 6). Norms become active when the agent’s beliefs reflect their specified conditions of activation.
Activated norms influence the behaviour of an agent in two ways:
• by motivating the generation of a goal that must be achieved or an action that has to be performed (the distinction between state and action (Norman & Reed 2002) is maintained), these are externally motivated activities.
• by being used in a special “norm filtering” step within the execution cycle of the NoA architecture by restricting the options of the agent in fulfilling its responsibilities
The generation of an activity results in the creation of a so-called “Activity Monitor” (see figure 2). This is the main functional element within NoA that supports plan selection, plan filtering, execution and handling of subgoals to either satisfy a top-level goal or perform an action. Activity Monitors operate concurrently, providing a separate thread of control for each activity. Within each activity monitor, the complete execution of a plan chosen for such a goal / action takes place. If a selected plan contains sub-goals or actions, then the activity monitor will maintain the state of the current plan and try to achieve these sub-goals or perform the subsidiary action, before it continues with the execution of the original plan. The execution cycle within this monitor has the following steps:
1. Plan Option Generation. In case that a goal must be satisfied, a set of plans is chosen according to one of the effects they would produce if they would be executed. This set is called the “Set of Plan Activations”. In case that the direct performance of an action is required, one specific plan is chosen.
2. Norm Filter. Active norms are applied to this set of plans to filter out those that would produce effects that are forbidden or are directly acts that are forbidden.
3. Plan Choice. One of the plans must be chosen for execution.
4. Plan Execution. The execution of a plan can have various outcomes: performing a primitive action affecting the world, updating beliefs or establishing a subgoal or subsidiary actions.
Plans that are chosen as options for goal achievement, are checked against the currently active set of norms. The norm filter has to decide which plans must be filtered out. In its most simplest form of implementation, this would be all the plans that would produce effects that are prohibited according to the currently active norms. More sophisticated norm filters would introduce deliberation to allow NoA agents to handle norms in a maybe more sophisticated or “relaxed” way. The subsequent sections give more detail to single steps in the NoA execution cycle.
3.1 Plan Specification
The general form of a NoA plan carries information about when it would be allowed to select it for execution (preconditions), what kind of goals it can satisfy (effects) and the actual body of the plan:
plan <planname> <parameterlist>
<preconditionlist> <effectlist> <planbody>
Plans can have multiple effects. When a plan is chosen for satisfying a goal, then this choice will be based on one of these effects. All other effects are side-effects, which occur during the execution of the plan. The NoA plan specification language reflects the distinction between achieving states of affairs and performing actions with following language constructs:
achieve <state> perform <action>
The achieve construct contains a <state> expression that determines the effect that the agent wants to achieve. A plan is an appropriate option or “applicable” for the satisfaction of such a goal, if it has the effect in its effect list. During the plan selection process, all initially applicable plans (according to their preconditions and the required effect) are sent through a norm filter. This norm filter will reduce this set of plans to a subset that are applicable according to the currently active norms. From this reduced set of plans, one plan will eventually be chosen for execution.
The perform construct already determines the plan that should be executed, specified by the <action> expression. A plan declaration, therefore, serves both cases. In case of the achieve statement, plans are chosen according to a specified effect, whereas in case of the perform statement, plans are chosen according to the plan signature – the plan name with the parameter list.
An example illustrates in more detail, how NoA plans serve agents using Supervised Interaction. In this example, a customer agent is doing business with a supplier agent under the supervision of an authority. As the underlying protocol for this interaction, a simplified version of the “Letter of Credit” business protocol is chosen. This protocol is illustrated in figure 3.
Authority
Customer
Supplier
1. D epos it_M oney 2. Is sue_ LoC 4. Transfer_Goods 5. Send_LoC 6. R etriev e_M on ey 7. P ay_m on ey“Letter of Credit”
3. OrderFigure 3. Letter of Credit
The “Letter of Credit” protocol is intended to secure business transactions. A bank is acting as an authority and is releasing money to the supplier that has been deposited by the customer, if the supplier
can produce a Letter of Credit. This Letter of Credit is issued by the bank to the customer and used by the customer as a kind of token to be handed over to the supplier in exchange for goods. The supplier then “cashes in” the Letter of Credit from the bank. Figures 4, 5 and 6 show plans that could be appropriate to let agents act accordingly.
Figure 4. Plans appropriate for the Customer agent
Figure 5. Plans appropriate for a Bank agent
Figure 6. Plans appropriate for a Supplier agent
Three plans are specified for the customer agent (figure 4), “depositMoney”, “order” and “sendLoC”. These plans provide the agent with the capabilities to get a Letter of Credit from the bank and order the goods. For example, the plan “order” has in its parameterlist all the variables specified, which are used within the plan. These variables will be bound at plan option generation (see figure 2 and section 3.3). The preconditions express the state of affairs in which the plan is appropriate for plan issueLoC ( LoC, Acc, Mon, Cust )
preconditions (
credit( Acc, Mon ) ) effects (
haveLoC( Cust, LoC ) ) {
primitive provideLoC(Cust,LoC,Acc);
}
plan depositMoney ( Cust, Acc, Mon, Bank )
preconditions (
haveAccount( Acc, Bank ), haveMoney( Cust, Mon ) ) effects (
not haveMoney( Cust, Mon ), credit( Acc, Mon ) ) {
primitive deposit( Cust, Acc, Bank, Mon );
}
plan order ( Cust, Supp, Goods, LoC ) preconditions (
stocked( Supp, Goods ), haveLoC( Cust, LoC ) ) effects (
ordered( Cust, Goods ) ) {
primitive sendOrder( Cust, Supp, Goods ); }
plan sendLoC ( Cust, Supp, Goods, LoC ) preconditions (
haveGoods( Cust, Goods ), haveLoC( Cust, LoC ) ) effects (
not haveLoC( Cust, LoC ), haveLoC( Supp, LoC ) ) {
primitive send ( LoC, Supp ) ; }
plan payMoney ( Bank, Supp, LoC, Acc, Mon ) preconditions (
haveLoC( Bank, LoC ) ) effects (
not credit( Acc, Mon ), haveMoney( Supp, Mon )) {
primitive payout(Acc,Mon,LoC,Supp); }
plan transferGoods( Supp, Cust, Goods, LoC, T ) preconditions (
haveLoC( Cust, LoC ), ordered( Cust, Goods ) ) effects (
not stocked( Supp, Goods ), haveGoods( Cust, Goods ) ) {
perform loadTruck ( T, Goods ) ; achieve arriveIn ( T, Cust ) ; perform unloadTruck ( T, Goods ) ; }
plan retrieveMoney ( Supp, Bank, LoC ) preconditions (
haveLoC( Supp, LoC ) ) effects (
not haveLoC( Supp, LoC ) ) {
primitive sendLoC( Supp, Bank, LoC ) ; }
selection. In case of the order plan, these are that the supplier stocks the goods that are of interest to the customer and the customer has a Letter of Credit for these goods. Following successful execution of the body of this plan, the effects of the plan are expected to occur; i.e. the goods are ordered by the customer. To limit the complexity of this detailed example, the body of this plan and other plans are shown as the execution of a primitive action. In the case of plan “order” this primitive action is to send the order to the supplier for the goods indicating that a Letter of Credit is available.
The bank is provided with two plans expressing capabilities to issue a Letter of Credit to the customer and pay the money to the supplier in exchange for the Letter of Credit ( figure 5).
The plans for the supplier (figure 6) provide the capabilities necessary to transfer the goods and retrieve the money from the bank.
3.2 Contracts
In Supervised Interaction, agents engage in a business transaction by establishing a contract. This contract contains the norms that govern the interaction of the business partners. For Supervised Interaction and for NoA agents, a contract specification language has been designed to support the formulation of such contracts. The syntax of this language is outlined in figure 7.
<contract> ::= “contract” <name> “(“ <content> “)” <content> ::= ( <agent> | <role> | <norm> )+
<agent> ::= “agent” “(“ <agent_name> “,” <role_name> “)” <role> ::= “role” “(“ <role_name> “)”
<norm> ::= ( “obligation” | “permission” | “prohibition”| “sanction” ) <norm_body> <norm_body> ::= “(“ <role_name> “,” <activity> “,” <activation> “,” <expiration> “)”
<activity> ::= <perform> | <achieve> | “not” <activity> <perform> ::= “perform” <action>
<achieve> ::= “achieve” <state>
<action> ::= <plan_name> “(“ <parameterlist> “)” <state> ::= <condition>
<activation> ::= <condition> <expiration> ::= <condition>
<condition> ::= <predicate> (( “and” | “or” ) <predicate>)* | “not” <predicate>
<predicate> ::= <pred_name> “(“ <parameterlist> “)” | “(“ <condition> “)” |
“TRUE” | “FALSE”
Figure 7. The Contract Specification Language
A contract for NoA agents is a set of normative statements that express the obligations, permissions, prohibitions and sanctions for a specific interaction. For each normative statement in a contract, it must be clearly specified, under what circumstances this norm is “active” and therefore relevant to an agent. Activation and expiration conditions are introduced for this purpose (see syntax specification in figure 7). Each norm specification carries this information to control its activation.
Norms are goal / action generators. In case that a norm becomes active, an activity as specified in the norm body is generated within an agent and the satisfaction of a goal or the performance of an action is pursued as described in previous sections. Each norm is assigned to a specific role in the contract, which is the “norm-addressee”. When a contract is instantiated from a contract template, such a role will be taken on by one of the agents participating in the execution of this contract. Normative statements in the NoA contract specification language can express obligations, permissions, prohibitions and sanctions. Obligations occur in two forms:
• An obligation to achieve a state of affairs or to perform an action would demand certain activities to fulfill its purpose. Such obligations therefore are goal / action generators – they motivate the creation of goals or actions and the subsequent selection of an appropriate plan.
• An obligation to not achieve a state of affairs or to not perform an action essentially expresses that it is forbidden to achieve / do that. The separate language construct “prohibition” expresses this
case. Such a norm is not a goal / action generator, this kind of norm is relevant for the norm filtering step only. The keyword “prohibition” is introduced simply as a syntactic tool to improve the readability of contract specifications.
• Permissions temporarily override prohibitions, their activation and expiration conditions specify a window of opportunity where the activity specified in such a permission is allowed to take place. For the example, which has been started in the previous section, a contract must be introduced that correctly encodes the simplified “Letter of Credit” protocol as depicted in figure 3. This protocol must be translated into a set of normative statements formulated in the Contract Specification Language as outlined in figure 7. The first obligation in such a contract would be for the customer to deposit its money with the authority, which is the bank:
obligation (
Cust,
perform depositMoney ( Cust, Acc, Mon, Bank ),
TRUE,
credit ( Acc, Mon ) )
This obligation motivates the performance of the plan depositMoney specified previously. The variables Cust, Acc, Mon, Bank will be bound with appropriate values, when this obligation becomes operative. This obligation expires, when the money is credited to the customer’s account. This is one of the effects of the plan depositMoney.
As soon as such a credit exists, a permission is activated for the bank to issue a Letter of Credit. This is expressed with following normative statement:
permission (
Bank,
perform issueLoC ( LoC, Acc, Mon, Cust ), credit ( Acc, Mon ),
haveLoC ( Cust, LoC ) )
After the customer received a Letter of Credit, it is obliged to place an order with the supplier. This obligation exists, because the customer has already signed a contract to order goods. In the execution phase, this obligation is then executed. The contract will contain an obligation such as the following:
obligation (
Cust,
perform order ( Cust, Supp, Goods, LoC ), haveLoC ( Cust, LoC ),
haveGoods ( Cust, Goods ) )
This permission is activated when the Letter of Credit is issued and expires when the goods are in the possession of the customer. The following obligations and permissions are the driving force for a further execution of the contract. The supplier has to achieve the delivery,
obligation (
Supp,
achieve haveGoods ( Cust, Goods ),
haveLoC ( Cust, LoC ) and ordered ( Cust, Goods ), haveGoods ( Cust, Goods )
)
which in turn creates an obligation for the customer to exchange the Letter of Credit for the goods,
obligation (
Cust,
perform sendLoC ( Cust, Supp, Goods, LoC ),
haveLoC ( Cust, LoC ) and haveGoods ( Cust, Goods ), haveLoC ( Supp, LoC ) and not haveLoC ( Cust, LoC )
which in turn creates a permission for the supplier to eventually retrieve the money from the bank,
permission (
Supp,
perform retrieveMoney ( Supp, Bank, LoC ), haveLoC ( Supp, LoC ),
haveLoC ( Bank, LoC ) and not haveLoC ( Supp, LoC ) and haveMoney ( Supp, Mon )
)
which in turn creates the obligation for the bank to pay the money:
obligation (
Bank,
perform payMoney ( Bank, Supp, LoC, Acc, Mon ), haveLoC ( Bank, LoC ),
haveMoney ( Supp, Mon ) )
An obligation for the bank makes only sense, if this obligation can enforced. In this example, the bank itself acts as an authority, enforcing obligations by issuing sanctions. To explain how the bank can be forced to meet its obligation towards the supplier, it must be seen as part of a social environment with a legal structure and relationships of power between authorities at different levels of the society. These “Meta”-authorities will then enforce correct behaviour of the bank.
As pointed out previously, permissions temporarily override prohibitions. Two permissions are specified in the example contract, but no prohibitions that these permissions override. Therefore the following norm specifications are necessary to make the contract complete:
prohibition (
Cust,
perform order( Cust, Supp, Goods, LoC ),
TRUE,
FALSE
)
prohibition (
Supp,
perform retrieveMoney ( Supp, Bank, LoC ),
TRUE,
FALSE
)
The first prohibition expresses that it is, in general, forbidden for the customer to order anything. This prohibition is overridden by a permission in case the customer has a Letter of Credit. The second prohibition expresses that the supplier is not allowed to retrieve money. But another permission in the contract overrides this prohibition in case the supplier possesses the Letter of Credit.
Prohibitions are not goal generators but are important for the norm filtering step within the execution cycle of the NoA architecture (figure 1).
One single sanction is shown here:
sanction (
Bank,
perform withholdDeposit( Supp ),
not receivedBefore ( Goods, Deadline ), receivedBefore ( Goods, Deadline )
)
The bank has to withhold the deposit from the supplier in case the goods do not arrive before a specific deadline. Activation and expiration conditions are formulated in such a way that this sanction is activated only, if the goods do not arrive in time. In principle, each obligation has to be complemented
by a corresponding sanction to make sanctions enforce-able. For reasons of simplification, no such sanctions are shown here.
3.3 Plan Option Generation
Norms are activated when their activation condition holds. This activation takes place because of a change in the agent’s beliefs. Obligations are goal / action generators, creating new top-level goals or actions. In the “Letter of Credit” example, one achievement goal is stated on one of the obligations for the supplier:
achieve haveGoods ( Cust, Goods )
expressing the goal that the customer should eventually have the goods. All those plans of the supplier that produce an effect “haveGoods ( Cust, Goods )” will be an applicable option for satisfying this goal. In case of the example, only one plan is specified – plan “transferGoods” – that would be applicable. This plan has a set of parameters, “Cust”, “Supp”, “Goods”, “LoC”, “T”, that need binding to instantiate this plan for execution. If there are more than one options of a binding for one or more of these parameters, each binding case would produce a separate “activation” of this plan. If, for example, the supplier has three trucks (required binding for parameter “T”) in the sizes “small”, “medium” and “large”, three binding options emerge.
Option 1 Option 2 Option 3
Cust = “C” Cust = “C” Cust = “C” Supp = “S” Supp = “S” Supp = “S” Goods = “GXX” Goods = “GXX” Goods = “GXX” LoC = “X0000” LoC = “X0000” LoC = “X0000”
T = “T_small” T = “T_med” T = “T_large”
Figure 8. Binding Options for Plan Activation
This plan is now “activated” for each truck and becomes a separate plan option for satisfying the goal. As figure 8 shows, this would be the three truck options “T_small”, “T_med” and “T_large”.
All activated plans comprise the “Set of Plan Activations”. This set is transferred from the plan option generation step to the norm filter.
3.4 Norm Filter
The norm filter has to remove all those plans from the “Set of Plan Activations” that counteract any norm with their effects. All currently active norms are taken into account. Any norm the agent holds is taken into account by the norm filter. These include the normative statements from a contract such as presented previously in the example, but can also include norms expressing general agreements with a society of agents or conventions to follow.
In case of the outlined example, if the supplier agent has to meet certain criteria such as road restrictions, driving license restrictions or company-internal cost regulations, then maybe some of the options shown in figure 8 would not be applicable and therefore filtered out. In this example, it is assumed that the agent is completely acting according to its norms. This would be the simplest form of behaviour of a normative agent.
3.5 Plan Choice and Execution
The output of the norm filter is a (possibly) reduced “Set of Plan Activations”. From this set, one plan must be chosen for execution. Plan execution can have various outcomes. The performance of a primitive action would affect the external world of the agent and changes in this external world would then be recognized as perceptions, leading to belief updates. Plan execution can also result in simple updates of the agent’s beliefs or establish a subgoal or subsidiary action within the Activity Monitor (see figure 2) of the NoA architecture. The Activity Monitor is discarded as soon as its a top-level goal is satisfied or the plan corresponding an action is completed in its execution.
4 Related Work
The central focus of this paper is to establish a normative agent architecture for the execution of contracts. Research into normative agents is therefore relevant. This research has three interests: • Norm adoption. Under what conditions would an agent adopt a norm.
• Norm influence. How do norms influence the behaviour of an agent. • Norm violation. Under what circumstances would an agent violate a norm.
Lopez et al. (Lopez, Luck, d’Inverno 2002) present a proposal for agents that make a decision whether or not to adopt a norm, which includes issues such as the attitude of the agent towards norms, the consistency of a norm with the agent’s currently adopted goals etc. In general, Dastani and van der Torre (Dastani & van der Torre 2002) present a mature theory of norms and a decision procedure for selecting a consistent and maximal set of norms. To do this, however, they need to analyse all the consequences of the agent’s norms. In general, this is a hard problem. Castelfranchi et al. (Castelfranchi et al. 2000) present an abstract picture of the types of norms that could influence the agents behaviour, including norms that have the potential to generate goals and norms as preferences over decisions of the agent.
The NoA agent architecture complements this research by integrating norm specifications within a practical decision making architecture.
Contracts play a central role both in Supervised Interaction and in the NoA agent architecture. The contract specification language presented in this paper is influenced by the work of Jones and Sergot (Jones & Sergot 1992, Jones & Sergot 1996) and Pacheco and Carmo (Pacheco & Carmo 2001). They investigate the modelling of complex organisations and organisational behaviour using normative models. Pacheco and Carmo emphasise the importance of contracts as the central element to bind agents into societies. The contract specification language put forward by them includes role specifications, deontic characterisations for these roles, statements of representation, the attribution of roles to agents and the relations between roles. The contract specification language used in Supervised Interaction and put forward in this paper uses similar concepts with following extensions: specific normative statements called “sanctions” assigned to the authority role established by Supervised Interaction and an explicit consideration of activation and expiration conditions for normative statements in a contract, to clearly specify the time window during which a normative activity is operative. In addition, this contract specification reflects the clear distinction between actions and states as proposed by (Norman & Reed 2001).
5 Conclusion
In this paper, the NoA Normative Agent Architecture has been presented as an appropriate contract management framework for Supervised Interaction. Supervised Interaction is a form of contract management designed to create trust between contracting agents. It requires agents to understand norms specified in contracts and to act accordingly. The NoA Normative Agent Architecture is based on three key requirements: (a) a clear distinction between an agent taking responsibility for the achievement of a state of affairs and the agent taking responsibility for the performance of an action, (b) agents understand normative statements within contracts and how to correctly execute them and (c) goal / action generation and plan selection is based on norms. A detailed example is presented, using the “Letter of Credit” protocol to demonstrate, how NoA plans can be formulated and how norms motivate the generation of goals or the performance of actions, and how they influence plan option generation, selection and execution.
References
Castelfranchi, C. (1995). Commitments: From Individual Intentions to Groups and Organizations, Proceedings of the First International Conference on Multi-Agent Systems ICMAS’95, San Francisco, 1995.
Castelfranchi, C, Dignum, F., Jonker, C., Treur, J. (2000). Deliberate normative Agents: Principles and Architecture. In Intelligent Agents VI, volume 1757 of Lecture Notes in Artificial Intelligence, pages 364-378. Springer-Verlag, 2000.
Castelfranchi, C., Tan, Y.-H. (2001), The Role of Trust and Deception in Virtual Societies, Proc. 34th Hawaii Intl. Conf. On System Sciences, 2001.
Dastani, M, van der Torre, L. (2002). What is a normative Goal? In Proceedings of International Workshop on Regulated Agent-based Social Systems: Theories and Applications. AAMAS Workshop, 2002.
Dellarocas, D. (2000). Contractual Agent Societies: Negotiated Shared Context and Social Control in open Multi-agent Systems, 2000 Workshop on Institutions and Norms in MAS, Autonomous Agents 2000, Barcelona, Spain, 2000.
d'Inverno, M., Luck, M. Engineering AgentSpeak(L) (1998). A formal computational model. Journal of Logic and Computation, 8(3), 233--260, (1998).
Firby, R.J. (1987). An investigation into reactive planning in complex domains. In Proceedings of the National Conference on Artificial Intellgence (AAAI), pages 809--815. AAAI, 1987.
Georgeff, M. P., Lansky, A. (1987) Reactive Reasoning and Planning. In Proceedings of AAAI-87, pp. 677682, 1987.
Huber, M.J. (1999). JAM: A BDI-theoretic mobile agent architecture. In Proceedings of the Third International Conference on Autonomous Agents (Agents'99), pp. 236--243, (May 1999). Jones, A.J.I., Sergot, M. (1992), On the Characterisation of Law and Computer Systems: The
Normative Systems Perspective, In J.-J.Ch. Meyer, R.J. Wieringa (editors), Deontic Logic in Computer Science: Normative System Specification
Jones, A.J.I., Sergot, M. (1996), A Formal Characterisation of Institutionalised Power, Journal of the IGPL, 4(3), pp.429-445, 1996.
Kollingbaum, M.J., Norman, T.J. (2001). Supervised Interaction for Electronic Markets. UKMAS 2001, Oxford, 2001.
Kollingbaum, M.J., Norman, T.J. (2002). Supervised Interaction – creating a Web of Trust for Contracting Agents in Electronic Environments. In C. Castelfranchi & W. Johnson (eds), Proceedings of the First International Joint Conference on Autonomous Agents and Mulit-Agent Systems (Bologna, Italy), ACM Press, New York, pages 272-279, 2002.
Lindahl, L. (1977). Position and Change, D. Reidel Publishing Company, Dordrecht-Holland/Boston-U.S.A., 1977.
Lopez, F., Luck, M., d’Inverno, M. (2002). Constraining autonomy through norms. In Proceedings of the First International Joint Conference on Autonomous Agents and Multi-agent Systems, pages 647-681, 2002.
Machado, R., Bordini, R. H. (2001). Running AgentSpeak(L) agents on SIM_AGENT. In d'Inverno, M., and Luck, M., eds., Working Notes of the Fourth UK Workshop on Multi-Agent Systems (UKMAS 2001), 13-14 December. St. Catherine's College, Oxford, 2001.
Norman, T. J., Reed, C A. (2001). Delegation and responsibility. In C Castelfranchi & Y Lesperance (eds), Intelligent Agents VII: Proceedings of the Seventh International Workshop on Agent Theories, Architectures and Languages, volume 1986 of Lecture Notes in Artificial Intelligence, Springer-Verlag, pages 136-149, 2001
Pacheco, O., Carmo, J. (2001). A Role Based Model for the Normative Specification of Organized Collective Agency and Agents Interaction, Journal of Autonomous Agents and Multi-Agent Systems, in press, 2001.
Pörn, I (1970), The Logic of Power, D. Reidel Publishing Company, Dordrecht – Holland, 1970 Rao, A. S. (1996). AgentSpeak(L): BDI agents speak out in a logical computable language. In Agents
Breaking Away: Proceedings of the Seventh European Workshop on Modelling Autonomous Agents in a Multi-Agent World, LNAI 1038, eds., W. Van de Velde and J. W. Perram, pp. 42--55. Springer, (1996).
Sierra, C., Dignum, F. (2001). Agent-Mediated Electronic Commerce: Scientific and Technological Roadmap, In F. Dignum and C. Sierra (eds.), Agent-mediated Electronic commerce (The European AgentLink Perspective), LNAI 1991, pp. 1-18, 2000.