1) The document proposes a framework called DACMAS that combines formal models of system dynamics and data manipulation to model data-aware multi-agent systems based on social commitments. 2) In DACMAS, agents maintain local data and are specified via rules for communication and data updates, while a global contract regulates commitment establishment and evolution. 3) Verification of properties in DACMAS is decidable by reducing it to finite-state model checking, even though the systems have infinite runs due to data quantification and an unbounded number of objects/agents.

1. Verification of Data-Aware
Commitment-Based Multiagent Systems
Marco Montali
KRDB Research Centre for Knowledge and Data
Free University of Bozen-Bolzano
Joint work with Diego Calvanese and Giuseppe De Giacomo
AAMAS 2014
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 1 / 22

2. Data-Awareness in Dynamic Systems
Traditional approach to model dynamic systems: divide et impera of
• static, data-related aspects
• dynamic, process/interaction-related aspects.
Notable examples:
• In BPM: data and business processes are conceptually isolated from each
other, and only integrated at the implementation level.
• In MAS: a plethora of logics for reasoning about the behavior of agents and
their interaction, but completely neglecting the exchanged information.
No coherent understanding of what the system is doing.
Our ultimate goals
1 Provide formal models that simultaneously account for the system
dynamics and the manipulation of data.
2 Devise logic-based techniques for the verification and monitoring of
such integrated systems.
This combination poses major challenges to verification.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 2 / 22

3. Social Commitments
Semantics for agent interaction that abstracts away from the internal
agent implementation.
• Seminal work by Castelfranchi: social commitments as a mediation between
the individual and its “normative” relation with other agents.
• Extensive work by Singh et al.: commitments for the flexible specification of
protocols, contracts, interorganizational business processes.
Conditional commitment
cc(d, c, qp, qd)
Debtor agent d commits towards creditor agent c that, whenever condition
qp holds, it will bring about condition qd.
Example (Delivery upon payment)
cc(john, alice, item paid, item owned by alice)
The establishment of (conditional) commitments is typically regulated by a
global contract.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 3 / 22

4. Social Commitments: Critical Assessment
+ Flexibility
• In terms of events: commitments are about
properties/effects of events, not about events directly.
• In terms of interaction: evolution of commitments
determined by the involved agents, through explicit and
implicit operations (commitment machine). [Singh et al., IEEE Comp. 2009]
– Expressiveness
• Atoms of commitment (pre)conditions are usually propositions.
• No possibility of tracking multiple evolutions of the same type of
commitment between the same pair of agents.
• No distinction between commitments and their instances.
John commits for “delivery upon payment” with Alice, vs.
Alice paid item i1, hence John is committed towards the delivery of i1.
• Cf. work by Ferrario et al. on formal modelling of services and commitments.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 4 / 22

5. Making Commitment-Based MASs Aware of Data
To solve the expressiveness issues, we propose to make commitment-based
MASs data-aware. This requires:
• To explicitly account for the data maintained by agents, and the
knowledge used to structure it.
• To define how agents query and update such data in response to
events, possibly introducing fresh data into the system.
• To extend messages/events with their data payload.
• To lift contracts, commitments, and commitment machines to
first-order: each component will employ queries over the data.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 5 / 22

6. The DACMAS Framework
Global TBox
CBox
Contract
Institutional agent
Proprietary ABox
Specification
Event
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 6 / 22

7. Data Model
We use of a lightweight Description Logic ontology language: DLR-Lite.
Global TBox:
• Provides a common ground for agent interaction
• Models concepts and relations of any arity (shared vocabulary)
• Supports inheritance, disjointness, and key constraints (shared
semantic constraints).
Captures most constructs of conceptual modeling languages (UML).
Local, proprietary ABoxes:
• Each agent maintains and evolves its own ABox (nobody can directly
modify the data of another agent).
• Stored objects are from a countably infinite domain ∆.
• A special institutional agent keeps track of system-related data:
(Variable) set of names of all agents currently part of the system.
Immutable set of agent (behavioral) specifications.
Connection between each agent and its current specification.
Data about the current status of contracts.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 7 / 22

8. Querying Data
Typical query language for DL ontologies: union of conjunctive queries
(UCQs).
• Correspond to select-project-join queries in SQL.
• Evaluated using the certain answer semantics (agents have
incomplete information).
We consider two extensions:
• ECQ FOL queries whose atoms are UCQs.
• ECQ location argument to disambiguate where the query has to
be posed.
Example
Item@John(i) ∧ Paid@John(i, Alice) ∧ Owns@Alice(i)
Important: ECQ enjoys first-order-rewritability.
• Query answering can be reduced to query evaluation in standard
DBMS technology, by compiling away the TBox.
• All our results hold also in a purely relational database setting with
constraints.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 8 / 22

