Mitigating Circumstances

. Electronic contracts are a means of representing agreed responsibilities and expected behaviour of autonomous agents acting on behalf of businesses. They can be used to regulate behaviour by providing negative consequences, penalties , where the responsibilities and expectations are not met, the contract is violated . However, long-term business relationships require some ﬂexibility in the face of circumstances that do not conform to the assumptions of the contract, mitigating circumstances . In this paper, we describe how contract parties can represent and enact policies on mitigating circumstances. As part of this, we require records of what has occurred within the system leading up to a violation: the provenance of the violation. We therefore bring together contract-based and provenance systems to solve the issue of mitigating circumstances.


Introduction
Commitments between business parties are generally regulated through contracts. These documents allocate responsibility for particular outcomes, allow parties to know what to expect of each other and provide a basis for redress should those responsibilities and expectations not be met. In many contexts, autonomous software agents can be used to advantageously represent businesses' interests in an automated way, including preparing, agreeing on, reasoning over, acting on and enforcing contracts in an electronic form. Much research has been conducted on how best to instantiate contract-based systems [2,3,10].
For the purposes of this paper, we consider a contract to be a set of clauses, each of which states some responsibility of an agent. A clause may state an obligation, a prohibition or a permission. The set of agents to which clauses apply are called the contract parties. One crucial aspect of an autonomous approach to electronic contracting is the handling of violations of a contract clause, i.e. where the stated responsibilities have not been fulfilled. There are different ways that a violation could be dealt with. For example, most contract-based systems will include a notion of payments, and so violations may automatically incur financial penalties.
However, relationships in business are important and a company that handled all violations of a contract clause equally could damage its long-term relationships with partners. In situations in which unexpected circumstances have led a contract party to be unable to fulfil their responsibilities, other parties may act more leniently than they are contractually permitted to, to maintain the long-term business relationship. Such circumstances are called mitigating circumstances.
In current electronic contracting approaches, where mitigating circumstances are addressed at all it is by passing the decision on how to handle a violation up to a human. However, organisations often have standard, if not publicised, policies for handling mitigating circumstances, and so automation is certainly possible. We would like to extend contract-based systems to allow agents to autonomously consider, and react appropriately to, mitigating circumstances.
A pre-requisite to providing this extended functionality is the ability to determine whether there were, or may have been, mitigating circumstances for a violation, which requires reliable documentation of what has occurred and how that caused the violation. It is only through such documentation that mitigating circumstances will be evident. The problem of obtaining the relevant documentation of a violation's causes is exacerbated by the fact that violations may only be dealt with some time after they occurred, for instance where it is only through the accumulation of multiple failures over time that a contract clause is violated.
In this paper, we describe how recording and reasoning over the causes of violations can help to better manage the behaviour of parties in the system. This allows contracting parties to handle problems more flexibly, and encourage better coordination. Specifically, the technical contributions of this paper are as follows.
• An algorithm for handling mitigating circumstances in contract violation based on technologies for electronic contracting and for determining the provenance of violations, i.e. what caused them to occur. • A re-usable model for expressing mitigating cirumstance policies.
• The application of this algorithm and model to an aerospace aftercare scenario.
The rest of the paper is structured as follows. Section 2 describes a motivating example application in the aerospace domain. Section 3 introduces our electronic contracting approach, and discusses the use of provenance to determine the cause of violations. Section 4 then details our algorithm, which is applied to the example application in Section 5. We finish the paper with a discussion of related work in Section 6 and conclusions in Section 7.

Example Scenario
Our example scenario is based on the aftercare market for aircraft engines. It is an extended version of that considered by Lost Wax's Aerogility application [1].

