execution to normative relations
submitted in partial fulfillment for the degree of master of science
Simon Kemmere
10798250
master information studies
information systems
faculty of science
university of amsterdam
2020-10-09
First Supervisor Second Supervisor
Title, Name prof. Dr. Tom van Engers Giovanni Sileno PhD
Affiliation UvA UvA
Process model approach to relate procedural insights of a
contract execution to normative relations
A logistics use-case
Simon Kemmere
University of Amsterdam
ABSTRACT
Supply chains are characterised by the large number of parties and data exchanges that are involved. Frequently, these parties can be both partners and competitors in different supply chains. To enable business processes to run smoothly, these parties register obliga-tions of the agreed sale transaction in a contract. However, with the advent of blockchain and smart contracts these obligations can be registered digitally. Blockchain enables the immutable registra-tion of data, whereas smart contracts allow for digital automated execution of logic. Combined, the execution of a sale transaction can be automated and analysed in a formal manner. This research extends existing research by analysing not only the process-level operations but also the association of the process-level operations with the meta-level operations. This concept is applied to the exe-cution of contracts where obligations are subcontracted to a third party. Here, the subcontracted obligations are changed upon re-quest by an actor outside the subcontract. Thus, meta-operations trigger changes at the process-level. PNs allow the modeller to integrate these two levels in order to achieve a more realistic rep-resentation of the contract execution procedure. This creates an audit trail of the interactions between actors and actions of actors. The procedural insight of the audit trail was then related to the transformational apect of the power-liability relation these actors hold during contract execution.
1
INTRODUCTION
Globalization and technological advances have contributed to a growing demand for products and ease with which these can be ordered and paid, and delivered onto your doorstep [26]. The sales of all these products result in large logistic operations. These oper-ations form supply chains which encompass all steps from being shipped from the site of production to the location of the purchaser. Generally, these items must cross many international borders before they are delivered to the purchaser.
A pilot by the shipping company Maersk shows that a single container shipment from Kenya to the Netherlands involved 30 different organizations, over 100 people, and 200 individual infor-mation exchanges [12]. Every time freight is consigned the authen-ticity of documents and the status of freight conditions is verified which complicates the logistics process [28]. Reality teaches that the documents used to verify these process are susceptible to fraud, mistakes, or getting lost. Also, parties are hesitant in exchanging these documents, as they often include sensitive business informa-tion. It is not uncommon that parties within a supply chain are each other’s competitors and can use this sensitive information to their advantage [7]. Granting access to too much data during cooperation can thus result in losing the competitive advantage.
These factors create a sense of distrust among parties [23], which makes exchanging data in logistics a slow process. This stiff coop-eration between parties is exemplified in the same pilot. Namely, one third of the shipment time was dedicated to order handling and administrative processing.
Assessing the authenticity and provenance of the documents within these data exchanges is crucial when this lack of trust is present. Namely, proof of authenticity can improve trust between cooperating parties [22]. Additionally, parties want to ensure that competitors cannot access sensitive business information. This can be enabled by making data accessible based upon predetermined business rules. Currently, compliance with these rules is enforced using legal contracts. In essence, such contracts are written obliga-tions or duties of two (or more) parties to one another (throughout this thesis obligation and duty will refer to the same concept). Con-tracts are created by an independent centralized party, for example a notary. This party specifies the demanded terms of the involved parties.
The cooperating parties within a supply chain arrange with contracts who is responsible for each part of the transportation process. Therefore, a supply chain can be considered as a proverbial chain of contracts or obligations. A contract can be considered as a redundant precaution if all obligations are fulfilled. Conversely, a contract can be presented as evidence to support one’s claim of (non-)compliance in case of a dispute. Creation and compliance checking of contracts by an intermediary can be costly considering the scale on which some organizations operate.
Therefore, the automated enforcement of contracts, rule gov-ernance, and normative modelling, has attracted the attention of scholars from diverse fields such as knowledge engineering, AI, and law. The advent of blockchain and smart contracts can be associated with this quest for automation. Blockchain is characterized by the immutability with which information is registered. This immutabil-ity of information can be regarded as tamper proof in the sense that information cannot be deleted and thus is secure. Especially consortium blockchains are deemed fit to be used in a business environment since read and write restrictions can be put in place (see subsection 2.2 for more background on different architectures). Consequently, access to and sharing of data can be regulated by the parties involved. The characteristics of blockchain enable some ex-ecutable parts of contracts to be registered in artifacts called "smart contracts". A smart contract is a computer protocol registered on the blockchain that verifies, or enforces the execution of a contract digitally and automatically [31]. As these protocols are registered on the blockchain, these protocols are immutable. Consequently, these smart contracts can be trusted.
When the logic of the smart contract can be trusted, its conse-quence is that the state of the actors can be assessed during the execution of the contract. In essence, the execution of the business logic of the contract can be interpreted as an audit trail of interac-tions between the actors. This procedural process can be compared to the obligations parties had as agreed to in the contract between the actor.
In order to perform an analysis of smart contracts in terms of the interactions they enable, we need to look from a higher-level standpoint than the executed code of a smart contract. Generally, this is accomplished by creating diagrams which represent the behaviour of the entities involved. This is the central concern of process modelling. Many types of languages exist that can express process models. Examples are Business Process Modelling Notation (BPMN) [8] or Petri Nets (PNs) [39]. These modelling languages are convenient as they provide a clear visualisation of the system. Espe-cially PNs are interesting as they enable execution and verification of the process model.
Audit trails represented by PNs can be analysed with simple use case scenarios. This simplicity is reflected in the number of actors involved, which is kept to a minimum. Analysis of the operations of these actors is at the process-level. The complexity of the processes at the process-level increases when more actors are added. A change of operations at the process-level can be triggered by an event at the meta-level. However, this change of operations from the meta-level to the process-level cannot be registered at the process level as there is no integration between these levels when analysis takes place at the process-level. Therefore, we argue that analysing complex scenarios only at the process level is an incomplete expression of the operations at both levels. Thus, in order to represent more complex scenarios, the operations on the process-level must be associated with the meta-level operations.
Consider the following example: A contract between a buyer and seller (who is responsible for delivery) states product A is to be delivered to location X. The seller subcontracts delivery of product A to location X by hiring a carrier. When the buyer requests the seller to change the delivery to location Y instead of location X, the meta-level operations trigger a change of operations at the process level. Namely, the obligation of the carrier to deliver to location X is changed to the obligation to deliver to location Y. If analysis takes place only at the process level then meta-level processes cannot influence process-level processes.
This leads to the first research question:
•Can an audit trail of the execution of obligations embedded in a contract between supply chain actors be represented by Petri Nets when these obligations are subcontracted to a third party and the definition of these obligations is changed dynamically during execution?
PNs are an inadequate modelling technique to specify a whole contract formally as they hide certain details that are imperative for formalizing a contract. However, the procedural execution of the contract can serve as a basis to create a formal specification of the contract when the process-level and meta-level of operations are modeled with PNs. A formal specification of norms enables au-tomated analysis of the contract. Even though different approaches
exist to create formal specifications of a contract, we will do so by using eFLINT. Normative relation between actors that are defined implicitly in natural language can be formalized with eFLINT [32]. These normative relations consists of duty-claim and power-liability relations. eFLINT’s resulting specifications can be used to interpret relevant scenarios and support several forms of reasoning such as automatic case assessment, manual exploration and simulation.
Van Binsbergen et al. explain in [32] that eFLINT is action-based and the normative positions are derived from the actions that actors can perform at any given moment. Key to this is the power-liability relation. Namely, power creates the transformational aspect within the specification. Compliance checking of a scenario or software implementation is simplified as these are inherently action-based. Comparing this with the "choreography of interactions" from the audit trail, there seems to be overlap with respect to the action-based nature of the two modelling techniques. In other words, the procedural patterns established with the PN seem related to the prototypical norms related to actions.
This leads to the second research question:
• Can the procedural pattern of the audit trail be related to the transformational aspect of the normative positions of the actors?
In Section 2 of this thesis we will discuss key concepts and exist-ing research on supply chain, blockchain, smart contracts, process modelling with PNs, and the formalization of norms with eFLINT. In Section 3 we will discuss simple and more complex supply chain sce-narios. Then, from these scenarios we will derive the requirements of the contracts needed to model these scenarios. Furthermore, eFLINT modelling is discussed. In Section 4 the simple and more complex scenarios will be presented as PNs. This is followed by an analysis of these scenarios. Then, a simple audit trail is related to its eFLINT equivalent. Findings, limitations and future research directions are discussed in Section 5. Lastly, a conclusion (Section 6) ends this thesis.
2
RELATED WORK
Key concepts and related research is reviewed in this section. First, an overview is provided on supply chains and contracting, what blockchain is and what smart contracts are. This is followed by a section on process modelling using PNs. Then, norms in legal context and formal norm specification languages are discussed. The last section defines the research gap this thesis will address.
2.1
Supply chains
Supply chains can be complicated as many actors are involved. However, in the most basic scenario a supply chain is created as a result of two actors; a buyer and a seller. Generally, a buyer is a retailer who imports certain products in order to sell them in a specific location. A seller can be the manufacturer of the product or a retailer who already bought the product from a manufacturer. For the buyer to physically acquire these products, there is a need for transport. Transportation may be performed by the buyer, the seller, or any other party that the buyer and seller agree upon. However, in most scenarios the responsibility for delivering the goods is with the seller, unless otherwise agreed upon by the buyer.
Transportation is usually left to specialized third parties when supply chains cross borders. The act of transportation is in those cases generally subcontracted to a freight forwarder [28]. A freight forwarder is a company who arranges every link, i.e. party, nec-essary to transport the product from seller to buyer. These links generally consist of carriers who transport the product by road, sea, train, and/or air.
The transportation of the product along the supply chain is reg-ulated by contracts. Consider the following scenario: A contract between buyer and seller states that the seller must arrange trans-port to the buyer. The seller hires a freight forwarder to arrange this transportation which they agree to in a contract. The freight forwarder hires as many as necessary (one or more) carrier(s) to transport the product from seller to buyer. Between the freight forwarder and every carrier, a contract will be created. This will formalize the mutually agreed obligations each party has. The more intermediaries are needed the more complex the system becomes. The complexity of the system is subject to the interest of scholars, organisations and initiatives. For example, iShare1is an initiative from the Dutch government to create standards for data sharing within logistics. [28] propose a data pipeline monitoring system to gain insight in visibility of transport. Other research focuses on better aligning the different flows, i.e. physical flow of goods, flow of information, and flow of finances [36]. The demand from consumers to know where products come from incentivizes research to identify how transparency within supply chains can be increased [30]. Also, research on predictive forecasting is prominent considering the current state of data analytics [13].
For the scope of this thesis we will remain focused on supply chain and blockchain, and specifically smart contracts. Therefore, background on blockchain and smart contracts will be provided in the upcoming sections.
2.2
Blockchain
Blockchain can be defined as a decentralized distributed ledger in which a history of a chronological chain of transactions is present [24]. This chain is formed by blocks which contain validated trans-actions. When new transactions are executed, they are placed in a "holding area". This is a block that is yet to be attached to the blockchain. This detached block traverses over every validated block in the chain after a periodic interval. Its goal is to verify if the new transactions in this block interfere with the transactions already on the blockchain. Verification takes place based upon a consensus algorithm(see [38] for an overview on consensus algo-rithms). When the new transactions do not interfere with already present transactions, the block is added[24, 38].
Besides the storage of transactions, each block contains a times-tamp, a hash value of the previous block, and a nonce. A hash value is a unique sequence of numbers with which the previous block can be identified. A nonce is a random number needed to verify the hash. With this data structure the integrity of the blockchain can be ensured. Namely, every block is connected to its predecessing block. This creates a chain of blocks until eventually the first block (“genesis block”) is reached.
1https://www.ishareworks.org/
Existing data that is changed is assigned a new hash value and all hash values are unique [24, 25, 38]. So when data is changed without permission, it can be easily detected as the old and new hash values conflict. Therefore, fraud can be effectively prevented. The architecture of a blockchain determines whether one can view or store data on a blockchain. The main attributes of a blockchain architecture are determined by consensus, visibility, and control. Visibility is defined by if or how freely parties can view what is stored on the blockchain. Control then identifies the scope of oper-ations actors can perform on the blockchain. This can be enforced permissionless or permissioned. This means that either anyone or a selected group of actors can perform operations on the blockchain. Visibility is established in one of three ways: public, private, and consortium.
Anyone can view and perform operations on the data stored on a public blockchain. This necessarily means control is permissionless. Correctness of the stored data is decentralized as the ground truth is reliant on public consensus [24]. Due to its architecture, the process of verification in a public blockchain is relatively slow. Namely, anyone can add data and thus as part of the consensus protocol, new data must be verified by traversing over all previously attached blocks. Logically, if more users can interact with the blockchain, more blocks are part of the blockchain, in which case all blocks need to be verified if a new block is added.
The architecture of a private blockchain facilitates use by a sin-gle party. This party wants to benefit from the immutability of the ledger but wants to keep all data and information in-house. Visibility of the blockchain is private. This means only this party has the permission to view data stored the blockchain. Control is permissioned as this party chooses whether other parties can perform operations on the blockchain. However, it is unlikely other parties are granted permission to perform actions on the blockchain given that the visibility of the blockchain is private. Consensus is centralized as the party operating the view and write permissions also determines the correctness of the data.
Consortium blockchains are characterised by being a combi-nation of a public and private blockchain. The operators of the blockchain determine the view and scope of operation execution of external parties through an access control layer. This centralizes the ability to enforce access to the blockchain, i.e. a permissioned blockchain. However, the correctness of data is established using distributed consensus between the cooperating parties, i.e. thereby decentralizing enforcement of consensus. This type of blockchain is generally suited for interorganizational cooperation as access to information can be governed per party while keeping the benefits of a decentralized ledger.
In this light, consortium blockchains are being extensively re-searched in the field of supply chain. Applications are found in different areas. For example, [5, 18, 33] all proposed ways that enable tracking of different batches of food from a producer to a wholesaler. The food supply chain faces a central problem. Namely, when one of the batches is spoiled, this exact batch cannot be re-trieved due to distribution to retailers. Consequently, all batches within a certain date span are retrieved to prevent customers from getting sick. With blockchain all relevant information is recorded at every step of the distribution process. This enables the wholesaler only to retrieve the relevant faulty batches.
A different application comprises of the continuous tracking of temperature during the transport of temperature sensitive products, such as medicines [2]. A log of the temperature during transport can be kept with the help of temperature sensors embedded in a container. When this data is registered on the blockchain an im-mutable audit trail can be created enabling involved parties to assess whether temperature has influenced the quality of the transported cargo (see2for an enterprise application).
2.3
Smart contracts
A smart contract is a set of code that is executed on a blockchain when certain premises have been validated and found correct. This computational artifact allows two parties to digitally interact ac-cording to predefined rules. The terms of the smart contract deter-mine the logic of the execution [35]. In [19] an example of a smart contract was defined which we will use to illustrate the execution process of a smart contract (see Figure 1).
First, the terms of the contract are defined (step 1). Then, the seller allocates his goods as defined by terms of the contract (step 2). When a buyer accepts the contract, he agrees to conform to the terms of the contract, i.e. pay sum X to receive ownership rights of product Y (step 3). Subsequently, the terms of the contract are digi-tally validated, i.e. if the buyer has enough money and if the seller is the rightful owner of the product he wants to sell (step 4). Then, ownership rights and currency can be automatically transferred the moment the terms of the contract have been validated (step 5). In Figure 1 an example of a smart contract is presented. Looking at the different obligations we can derive from this contract, the following becomes apparent: There is the obligation to allocate the goods to a certain location and the obligation to pay. However, this contract is abstract in the sense that only two parties are involved, i.e. seller and buyer. As discussed earlier, a real supply chain may consist of many more actors. Furthermore, the actors to the con-tract are also the actors that execute the concon-tract. The scenario would be more complicated if the obligation of allocating goods is subcontracted to a carrier. This event creates obligations within obligations and thus the process becomes much more complex to oversee. These extra actors and obligations between actors make logistics much more dynamic compared to the static nature of this example (this notion will be readdressed in subsection 2.6). 2.3.1 Smart contracts and auditing.The characteristics of blockchain and smart contracts enable the creation of digital audit trails. With these audit trails it can verified if actors have adhered to the con-tract. Consequently, non-compliance can be verified more easily as these digital audit trails can be trusted. Non-compliance with a contract can be identified in two moments: ex ante and ex post, meaning before and after the fact respectively [20]. Ex post iden-tification of non-compliance is more related to dispute resolution. Namely, the identification of non-compliance ex post may be cause for a dispute which can elicit the need for resolution. On the other hand, ex ante identification of non-compliance is concerned with preventing non-compliance beforehand.
Research in contract law describes that with the introduction of smart contracts, a shift is apparent from ex post to ex ante [17]. 2https://modum.io/
Figure 1: Abstract smart contract example scenario.
This shift is enabled through the properties of blockchain and smart contracts as it allows for automated validation of compliance before-hand. A scenario where every contract can be enforced ex ante is deemed ideal as no dispute resolution is required ex post. However, [17] also state this is unrealistic. Namely, not all possible outcomes can be recorded in a smart contract beforehand. Therefore, ex post dispute resolution will remain part of the enforcement of smart contracts.
Establishing an audit trail beforehand can help identify possible generic desired or undesired sequences of events during the execu-tion of the contract. In order to create an audit trail an overview of the different processes must be created. The next section will describe the concepts to do so.
2.4
Process modelling
2.4.1 Modelling contracts. The research on modelling smart con-tracts is diverse. It ranges from modelling approaches that enable semi-automatic smart contract generation [9], to modelling the priority of business transactions [21], to modelling the negotiation part of a contract [6, 16].
The presented research has the creation and analysis of correct-ness of the contract itself in common, i.e. whether the outcome of the execution of the contract logic matches its proposed outcome. However, representations of the behaviour needed to achieve an audit trail of the contract execution is under represented.
[37] used BPMN for model driven engineering of the behaviour of contract execution. The BPMN represents a choreography nor-mally performed by the smart contract. It includes more actors than normally is the case. However, changing contract obligations is not part of the representation. Furthermore, BMPN lacks the characteristic of verification inherent to PNs.
Research using PNs to represent the behaviour needed to execute the scenario is conducted by [3, 4]. In this research the flow of execu-tions was represented using Documentary Petri Nets. These types of PNs allow for distinctions between and specifications of infor-mation, goods, price, time frames for deadlines, and role modelling. As such the specific intricacies of the contract can be modelled.
These works have aimed to model the contract execution. How-ever, by using Documentary PNs a level of granularity was used which does not fit the posed research question of this thesis. Namely,
that is to identify the changing of the obligations during the execu-tion phase of the contract. As such, the use of a more complicated type of PN does not seem warranted. Therefore, the following sec-tion will describe background on classical PNs.
2.4.2 Petri Nets. A Petri Net is a formal mathematical modelling notation for distributed systems developed by Carl Adam Petri in 1962 [27]. Distributed systems integrate input from and generate output to multiple acting entities. This handling of input and output can be regarded as a series of events. An event can trigger one or multiple unconnected events at the same time, but only if it fits their specific conditions. This execution of events is partially ordered, i.e. in a specific sequence, which in turn can trigger different events. Different partial orders represent different execution paths of the system.
PNs can be used to model the behaviour of very complex and/or technical systems due to the intuitive visual notation. By executing a token game, the requirements, properties and processes of a system can be analysed. This facilitates easier understanding of the system for non-scholars who may lack field expertise. This also makes PNs popular in the analysis of (early stage) software development [14]. PNs are composed of places (condition) and transitions (events). Places (circles) and transitions (squares) are connected by directed arcs (edges). Places can only be connected with transitions and vice versa, ultimately creating a directed graph. Tokens (black dots) within a place represent a resource. If all conditions needed to cause an event are fulfilled, the transition may use the token to fire. If the transitions fires, the token traverses from one place along the transition to the subsequent place. This would then signify the event has caused a new condition to occur.
2.5
Norms in legal context
2.5.1 Background. The research field of AI and law is developing frameworks and languages enabling automated ex ante verification of (non-)compliance. Namely, contracts, or law in general, is about assessing whether behavior is in line with the norms embedded in these judicial (but also societal and moral) entities, or not. Different deontic modalities exist such as obligation, permission, and pro-hibition. Judging behaviour with these modalities as the criterion results in if one can consider an action right and wrong.
The normative modalities have been extensively formalised us-ing deontic logic in order to capture the logical features in a com-putational manner. Different types of deontic logic exist and have been used to reason with the normative modalities found in legal artifacts. Examples can be found in [1, 10] utilising standard deontic logic and defeasible deontic logic in legal context respectively.
However, Hohfeld was of the opinion that the deontic modalities lacked the perspective of actor and recipient. This inclusion enabled the denomination of eight fundamental legal relations which suffice to represent all necessary legal relations between two parties bound by, for example, a contract. These legal relations included the notion of power as Hohfeld believed the set of relations was incomplete without [15]. This led to the following legal relations: duty-claim, liberty-no claim, power-liability, and disability-immunity.
Since Hohfeld, different perspectives emerged on the amount of legal relations needed to represent legal artifacts. The two formal norm specification languages discussed in the next section both
adopt the perspective of two relations. Namely, Van Doesburg & van Engers (2019) argue "there is little difference between the position that there are two or four fundamental normative relations. There is not much difference to claiming a liberty-noclaim relation is fun-damental, or that it is the same as an absent claim-duty relation." [34]. Consequently, the power-liability and the duty-claim correla-tives remained. The duty-claim relation expresses a future action or state that needs to undertaken or reached. It relates the duty holder to the claimant of this duty. Generally, this type of relation is enforced by a time constraint or penalty to assure fulfillment of this duty. The power-liability relation is the explicit consideration of change caused by an actor exercising a ‘power’ (performing an action), possibly having an impact on the actor with the correlative ’liability’ position.
The concept of power is ambiguous as it can refer to different principles, i.e. (physical) ability and (institutional) power. These need to be distinguished since power in the power-liability relation only refers to institutional power. Ability refers to the disposition to perform an action [29], e.g. if I am strong enough to remove the lid from a jar I can use its content to cook. Institutional power is situated in institutional reality. This concept of reality refers to abstractions from physical reality. Therefore, institutional power refers to the principle of actions that create or modify institutional facts, e.g. if I am the legal owner of a product, I have the power to transfer ownership to my professor. If the professor recognises my power to transfer legal ownership and he wants the product, he can become the legal owner of this product. This makes him liable to receive ownership of the product. Hence, liability is concerned with recognising that the opposite party is in a position of power (see [29] for more in-depth discussion on Hohfeld’s fundamental legal relations).
2.5.2 Formal norm specification.Contracts, laws, and other jural artifacts with embedded norms are generally formulated in natural language. Namely, they are usually designed by lawyers, and pol-icymakers etc. As already deliberately formulated, the norms are embedded, i.e. implicit. Both the implicitness with and the natural language in which these norms are described prohibit reasoning with them. Symboleo is a language which allows a user to specify contracts explicitly. Symboleo uses an ontology as its basis. On-tologies enables its user to capture concepts of domains at various levels of abstractions. Specifically, the UFO-L ontology of Griffo et al. is used [11]. This ontology uses Alexy’s A theory of constitu-tional rights as a basis which is a derivation of Hohfeld’s theory and captures the essential elements of a legal contract, e.g. legal position (see [? ] for in-depth discussion). Symboleo can only be applied to contracts which is a strength and simultaneously a weak-ness. Specification may lead to better developed applications while specification also prohibits findings to be applied in a more general manner.
The domain-specific language (DSL) for formalizing norms as ex-ecutable specifications (eFLINT) can be applied to different types of legal artifacts [32]. This language is action based and the normative positions of actors are derived from the actions they can perform, or are expected to perform at a given moment in time. eFLINT uses Hohfeld’s theory on legal relations and is therefore comparable to Symboleo. In contrast, the language can be used to formalize norms
from a large variety of sources. For example, eFLINT was applied to certain GDPR articles to demonstrate its functionality. The re-sulting specifications are executable and support several forms of reasoning such as automatic case assessment, manual exploration and simulation. Moreover, the specifications can be used to develop regulatory services for several types of monitoring, control and enforcement. The possibility of a broad application warrants the use of eFLINT over Symboleo even though Symbeleo may be the more typical choice in this research since contract execution is assessed.
2.6
Research gap
The preceding sections provided an overview of background on supply chains, blockchain, smart contracts. Also, (non-)compliance, an approach to describing and modelling these processes was dis-cussed. Lastly, norms and formalization of norms were disdis-cussed. As mentioned in subsection 2.4 the methods that are verified with use case analyses lack a realistic component with respect to the execution of these contracts and as such obligations. Either research includes only two parties (buyer and seller), or do not incorporate changing obligations. In order to incorporate this realistic compo-nent, we must add extra actors, the subcontracting of obligations, and changes of these subcontracted obligations. Then, an audit trail can be created that represents the execution of a more realis-tic supply chain scenario. Such an audit trail can facilitate ex ante model-checking of smart contracts in the current, but not limited to, field of supply chain. Subsequently, using eFLINT we aim to assess the changing of the normative relations between actors. Then, we aim to provide a proof of principle by relating the visual procedural aspect of the audit trail to these changes in normative relations.
The following section will describe the method with which we aim to capture the dynamics of the obligations within the audit trail. Furthermore, the method to specify norms explicitly is explained.
3
METHOD
In the simplest supply chain scenario, the duties embedded in a contract between two supply chain actors are fulfilled by the actors to the contract. However, one actor may subcontract the fulfillment of a duty to a third party. This adds obligations between the sub-contractor and the subcontractee. Additionally, duties may change upon request. This scenario may occur when the claimant requests to change the delivery location. In order to represent this dynamic aspect of the fulfillment of a duty, we construct some use cases. The exact definition of the contract is dependent on the scenario. Therefore, we must first construct scenarios of a different com-plexity in order to capture this dynamic aspect. As many factors influence the representations of these scenarios, some assumptions must be made in order for the scenarios to be sound. Following, the contracts needed to enable these scenarios can be constructed. Here too, some assumptions have to be made in order to construct consistent and comparable scenarios. Then, it is identified how the execution of the contracts in the scenarios can be represented using PNs. Lastly, the method to specify norms explicitly using eFLINT is discussed.
3.1
Scenarios
Generally, in a simple scenario the buyer and seller are the same as the receiver and carrier, respectively. We will represent Alice as the seller/carrier and Bob as the buyer/receiver.
In the case Alice subcontracts transportation, she is released of the title of carrier. The new carrier will be referred to as Carol.
Additionally, it is common that during the contract is in force, a buyer might request the product to be delivered to a different location. If this request is granted, the request conflicts with the existing contract. The initial contract needs to be terminated before a new contract can come into force if all relevant parties decide the request shall be honored.
This leads to the following specified scenarios below3:
• Scenario 1Alice has ten iPhones which Bob wants to ac-quire in exchange for a certain amount of money. They agree that Alice will transport the iPhones to Bob at location 1. • Scenario 2Scenario 1 can be extended when Alice decides
to hire a third party, a carrier Carol, to transport the iPhones to location 1.
This scenario can occur when Alice has no means, or oppor-tunity to transport the iPhones.
• Scenario 3Scenario 2 can be extended when Bob realizes that the iPhones should not be shipped to location 1 but to location 2. This requires Bob to request Alice to change the location of delivery. Consequently, Alice is required to request Carol to transport the iPhones to location 2. Such requests can drastically influence the schedule of Carol. For example, if location 2 is much further away than location 1, Carol does not have access to the carrier for a longer time. Any transportation jobs arranged after the initial sale may thus be delayed. Consequently, Carol will want compensa-tion and thus a new contract needs to be negotiated between Carol and Alice. Alice will want to recoup these costs from Bob and thus a new contract between Alice and Bob is ne-gotiated. Only if Bob agrees to the increased cost, the new contract between Alice and Bob, and Alice and Carol can be signed.
This scenario can occur when Bob would like to resell the iPhones. For example, a buyer at location 1 has retracted its interest and a new buyer is found at location 2.
• Scenario 4Scenario 3 can be extended when Bob realizes that the iPhones should not be shipped to location 1, but the shipment should be split evenly and shipped to two different locations, i.e. location 2 and location 3. This requires Bob to request Alice if she can transport five iPhones to location 2 and five iPhones to location 3. Consequently, Alice must request Carol if she is able to transport five iPhones to location 2 and five iPhones to location 3.
This scenario can occur when when Bob would like to resell the iPhones. For example, a buyer a location 1 has retracted his interest and two new buyers at two new locations are found, i.e. location 2 and location 3.
Within these scenarios, multiple recurring components can be iden-tified. Firstly, the interaction between buyer and seller. Secondly, 3Note: Every scenario shall contain one example with the consideration that there are
the possible subcontracting of the delivery from seller to carrier. Lastly, the request by a specific party to change the content of the initial contract, i.e. the request to change the present duties.
3.2
Contracts
All scenarios have the same starting point. Namely, scenarios 1, 2, 3, and 4 all start with a contract between seller and buyer. Therefore, this contract shall be referred to as contract 1. In scenario 2 a contract between seller and carrier is added, which also occurs in scenario 3 and 4. This contract shall be referred to as contract 2. Then, in scenario 3, seller and buyer, and seller and carrier terminate the old contract and start a new contract. These new contracts shall be referred to as contract 1.1 and 2.1 respectively. Lastly, in scenario 4, seller and buyer, and seller and carrier terminate the old contract and start a new contract. These new contracts shall be referred to as contract 1.2 and 2.2 respectively.
Contracts need to be constructed which formalise the agreement between buyer and seller. This facilitates better execution of the agreement described in the supply chain scenarios. Consequently, parties’ duties are registered which enables accountability of the actions parties execute. Many templates of a sales contract exist containing the most frequently used clauses in sales contracts, e.g. footnotehttps://www.docsketch.com/contracts/sales-contract-template/. However, for this thesis it is only relevant to include clauses which are necessary to execute the sale. Therefore, contract 1 should at least reference the following aspects of the sale:
•The availability of the product and the intention to purchase. •Transportation terms, e.g. who will transport the product. •Purchase terms, e.g. price, installments etc..
•Inspection of product on delivery. •Transfer of ownership.
Contract 2 is different as it is an agreement about transporting a product and not about becoming the owner of a product. However, the above-mentioned clauses can serve as a template that can be applied to this specific agreement:
•The availability of the product for shipping, and willingness and ability to ship.
•Delivery terms, i.e. whereto the product to. •Finance terms, e.g. price, installments etc..
•Responsibilities when product is rejected at delivery. In scenarios 3 and 4, Bob will request Alice to deliver the prod-ucts to a different location than agreed upon in the contract. In order to accept this request, Alice will need to request Carol to change the location to which she aimed to deliver the products. This request does not satisfy what was agreed upon in the initial contract between Alice and Carol. In order to accept the request, new contracts need to be signed and the old contracts need to be terminated. Contracts 1.1, 1.2, 2.1, and 2.2 must contain something of the following:
•Reference to the earlier agreed upon contract and the termi-nation of all duties resulting from this contract.
3.3
Petri Nets
The execution of a contract in a specific scenario can be represented as a series of actions by actors and interactions between actors.
Generally, these series of actions and interactions are the same for every sale. The sequence of events may differ slightly depending on what the buyer and seller agree to. In reality much more events take place before a sale is executed and a supply chain is constructed. For some of these events it is redundant to include them as the aim is to represent the execution of a contract. Therefore, we assume the following for the execution of the sale between buyer and seller: • Offering of the product by either party to either party has
occurred.
• Negotiations with respect to the contract, e.g. price, delivery etc., have already taken place and the contract is signed and has come into force.
• The burden of transportation lies with the seller. In reality this is influenced by whether the sale is Business-to-Business (B2B) or Business-to-Customer (B2C) related. In B2B sales, the burden of transportation can lie either with the buyer or seller. However, transport is generally arranged by the seller. In B2C sales, the burden of transportation generally lies with the seller. Taking large e-commerce companies such as Amazon4, Zalando5, or Bol6as example, products may be
scattered among different warehouses in different countries. Consequently, arranging transport is much easier for the business than for the customer. Additionally, it is considered a service by customers to not have to invest in transport. • Payment occurs after the inspection of the product. This
simplifies the scenario as modelling of the refund does not have to be included when the product is rejected by the buyer.
• If the buyer rejects the product, the burden of retrieval of the product lies with the seller. This simplifies the scenario as the seller does not have to retrieve the product himself or using a carrier.
• The products will always be delivered.
With these assumptions in mind, and for consistency and com-parison reasons, we will assume the following sequence of events for every scenario:
(1) Start of the contract.
(2) Seller makes the product available and buyer intends to buy the product.
(3) Transportation and delivery.
(4) Acceptance or rejection of product by buyer. (5) Payment by buyer.
(6) End of the contract.
The notion that series of actions and interactions are similar for every sale also holds for the actions and interactions between the seller and carrier. Before a sequence of events can be presented, some assumptions have to be made:
• Contract negotiations between seller and carrier have al-ready taken place.
• Carrier has no duty to retrieve the product upon rejection by buyer.
With these assumptions in mind the following sequence of events is assumed:
4https://www.amazon.com/ 5https://zalando.nl/ 6https://bol.com/
(1) Start of the contract.
(2) Willingness and ability to ship by carrier and willingness and ability to pay by seller.
(3) Pick-up and delivery.
(4) Payment by seller regardless of acceptance or rejection by buyer.
(5) End of contract.
The last recurring component is when the buyer requests to change the contract. The contracts between the buyer and seller and the seller and carrier were assumed to be negotiated. However, it is imperative to incorporate the negotiation process as it is part of the execution of the initial contract.
In order to present the sequence of events, first some assumptions must be defined:
•The buying party is the party requesting to change the con-tract.
•The moment of realization by buyer that the location has to be changed will occur when transport is en route. Namely, this is the most inconvenient time for the buyer to request to change the contract. As a result, the carrier is most likely to demand a financial compensation for services rendered and thus the need for new contracts is most prominent. •The contract negotiations between the carrier and seller, and
the seller and buyer will have a positive outcome.
With these assumptions in mind the following sequence of events is assumed from the moment the product is en route from the seller to buyer which is carried out by the carrier:
(1) Buyer requests seller to change the deliver location. (2) Seller realizes the conflicting contracts between buyer and
seller and seller and carrier.
(3) Seller requests carrier to deliver to a different location. (4) Carrier is willing to comply for a new fee.
(5) Seller communicates increased fee to buyer. (6) Buyer accepts.
(7) Seller accepts.
(8) New contracts are signed and initial contracts and thus duties are terminated.
(9) Duties need to be fulfilled as described by the new contract. Furthermore, it is assumed that similar actions of actors and communications between actors will occur more than once. Conse-quently, consistent notation of these actions and communications facilitates better understanding of the process.
The following notation of actions and communications have been identified:
•Inter-actor communication exists of a sending actor and re-ceiving actor and a subject which they communicate about. These events can thus described as send + subject and receive + subject. The condition in between these events is the con-dition where communication takes place. This can thus be described as communicate + subject.
•When inter-actor communication takes place, it may happen that the answer of the receiving actor is required before this actor can execute the next event. This places the initial send-ing actor in a condition where the actor awaits a response. Hence, this can be described as await + subject.
• Contracts are a formal notation of duties between two actor. Thus, the start and end of a duty can be described as start duty + first letter Holder + first letter Claimant + number of dutyand end duty + first letter Holder + first letter Claimant + number of duty.
3.4
Norm specification with eFLINT
Specifying norms in legal artifacts using eFLINT requires the cre-ation of three frames the Act, Duty, and Fact frame. A short descrip-tion will be provided next, but for a more detailed overview see [34]. The Act frame describes normative actions performed by an actor resulting in normative changes addressed to an actor that is either receiving the results or is an interested party. This frame is called an Act frame, because it describes all the aspects of the function that changes a state due to a normative action performed by an agent. The Act frame is considered to exemplify the power-liability relation between two normative actors. The actor is in a state of power and the receiving actor in a state of liability. The Duty frame represents a duty, or obligation, that is an act that ought to be performed in the future, or ought to have been performed in the past in case of a violation of the duty. It exemplifies the duty-claim relation between two agents. Here, the duty belongs to the duty holder, and the claim to the claimant. The Fact frame is used to make more detailed statements on the condition which must be satisfied before an act can occur, also called the precondition. Every fact in the function of a Fact frame, can be the subject of a new Fact frame. The level of detail that is pursued depends on the purpose of the analysis.
4
RESULTS
Within this section, the questions posed in the introduction will be answered based on the provided literature and method, and are verified by engineering. The first question was: Can an audit trail of the execution of obligations embedded in a contract between supply chain actors be represented by Petri Nets when these obligations are subcontracted to a third party and the definition of these obligations is changed dynamically during execution? In order to do so, the specified contracts per scenario, and the execution of these contracts per scenario with PNs will be presented and discussed. The second research question was: Can the procedural pattern of the audit trail be related to the transformational aspect of the normative positions of the actors? First, the scenario will be presented, followed by an analysis of the PN with respect to the dynamics of the normative positions.
4.1
Contracts
In the previous sections, we presented abstract descriptions of the clauses necessary to be included in the different contracts in order to execute the sale properly. Furthermore, we identified significant overlap of the contracts used in each scenario. Therefore, in this section only contract 1 and contract 2 and a summary of contracts 1.1, 1.2, 2.1, and 2.2 will be presented. A full description of contracts 1.1, 1.2, 2.1, and 2.2 can be found in the appendix (Section 6). 4.1.1 Contract 1.From the abstract description of the contract between Alice and Bob the the following contract is derived:
This Sales Agreement (the “Agreement”) is entered into between Alice [Seller] and Bob [Buyer]. Seller is willing to sell 10 iPhones [Products] and Buyer wishes to purchase these products. Therefore, Seller and Buyer agree as follows:
(1) Sale of iPhone. Seller shall make the Products available for sale and Buyer shall purchase the Products.
(2) Delivery. Seller shall deliver the Products to Buyer. The Products shall be deemed delivered when Buyer has acknowl-edged the delivery.
(3) Purchase Price & Payments. Seller agrees to sell the Prod-ucts to Buyer for €2500,-. Seller will provide an invoice to Buyer after Buyer has accepted the delivery. All invoices must be paid, in full, within thirty (30) days. Any balance not paid in full within thirty (30) days will result in the claim to transfer the remaining funds. Any balances not paid within thirty (30) days will be subject to a five percent (5%) late payment penalty.
(4) Inspection of iPhone & Rejection. Buyer is entitled to inspect the Products upon delivery. If the Products are un-acceptable for any reason, Buyer must reject them at the time of delivery. In the event Buyer rejects the Products, the contract between Buyer and Seller will be terminated. 4.1.2 Contract 2.Contract 2 can be defined as follows:
This Sales Agreement (the “Agreement”) is entered into between Alice [Seller] and Carol [Carrier]. Seller wishes to have 10 iPhones [Products] shipped to Location 1 and Carrier is willing to ship these products to Location 1.
Therefore, Seller and Carrier agree as follows:
(1) Shipping of Products. Seller shall make the Products avail-able for shipping and Carrier shall ship the Products. (2) Delivery. Carrier shall deliver the Products to location 1.
The Products shall be deemed delivered when delivery is acknowledged at Location 1.
(3) Shipping Price & Payments. Carrier agrees to ship the Products to Location 1 for €250,-. Carrier will provide an invoice to Seller at the time of delivery. All invoices must be paid, in full, within thirty (30) days. Any balances not paid within thirty (30) days will be subject to a five percent (5%) late payment penalty.
(4) Rejection of delivery at Location 1. In the event the Prod-ucts are rejected at location 1, Seller will be responsible for retrieving the Products from Location 1. Seller will be liable for payment for shipping under the terms of clause 3. Payment in full for correct services rendered as determined by this contract will terminate the contract between Seller and Carrier.
4.1.3 Contract 1.1.In scenario 3, contract 1.1 comes into force as a result of Bob’s request to Alice to change the location of delivery. Consequently, renegotiation takes place. Contract 1.1 thus includes two additions to the preamble and one alteration in clause 3. These changes are as follows:
•With this Agreement Seller and Buyer recognize the earlier entered into contract and wish to formally terminate that
contract. This releases both parties from all duties, claims, and liabilities resulting from that contract.
• All Products are to be shipped to Location 2.
• The price of payment has increased from €2500,- to €3000,-4.1.4 Contract 2.1.In scenario 3, contract 2.1 comes into force as a result of Alice’s request to Carol to change the location of delivery. Consequently, renegotiation takes place. Contract 2.1 thus includes two additions to the preamble and one alteration in clause 3. These alterations are as follows:
• With this Agreement Seller and Carrier recognize the earlier entered into contract and wish to formally terminate that contract. This releases both parties from all duties, claims, and liabilities resulting from that contract.
• All Products are to be shipped to Location 2.
• The price of payment has increased from €250,- to €500,-4.1.5 Contract 1.2.In scenario 4, contract 1.2 comes into force as a result of Bob’s request to Alice to split the shipment and distribute this shipment over two new locations of delivery. Consequently, renegotiation takes place. Contract 1.2 thus includes two additions to the preamble and one alteration in clause 3 and 4. These changes are as follows:
• With this Agreement Seller and Carrier recognize the earlier entered into contract and wish to formally terminate that contract. This releases both parties from all duties, claims, and liabilities resulting from that contract.
• 5 iPhones [Products1] are to be shipped to Location 2 and 5 iPhones [Products2] are to be shipped to Location 3. • The price of payment has increased from €2500,- to €3500,-• Buyer is entitled to inspect the Products1 and Products2 upon delivery. If Products1 and/or Products2 are unacceptable for any reason, Buyer must reject them at the time of delivery. If one or either part of the shipment is rejected it will terminate the contract between Buyer and Seller. Buyer will be liable for every part of the shipment that is accepted, i.e. Products1 or Products2, or both.
4.1.6 Contract 2.2.In scenario 4, contract 2.2 comes into force as a result of Bob’s request to change the location of delivery. Conse-quently, renegotiation takes place. Contract 1.1 thus includes two additions to the preamble and one alteration in clause 3. These alterations are as follows:
• With this Agreement Seller and Carrier recognize the earlier entered into contract and wish to formally terminate that contract. This releases both parties from all duties, claims, and liabilities resulting from that contract.
• 5 iPhones [Products1] are to be shipped to Location 2 and 5 iPhones [Products2] are to be shipped to Location 3. • The price of payment has increased from €250,- to
€750,-4.2
Execution of the contracts
With the aforementioned contracts we can now create PNs in order to identify how the duties change in different scenarios. Only the most relevant parts of the models will be discussed. For structur-ing reasons it is decided that the start of a duty and a contract is highlighted by a red square, relevant conditions and events are
highlighted by a blue square, and the end of a duty and contract by a yellow square. Furthermore, all figures from the upcoming section can be found in Appendix Section 6.
4.2.1 Scenario 1. From the contract used in scenario 1 we can derive two duties. Namely, (1) the duty, held by Alice, to deliver the product to Bob; and (2) the duty, held by Bob, to pay Alice. The duty to deliver starts the moment the contract comes into force (see red square in Figure 2). This duty ends the moment Bob acknowledges to Alice that the products have been delivered (see yellow square in Figure 2). Due to this formulation the only compliant action is to deliver. Failing to deliver, i.e. never receiving the delivery, will result in the token remaining present in the place "product delivery" (see blue square in Figure 2).
Figure 2: Initiating and ending the duty to deliver. After delivery, Bob is allowed to inspect the products and choose whether to accept or reject the shipment. In case of rejection, the condition enabling the duty to pay is not satisfied as the contract states only accepted products must be paid. As a result, the contract can and will be terminated as no duties are left unfulfilled.
Contrary, if Bob chooses to accept the products, his duty to pay will start (see red square in Figure 3). This starts a payment process in which three possible flows of events can be executed: Bob pays 100% of the amount within 30 days, Bob pays 100%-x of the amount within 30 days, Bob pays 0% of the amount within 30 days (see three blue squares in Figure 3).
The general flow is similar for each scenario. Therefore, the execution of events when 100%-x is transferred will serve as an example, which is highlighted in Figure 4. The events and conditions related to Alice are highlighted in red, communication between Alice and Bob is highlighted in blue, and events and conditions related to Bob are highlighted in orange. Based upon the invoice sent by Alice, Bob decides to pay 100%-x of the amount within 30 days. Bob transfers this amount which enables Alice to assess whether this is payment is compliant with respect to the contract. The amount is not sufficient which enables Alice to request the
Figure 3: Initiating the duty to pay.
Figure 4: Execution of payment and end of duty to pay and contract.
remainder of the amount. Bob then transfers this remainder, thereby fulfilling his duty to pay. With this fulfillment, all duties have been completed and thus the contract is terminated.
Important to consider is that the overall payment scenario is an iterative process. Alice will assess again if all funds have been trans-ferred when Bob transfers the remainder of the funds. Furthermore, Bob may choose not to comply with Alice’s request to transfer the remaining funds. Alice can request Bob again to transfer these funds. A possible outcome scenario may be that Alice chooses to enforce compliance via a judge. However, these scenarios have not been constructed because the focus of the research question is to analyse fulfillment of the duties presented in the contracts. 4.2.2 Scenario 2.Scenario 2 starts identical to scenario 1. Namely, a contract between Alice and Bob comes into force. For Alice this starts the duty to deliver to Bob (see Figure 5). Alice chooses to subcontract transportation of the products to a carrier, Carol. This
Figure 5: Start of contract to subcontract transport to Carol.
starts a contract between Alice and Carol and as such a duty to Alice held by Carol to deliver to Bob (see Figure 5).
The product can be delivered when transport details have been sent. This enables the places where Alice will want confirmation from both Carol and Bob to verify if ultimately the products have been successfully delivered (see blue square "await delivered Carol" and "await delivered Bob" Figure 6). Furthermore, it becomes clear that in order to end Alice’s duty to deliver to Bob can only be ended when Alice receives confirmation from Bob that the products have been delivered. Namely, the condition "end duty A-B1" (yellow square) can only be enabled by "receive delivered Bob" (blue square). In similar fashion, Bob needs to confirm to Carol that the shipment has been delivered in order to complete the duty held by Carol to Alice to deliver to Bob. If all these places have fired it means that the product is delivered to Bob, and Carol has received the necessary confirmation to send an invoice to Alice. This starts a duty to pay held by Alice to Carol. This payment flow will proceed as described in subsubsection 4.2.1.
Concurrently, Bob decides whether to accept or reject the prod-ucts. If accepted this starts a payment flow as described in subsub-section 4.2.1. The contract between Bob and Alice terminates if Bob chooses to reject the products as no duties are left unfilled. How-ever, the contract between Alice and Carol remains active. Namely, the contract states that payment should occur if the product was delivered to Bob.
Important to note is that Alice is not released from the obligation to deliver to Bob even though she has subcontracted the act of delivery. Namely, if Carol fails the duty to deliver the product to Bob, Carol fails to comply with the contract between her and Alice. Consequently, Alice fails to deliver the product to Bob and as such does not comply with the contract between her and Bob. 4.2.3 Scenario 3.Scenario 3 starts identically to scenario 2 up to the moment the product is en route from Alice to Bob. From there on it can be divided into three separate parts as visualised in Figure 7. Firstly, the phase where a request is made which conflicts with the duties registered in the present contract (orange segment). Secondly, there is the renegotiation between the parties (purple segment). Lastly, there is the signing of the new contract and consequently the end of old and start of new duties (light blue segment).
Figure 6: Fulfilling duty and ending contract.
Within the orange segment the event "new insight" is responsible for the onset of the request to change the delivery location (see blue square in orange segment of Figure 7. This request results in the condition where the contract between Alice and Bob, and Alice and Carol requires change. Therefore, Alice requests Carol to draw up an offer which includes the change of location. With this event the renegotiation segment of the scenario is entered (see purple segment of Figure 7).
Carol creates a new offer for Alice. Considering the offer, Alice desires new terms between her and Bob and constructs a new offer which she communicates to Bob. Bob agrees to the new offer, and as such Alice can agree to the offer made by Carol. These events create the condition where every party is ready to sign the new contract (see blue squares in purple segment of Figure 7). Consequently, the next segment of the scenario is entered, i.e. the ending of old and start of new duties (see light blue segment of Figure 7).
Within this last segment the contracts between Alice and Bob, and Alice and Carol are signed. With these events a new duty to deliver to the new location is started. Concurrently the old duty to deliver to the old location is terminated. This notion is identi-cal for both the contract between Alice and Bob, and Alice and Carol (see blue squares in light blue segment of Figure 7). From this moment the scenario follows the same flow as discussed in subsubsection 4.2.1.
It is important to note that the renegotiation segment is very abstracted. Namely, the negotiation process between the agents is generally more complex as it probably requires more communi-cation back and forth. This is especially true when the first offer between either renegotiating pair of agents is not accepted directly. This again emphasizes the iterative aspect of the process.
Additionally, in the current representation there is no room to reject the offer by either party in either renegotiation process. This
Figure 7: Three phases of changing the contract. Orange: Contract conflict. Purple: Contract renegotiation. Light Blue: Ending of old and starting of new duties.
does limit the generalizability to a real scenario. However, for the scope of identifying the changes in duties it is necessary to include successful negotiations. Namely, without successful negotiations a new contract cannot be started and thus no new duties are started. 4.2.4 Scenario 4.Scenario 4 starts identical to scenario 3. The initial contracts have started, and Carol is en route to transport the products to Bob. However, Bob now requests the shipment to be split and delivered to two new locations. The scenario thus enters a renegotiation phase identical to the one in the purple segment in Figure 7. However, the signing of the new contracts differentiates scenario 4 from scenario 3.
Instead of one new duty, two new duties are created, i.e. the duty to deliver to location 2 and the duty to deliver to location 3 (see red squares in light blue and purple frame in Figure 8). This process occurs for both the contract between Alice and Bob, and Carol and Alice. The start of the new contract between Carol and Alice enforces that the current shipment is split (see blue square under light blue frame in Figure 8). Consequently, a new truck is needed and the truck already in use requires a new delivery address.
The product can be delivered and acknowledged to be delivered if all conditions are satisfied by Bob and Alice, and Alice and Carol (see blue square in purple frame in Figure 8). These events then trigger the condition where the duties to deliver are satisfied by Alice, i.e. the yellow squares in Figure 8. Concurrently, Bob commu-nicates to Carol that delivery has occurred. With this condition the duties to deliver can be ended. Once every party has acknowledged and received confirmation of the deliveries, payment processes start. These processes follow an identical procedure as described in Figure 3 and Figure 4. However, as the shipment is split Bob may inspect both shipments. By inspecting, Bob may choose to accept both, either, or none of the shipments. Logically, payment for the shipment(s) occurs accordingly. When executing the token game this is represented by the presence of two tokens. Here each token signifies a shipment. These tokens can then be manipulated in executing either of the acceptance scenarios in Figure 3.
Figure 8: End and start of duty dynamics when splitting a shipment.
Figure 9: Delivery flow of a split shipment.
4.3
Relating PN to eFLINT
A higher level scenario must be defined to demonstrate how the procedural insight can be related to the normative relations between actors as specified by eFLINT. This is an abstracted version of the earlier presented scenario 1 with a seller (Alice) and buyer (Bob). The integral components of this sales contract execution are presented in a PN (see Figure 10). When the contract is started, the duty for Alice to deliver starts. While Alice transports the product, Bob awaits this delivery. Once delivered, Bob acknowledges this delivery which is confirmation that the duty to deliver held by Alice is fulfilled. Bob communicates acceptance of the product if he chooses to accept the product after his inspection. This enables Alice to create and send an invoice. Receiving of this invoice by Bob starts the duty to pay for the product. Payment, and communication of payment ends the duty of Bob to pay Alice which finalizes the sale and contract.
Essential to eFLINT is that normative relations are described and allowed to change over time by the effect of actions and events [32]. These Acts have been highlighted in Figure 10 with red squares. As mentioned, Acts portray a power-liability relation in which the actor executing the action holds the institutional power to perform this action (see orange stars in Figure 10). Since the normative position is always in relation with its opposite normative position, the receiving interested party holds a position of liability (see green stars in Figure 10). Each normative position is part of a specific relational duo. These have been highlighted by the grey areas in Figure 10.
This information facilitates the design of the eFLINT specifica-tion. Firstly, the level of granularity with which the PN is designed translates to the granularity with which the eFLINT can be de-signed. Namely, the PN could have been designed to omit every event besides the start contract, transport product, and pay entities. Then, the procedure relating to the eFLINT would indicate only to include these entities as Acts. Specification of eFLINT based on a PN may be irrelevant for simple procedures as procedural steps can be identified without the need for visual confirmation. However,
Figure 10: Dynamics of normative relations during contract execution. Red square: Act. Blue square: start or end of duty. Green star: Position of liability. Grey: the specific relational positions.
oversight may be lost quickly if more complex or more granular processes are represented. The current PN is a proof of principle with which this application is demonstrated.
The PNs throughout this research have always started from a mutual and neutral situation since both actors can initiate the start of the contract. Important to note is that the specification of an Act with eFLINT is always started by one specific actor. Therefore, for the specification of the eFLINT it is assumed that the seller has the ability to start the contract. To create the institutional Fact that the contract is started, Alice (seller) needs to be in a position of power and Bob (buyer) needs to recognise Alice is in power which results Bob to be in a position of liability. The action of starting the contract starts the duty to deliver by Alice to Bob. This can be specified explicitly with eFLINT throught the following declaration. The Related to clause determines that the action of starting a contract is concerned with a specific combination of product, amount, and a sale (transaction) identifier. Both the contract related to this specific combination of entities and the duty to deliver by seller to buyer is created.
Act start-contract Actor seller Recipient buyer
Related to product, amount, sale) Creates
contract(seller,buyer,product,amount,sale), deliver-product-duty(seller,buyer)
The subsequent Act is transporting the product. Alice is in pos-session of the product and holds the ability to either deliver the product or not. Also, Alice is in a position of power as the duty created in the previous Act created the duty to deliver (see orange star near "transport product" transition in Figure 10).
The instantiating of this duty gave Alice the power to fulfill this duty by transporting the product. Logically, Bob is liable to receiving the product which is indicated by the green star in the "await delivery" place (see Figure 10). The related eFLINT specification allows this power-liability relation to be declared explicitly.
Act deliver-product Actor seller Recipient buyer Related to product Conditioned by contract(seller,buyer,product,amount,sale) Creates product-delivered(product)
The explicitation of this power-liability relation enables the user to reason if a product is delivered as regulated by the contract.
Alice needs acknowledgement from Bob that the product is de-livered. Thus, Bob needs to have the ability to let Alice know the delivery is received. Here, the positions of power and liability switch to the opposite sides, i.e. Bob in a position of power and Alice in a position of liability. Namely, the event of delivering by Alice places Bob in a position of power as Alice recognises Bob can determine if the product is received. Consequently, Alice is in a position of liability. This relation is signified by the green star in the "await de-livered" place and the orange star in the "send dede-livered" transition. This can be specified in eFLINT with the following declaration.
Act receive-product Actor buyer Recipient seller Related to product Conditioned by product-delivered(product) Creates product-received(product) Terminates deliver-product-duty(seller,buyer)
This declaration shows that the buyer is in a position of power to acknowledge to the seller that the product is received. The Re-lated toclause reflects that acknowledging the product is received concerns the product. The (pre- and post-) conditions explain that acknowledging the product is received can only occur if the product is delivered. In this case, the duty from seller to buyer to deliver is terminated.