9. Agent Specification
Regulate the agent behavior in a data-driven, declarative way.
Proactive behavior: communicative rules
1 Determine which messages with payload can be sent.
2 Choose which to send.
Reactive behavior: update rules
1 Conditionally react to an incoming/outgoing message by invoking an
update action.
2 Apply the update action by modifying the local ABox, possibly
introducing fresh data (taken from ∆).
At each step: infinitely many choices in general!
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 9 / 22

10. Communicative Rules
Shape
Q(r, x) enables ev(x) to r
Semantics:
• Normal agent: issues a query over its own ABox + that of the
institutional agent.
• Institutional agent: could read all ABoxes.
• Each obtained answer grounds the payload of the message and the
destination agent.
This determines a possible outgoing message.
Example
Customer specification: registration request to a seller.
Spec@inst(sel, seller) enables req reg to sel
Seller specification: item proposal to a customer.
MyCust(m) ∧ Item(i) enables propose(i) to m
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 10 / 22

11. Update Rules
Shape
• on ev(x) to r if Q(r, x) then α(r, x) (on-send)
• on ev(x) from s if Q(s, x) then α(s, x) (on-receive)
• on ev(x) from s to r if Q(s, r, x) then α(s, r, x) (on-exchange)
Semantics:
• Upon an incoming/outoing message, evaluate whether the payload +
sender/receiver satisfy a condition.
• If so, apply the update action α with paramaters the payload +
sender/receiver.
Example
Seller reaction to “empty cart” request:
on empty cart req from c if MyCust(c) then doEmpty(c)
Seller reaction to the presence of a new item:
on new item(i) from p if MyProv(p) ∧ ¬Item(i) then addItem(i)
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 11 / 22

12. Update Actions
Shape
α(p) : {e1, . . . , en}. Each update effect e has the form:
[q+
(p, x)] ∧ Q−
(p, x) add A, del D
where:
• A is a set of facts to be added, possibly including Skolem terms.
• D is a set of facts to be deleted.
• Like in STRIPS: add wins over delete.
Semantics:
• Pose all effect queries in parallel.
• For each answer substituting x, ground the facts in A and D.
• Substitute each ground Skolem term in A with an actual value from
∆ agent choice!
• Modify the ABox by deleting and adding the corresponding ground
facts, provided that the resulting ABox is consistent with the TBox.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 12 / 22

13. Update Actions - Examples
Example (Empty Cart)
on empty cart req from c if MyCust(c) then doEmpty(c)
where: doEmtpy(c) : {[InCart(i, c)] del{InCart(i, c)}}.
Example (Item Addition)
on new item(i) from p if MyProv(p) ∧ ¬Item(i) then addItem(i)
where: addItem(i) : {[true] add{Item(i), Price(i, p(i))}}
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 13 / 22

14. Contractual Specification
Shape
Set of commitment rules of the form:
on ev(x) from s to r if Qc(s, r, x)
then ccn(s, r, [q+
p (s, r, x, y)]∧Q−
p (s, r, x, y), Qd(s, r, x, y))
Semantics: when ev is sent from a to b with actual payload d. . .
• If the boolean query Qc(a, b, d) is satisfied, an instance of conditional
commitment n is created between a and b, with payload d.
• Instance manipulated through a first-order commitment machine:
Explicit operations: delegation, cancelation, . . .
Implicit operations: handled by the institutional agent when the
precondition and condition becomes true.
Whenever the partially ground precondition is satisfied with substitution
v for y, a base-level instance is created for n with payload d, v.
When the ground condition Qd(a, b, d, v) is brought about, then such
base-level instance is discharged.
Explicit manipulation of base-level instances allowed, leading them to
different states.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 14 / 22

15. Execution of Commitment Machines
Example (Delivery upon payment)
on accept reg from s to c if MyCust@s(c)
then ccDelivery(s, c, [Item@s(i)∧Paid@s(i, c)], Owns@c(i))
Key Issues
1 How to keep track of commitment instances and their state?
2 How to evolve such information according to the first-order
commitment machine rules?
3 Who is in charge of this?
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 15 / 22

16. Commitment Box
Special relations obtained from the contractual specification.
For each conditional commitment:
• One relation for its instances, keeping track of debtor/sender,
creditor/receiver, payload.
• One relation for the instances of its base-level version, keeping track
also of the extended payload and the commitment state (active,
satisfied, violated, . . . ).
Extension of relations: managed by the institutional agent, accessible by
everybody.
Example
ccDelivery(s, c, [Item@s(i)∧Paid@s(i, c)], Owns@c(i))
leads to:
• DeliveryCC(debtor, creditor);
• DeliveryC(debtor, creditor, state, item).
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 16 / 22