Contract
In this scenario, aircraft operators (e.g. airlines) establish contracts with engine manufacturers whereby the manufactures are obliged to ensure the aircraft have engines in working order. To achieve this, an engine manufacturer regularly removes an engine from an aicraft for which it is responsible and replaces it with an already serviced engine to allow the aircraft to continue flying. This replacement must be performed in a timely fashion, so that the aircraft remains usable. As well as regular servicing, the engine manufacturer must respond to possible faults in an engine by similarly replacing it. Once removed, an engine is serviced and then returned to the pool of engines available for swapping into other aircraft.
The core contract between aircraft operator and engine manufacturer specifies the following: • An engine requires servicing after every X flights, as well as when its health data indicates a possible fault. • When an aircraft's engine requires servicing, the engine manufacturer must remove the engine and replace it with a serviced one. • The aircraft operator is permitted to penalise the engine manufacturer if an aircraft is left on the ground for more than Y hours due to an engine not being available.
The core contract may be extended by extra constraints on the engine manufacturer in particular cases.
• Engines are ultimately composed of parts supplied by parts manu- facturers. An aircraft operator may constrain an engine manufacturer to only use parts from given named suppliers in engines used in their aircraft. • For best use of resources in fulfilling multiple contracts, an engine manufacturer will often take and service an engine from one operator's aircraft and put it into the aircraft of another operator. In some cases, one operator may not trust another. An operator may therefore constrain an engine manufacturer never to put engines into their aircraft that have been previously used by a particular other operator's aircraft.

Mitigating Circumstances
Where an aircraft has been grounded due to lack of working engine, an aircraft operator will want to recoup their costs by penalising the manufacturer. However, the two companies wish to retain a good working relationship, and particular mitigating circumstances may be considered. Whether the operator makes these circumstances clear to the manufacturer in advance is a choice of the individual business.
In this scenario, we consider two mitigating circumstances.
Late Health Data A manufacturer is aware of a potential fault in an engine through analysing the engine's health data. This is recorded in the aircraft, and so must be supplied by the operator. If supplied late, the manufacturer is delayed in servicing the engine. Part Supplier Late If an operator restricts the manufacturer as to where it can source engine parts, and the required part manufacturer was late in supplying parts, then this can affect the manufacturer's ability to provide a working engine on time.

Managing Violations
The way that violations of the contract are handled should depend on circumstances. In the scenario, one or more of the following broad actions can be performed by the aircraft operator given a violation (e.g. aircraft remaining on the ground too long).
Full Penalty Operator deducts 30% from the monthly payment to the engine manufacturer.
Reduced Penalty Operator sends a formal notice reprimanding the manufacturer but acknowledging mitigating circumstances. Reconsider Policy Operator starts reconsideration of its constraining policies in the contract.
The choice of a specific action is entirely based on the goals of the business, and is out of scope of this paper. For convenience, we assume that a partial penalty will be the action taken in all subsequent examples. We now discuss the two primary technologies that our algorithm for handling mitigating circumstances depends upon.

Contracts and Provenance
Our approach brings together two technologies, described in detail below. The application is based on contract-based systems to support regulation of agents' behaviour through explicit contracts agreed between agents. The policies for mitigating circumstances use provenance systems to record documentation on what occurs within a system and use this to determine why a particular violation occurred.

Contract-Based Systems
A contract-based system is one in which agents agree to documents which specify requirements (obligations and prohibitions) or permissions on their behaviour. For our purposes, we define a contract to be an assignment of clauses to agents that have agreed to fulfil them.
For agents, acting on behalf of multiple organisations, to set up and rely on contracts for mutual benefit, we require a supporting infrastructure. This can be expressed in terms of agents playing administrative roles, such as for storing contracts to ensure access to them and for preserving their integrity over their lifetime. It may also include monitor roles, which require the agents playing them to check that clauses are being fulfilled and, where they are not, to notify the enforcer of that contract clause, i.e. the agent responsible for handling that clause's violation.
Current work, such as that conducted in the CONTRACT project, has begun to bring together existing technologies to specify contract languages, frameworks for defining contract-based applications, administrative architectures containing those infrastructural roles needed to manage the contracts and model checking techniques for verifying that agents in an application are able to fulfil its contractual responsibilities. In this paper, we assume the presence of a contract language and administrative infrastructure. In general, we will not refer to these further, as they are out of scope of the work. However, the monitoring of the fulfilment of contract clauses is a vital part of understanding the context in which a violation occurs. For explanatory purpose, we will assume a single agent playing a monitor role for checking the fulfilment of all contract clauses. In reality, it is often the case that many such agents need to exist for an application, as monitoring may use and/or produce information private to individual contract parties.