17. From Contracts to On-Exchange Rules
Making commitments operational:
• On-exchange rules automatically generated from the contractual
specification and the semantics of commitment machines.
Note: no detach of conditional commitments anymore!
• The institutional agent is responsible for their execution.
Example (Delivery upon payment)
CC creation rule:
on accept reg from s to c if MyCust@s(c)
then create DeliveryCC(s, c)
create DeliveryCC(s, c) : {[true] add{DeliveryCC(s, c)}}
C creation and discharge (triggered for any exchanged event):
createC(d, c) : {[DeliveryCC(d, c) ∧ Item@d(i) ∧ Paid@d(i, c)]
add{DeliveryC(d, c, active, i)}}
dischargeC(d, c) : {[DeliveryC(d, c, active, i)] ∧ Owns@c(i)
add{DeliveryC(d, c, sat, i)}, del{DeliveryC(d, c, active, i)}}
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 17 / 22

18. Sample System Run
Seller John
Customer Alice
Name
MyCust
Alice
Bob
ID
Item
i1
i2
Item
Paid
Cust
Institutional agent D.
DeliveryCC
C.
DeliveryC
Item
ACCEPT-REG
JohnAlice
Item
Owns
PAY-CC(i1)
Item
Paid
Cust
i1 Alice
D. C. State
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice active
PAY-BT(Alice, i2)
Item
Paid
Cust
i1 Alice
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice active
Alice's Bank
i2JohnAlice active
i2 Alice
deliver(i1,...)
Item
Paid
Cust
i1 Alice
D.
DeliveryCC
C.
DeliveryC
Item
JohnAlice
D. C. State
i1JohnAlice sat
Carrier
i2JohnAlice active
i2 Alice
Item
Owns
i1
Item
Owns
Item
Owns
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 18 / 22

19. Execution Semantics
Infinite-state transition system with states labelled by agent ABoxes.
Loop forever:
1 Pick a sender agent from the table maintained by the institutional agent.
2 Eval all its communicative rules and generate enabled outgoing messages.
3 Pick one of such messages.
4 Manage the synchronous reaction of sender, receiver, and institutional agent,
evaluating their update rules and applying the obtained update actions.
If Skolem terms are involved, pick a value for each of them.
5 If all resulting ABoxes are consistent with the TBox, generate the successor,
otherwise roll-back.
...
. . .
...
. . .
...
. . .
. . .
Three sources of infinity/unboundedness:
• Infinite branching (value choice for Skolem terms).
• Infinite runs (Usage of such values in ABoxes).
• Unbounded ABoxes (accumulation of such values).
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 19 / 22

20. Verification
Requirements for temporal/dynamic properties:
• to capture data first-order queries;
• to capture dynamics temporal modalities;
• to capture evolution of data quantification across states.
We employ µL
ECQ
p , a first-order variant of µ-calculus:
• to capture data ECQ queries;
• to capture dynamics least and greatest fixpoints.
µ-calculus subsumes LTL, CTL, CTL∗
.
• to capture evolution of data quantification over objects/agents
that persist over time in the active domain.
Example (Delivery commitments are honored for gold customers)
νZ.(∀s, c, i.DeliveryC(s, c, active, i) ∧ MyGoldCust@s(c)
→ µY .(DeliveryC(s, c, sat, i)) ∨ (live(s, c, i) ∧ − Y )) ∧ [−]Z
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 20 / 22

21. Key Results
Already for a DACMAS with a single agent, it is undecidable to check
propositional reachability properties.
State boundedness
Each state of the system contains only bounded number of objects and agents.
The system has still infinite branches and infinite runs.
• Unboundedly many objects/agents can be encountered along a run,
provided that they are not accumulated in the same state.
Theorem
Verifying state-bounded DACMASs against µL
ECQ
p properties is
decidable and reducible to finite-state model checking.
Proof.
Reduction to Data-Centric Dynamic Systems [PODS2013], compiling away locations
and the global TBox.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 21 / 22

22. Conclusion and Future Work
DACMAS is a rich framework for modelling data-aware MASs and track
data-aware contracts based on commitments.
• Modelling: paves the way towards a refined theory of commitments
where data are fully taken into account.
• Executability: readily implementable (e.g., in JADE).
Each execution step is in LOGSPACE w.r.t. the agent data.
• Verification: allows in principle to rely on standard model checkers.
Important observations:
• Results immediately extendible to asynchronous lossless
communication with bounded queues/sets.
• State-bounded DACMASs can also be verified against full CTL-FO
with epistemic modalities (cf. [Belardinelli et al., KR 2012]).
Ongoing and next steps:
• Connection with the work on formal ontology for services.
• Fully distributed management of commitments, without relying on the
institutional agent.
• Distributed monitoring and lossy interaction.
Marco Montali Data-Aware Commitment-Based MASs AAMAS 2014 22 / 22