Provenance and Causation
As previously stated, reliable documentation is necessary in order to determine whether the causes of a violation are sufficient to mitigate it. Thus, we need to be able to determine the provenance or the what caused a particular occurrence (e.g. violation) to occur as it did. In the study of art, te provenance of an artwork can include the artist, the materials used in creating it, the restoration done to the work over time, the different locations in which it has been stored or exhibited and so on. All of these ultimately caused the artwork to be as it is now. In previous research, we have studied provenance in the context a wide range of sciences [8]. Knowing the provenance of results is important in scientific experiments for many purposes, e.g. peer reviewers determining whether an experiment was rigorous and sound, understanding where an error may have occurred which affected the results, re-use of configuration of particularly successful experiments, etc.
With regard to the violation of a contract clause, causes can include the actions, or absence of actions, of the responsible party, but may also include actions of other agents and occurrences more widely within the application environment.
Determining the provenance of an occurrence therefore requires data on its causes. As we often do not know in advance that something particular will occur, agents must record what occurs and causal connections between occurrences around the time that they happen. The documentation forms a causal graph, depicting where A was caused by B, which was caused by C etc. Below, we will denote that A was caused by B (A is effect, B is cause) using notation: In order to ensure the availability of such a causal graph for our algorithm, we only consider applications that have be made provenance-aware, which entails that most, if not all, software agents are designed or adapted to record what they do and what caused them to do it (messages received, their goals etc.) [9]. In a contract-based environment, this includes both the contract parties and the infrastructure agents, such as the monitor. When it is not possible to record the causal connections between occurrences, it is often possible to infer that they exist from what has been recorded. To illustrate how provenance provides better understanding of an occurrence, we describe the provenance of engine being made available after servicing in Figure 1. We begin at the top of the figure.
Originally, it is determined that an engine, E, requires service. This occurrence causes the engine maker to be notified. The engine maker then requests and receives a part, P . In parallel to the engine maker being notified, another engine becomes available. Together the occurrences of a engine becoming available and the engine maker being notified cause the engine, E, to be swapped out for engine E2. Once engine E is taken out of the airplane, its defective part is replaced with the part ordered by the engine maker. This replacement of parts causes E to be made available once again for use in other aircraft.

Algorithm
In this section, we bring together the contract-based and provenance technologies described above to give an algorithm for handling mitigating circumstances when a violation is detected. We summarise the algorithm below, and then describe each step in more detail.

Violation Detection
From checking the environment, monitor determines that a clause was violated, informs the relevant enforcer.

Cause Determination
The enforcer uses heuristics to infer possible undocumented causes of the violation.

Mitigating Circumstances
The enforcer uses policies to determine, from the recorded and inferred causes of the violation, whether there were mitigating circumstances. 4. Remedy If mitigating circumstances were found, then, again according to its policy, the enforcer acts to remedy the situation and ensure that violations are less likely to occur in future.

Violation Detection
In order to detect the violation, the monitor must observe its environment on the basis of what is expected from fulfilling the contract clause. When the violation occurs, it notifies the enforcer for that clause. The enforcer is often a party to the contract, i.e. the agent that gains from the clause's fulfilment.
Being provenance-aware, the monitor records several pieces of documentation about what it does: the clause-related observation of the environment, the signalling of a violation, and the causal connection between the two (the former causes the latter).

Cause Determination
When a violation has occurred, the enforcer first checks whether there are undocumented causes it can infer from the available documentation. This provides a more complete picture from which it can then determine whether there were mitigating circumstances. Inference is achieved by applying inference rules.
An inference rule expresses a heuristic by which the enforcer determines new causal connections from existing facts. Its antecedent is an expression composed of parametrised predicates, its consequent takes the form of causal graph edges between occurrences. The antecedent's predicates are facts from one of four sources: The antecedent may also contain mathematical expressions resolving to true or false based on the predicate variables, e.g. A > B. The consequent of an inference rule contains a set of causal connections between predicates from the antecedent (i.e. known occurrences). An example of a whole rule is given below. In this rule, the antecedent is a conjunction of two facts documented by agents in the system and a relationship between them. The facts are that an engine's health data was received at time T1 and that the aicraft with that engine was unserviced at time T2; the relationship expresses that T2 was less than 10 hours after T1. The consequent of the rule, i.e. that implied by any pattern of occurrences matching the former facts, is that the fact that the engine was not serviced at T1 was caused by the health data being received at T2. Whenever the documented facts of a violation match the antecedent, the consequential causal connection will be added to the facts from which mitigating circumstances will be assessed.

Mitigating Circumstances
Determination of mitigating circumstances is achieved by a policy setting out where the causes of a violation suggest mitigating circumstances, and what action to take in each such case. Such a policy could be included as part of a contract document, in which case other parties may use it to reason about what they can get away with, or may be private to the owning contract party, if they prefer to keep the mitigating circumstances considerations secret. There are likely to be several different kinds of mitigating circumstance, such as the three given for the example in Section 2.2. For each kind, there will be a pre-condition and a remedy.
The pre-condition is a causal graph between occurrences, in the form of a tree with a violation occurrence as its root. All occurrences in the tree can be parametrised with variables. As a whole, the precondition graph acts as a template for chains of causes of a particular form leading to a violation. The template graph is then matched against the documentation recorded and inferred. If they match, mitigating circumstances have been found, and the remedy enacted.
An example of a mitigating circumstances policy statement is given below. The precondition is a tree of causal connections from the violation of a clause concerning a particular aircraft. The precondition is a template which can be matched against documented, or inferred, facts. In this case, the violation must have been caused by the aircraft's engine not being serviced at a given time, which in turn must have been caused by the engine health data being received at a given time. If this pattern is found within the documentation, then the pre-condition is matched, the policy applies, and the appropriate action is taken: reduced penalty, in this case.

Remedy
For the purposes of this paper, we consider the remedy to be a simple action by the enforcer, such as reducing the penalty that would otherwise be placed on the violating agent. In future work, we will consider more sophisticated mechanisms, such as negotiating to adjust the contract to more realistically suit the working environment.

Formal Definition
The algorithm can be expressed in pseudo-code as follows.
• C: the set of contract clauses of which to detect violations • R: the set of inference rules • G: a graph (V, E) where vertexes represent occurrences and edges causal relationships between them • GKB: the union of the knowledge sources (domain, contract, contract party, monitor) • P : a mapping from violation types to sets of policies concerning those types • A: an array of actions to be taken indexed by a policy if e = cv 5 then G ← APPLYRULE(r, GKB)

Applying to the Example
In this section, we apply our algorithm to the scenario presented in Section 2. We start by defining the facts that may be documented or inferred by an aircraft operator agent in the scenario. These are expressed using predicate logic and described in Table 1. Using statements of this form, we can construct propositions about what is documented or believed at any one time.

Predicate Description Domain Knowledge owns(A, O)
Operator O owns aircraft A Contract Clauses constrainedP artSupplier(S, P ) Contractual obligation to use supplier S for part P disallowedP riorU se(O) Contractual prohibition from using engines previously used by operator O

Contract Party Documentation engineAvailable(E)
Engine E is serviced and available for use partReceived(S, P, T ) Manufacturer received part P from supplier S at time T partRequested(S, P, T ) Manufacturer requested part P from supplier S at time T receivedHealthData(E, T ) Manufacturer received health data about engine E at time T replacedP art(E, P, T ) Part P was replaced in engine E at time T swappedEngine(A, E1, E2, T ) Engine E1 was removed, engine E2 inserted into aircraft A at time T Monitor Documentation unserviced(A, E, T ) Engine E of aircraft A requires but has not received servicing at time T violation(A) Violation of the contractual obligation regarding servicing aircraft A We now describe two use cases in which there are mitigating circumstances that the aircraft operator, acting in the role of enforcer, takes into account, matching those described in Section 2.2. In both use cases below, the monitoring mechanism discovers that an engine has not serviced at a given time, even though it contractually should have been. In each case, a different mitigating circumstance has occurred, and so a reduced penalty is applied. For each use case, we show how the algorithm in the previous section is applied.

Late Health Data
The following operation of the contract parties is documented.
• The engine manufacturer, as part of its operation, receives the health data for an engine at a given time: receivedHealthData(e, t1). This is the engine of an aircraft, a, which has earlier been recorded as requiring servicing.
Violation Detection The monitor determines that an aircraft requires servicing but has not been serviced at this moment: unserviced(a, e, t2). It further determines that, contractually, it should have been determined before now. It therefore, reports a violation: violation(a). The causal connection between these two occurrences is documented: violation(a) → unserviced(a, e, t2) .
Cause Determination The operator believes that the health data should have been received at least 10 hours in advance for the manufacturer to be able to complete the job in time. This belief implies a causal connection between an engine not being serviced and that engine's health data being received late (the former was due to the latter). The operator first infers the causal connection from the available data using the following inference rule. Mitigating Circumstances From this, we then have a sequence leading to a violation matching the pre-condition of the following rule: receiving engine health data at a given time caused the engine not to be serviced, which caused a violation.

Part Supplier Late
The following operation of the contract parties is documented.
• The contract constrains the manufacturer to use a given part supplier for parts of a particular type: constrainedP artSupplier(s, p). • At some point, the manufacturer requires a part of this type and orders it from the supplier: partRequested(s, p, t1). • The supplier eventually provides the part: partReceived(s, p, t2).
• The engine manufacturer is required to service an engine that requires a part of the above type. When the part is available, the manufacturer puts the new part into the engine: replacedP art(e2, p, t3). • This repaired engine is later used to swap into an aircraft requiring a service: swappedEngine(a, e1, e2, t4). • A causal chain is recorded: the engine swap required the replacement of the part, which required the part to be received, which required the part to be requested from the supplier, which was made to that supplier because of the contract clause: swappedEngine(a, e1, e2, t4) → replacedP art(e2, p, t3) → partReceived(s, p, t2) → partRequested(s, p, t1) → constrainedP artSupplier(s, p) Violation Detection The monitor determines that an aircraft requires servicing but has not been serviced at this moment: unserviced(a, e2, t5). It further determines that, contractually, it should have been determined before now. It therefore, reports a violation: violation(a). The causal connection between these two occurrences is documented: violation(a) → unserviced(a, e2, t5) .
Cause Determination The operator believes that if the part supplier supplied a part late, this can lead to problems servicing aircraft (specifically, if the part is supplied late if less than 48 hours beore servicing is due). This belief expresses a causal connection between the engine not being serviced and the part being received late. It first infers the causal connection from the available data using the following rule. Mitigating Circumstances From this, we have a sequence leading to a violation matching the pre-condition of the rule below: a constraint on the part supplier caused a part supplier to be used in requesting a part which caused the part to be delivered at a particular time (late) which caused the engine not to be serviced, which caused a violation.

Precondition
Remedy

Related Work
In recent work on normative systems and agreement in serviceoriented architectures, concepts such as norms specifying patterns of behaviour for agents, contract clauses as concrete representations of dynamic norms, management or enforcement of norms itself being a norm, are all already established in the literature [2,3,7,10]. Such work has tended to focus on the infrastructure needed to support such systems and handling of violations is generally through the mechanism of immediately issuing contractually fixed penalties. There are notable exceptions, e.g. longer-term issues are considered by Duran et al. [4], who examine how observation of fulfilment and violation of obligations can feed into a longer-term assessment of agents through testimonials.
There have been many recent approaches to the recording causal documentation so that the provenance of occurrences can be determined. It is applicable to a wide range of applications [8], and has particularly been considered in the context of workflow enactment, i.e. automatically recording documentation as each step of a workflow is executed [5,11]. In our own work we have examined how provenance can be used to interpret and ask questions about the validity of experimental results [6].

Conclusions
When a contract clause between parties is violated, a single fixed penalty is an inflexible way to manage the situation. In many real world cases, the party permitted to enact the penalty may wish to take into account mitigating circumstances, for the sake of the longterm business relationship. Mitigating circumstances, and how to act in case of them, can be expressed in a policy document, but in order to judge circumstances against the policy we need a reliable record of what led to the violation occurring.
In this paper, we have provided an algorithm, and accompanying data structures, for evaluating whether violations were caused by mitigating circumstances, and acting accordingly. This makes use of a contract-based framework, by which we can define the contract clauses, and provenance technology, by which agents can document the causes of what occurs. In combination, this allows us to express and enact mitigating circumstances policies. We have shown how this applies in a concrete example in the aerospace domain. This is preliminary work, which needs to be tested in practical applications. Future work will concern the re-usability of (parts of) mitigating cirumstances policies, and methodological guidelines for constructing them, both aimed at easing the process of implementing such policies in diverse applications.