Expressing and Verifying Business Contracts with Abductive Logic Programming

1. Expressing and Verifying Business Contracts with Abductive Logic Programming M. Alberti1, F. Chesani2, M. Gavanelli1, E. Lamma1, P. Mello2, M. Montali2, P. Torroni2 1ENDIF, University of Ferrara 2DEIS, University of Bologna

2. Normative Multiagent System • (from discussion group) • A system whose components (agents) can violate part (norms) of the system specification. Constraints cannot be violated. • Useful model of open agent societies (where agents are not “certified”). • Specification and verification of norms should be external to agents. NorMAS 2007 Seminar - Dagstuhl

3. Outline NorMAS 2007 Seminar - Dagstuhl

4. The SCIFF framework • Logic language based on Abductive Logic Programming. • Developed in the EU-funded SOCS project for specification and verification of agent interaction protocols. • Proof procedures to prove compliance to protocols and protocol properties. NorMAS 2007 Seminar - Dagstuhl

5. Abductive Logic Programming • Abductive logic program: a triple <P,A,IC> • P is a logic program • A is a set of predicates called abducibles(hypotheses) • IC is a set of integrity constraints • Abductive explanation of a goal G: set  of abducibles such that • P   |= G • P   |= IC NorMAS 2007 Seminar - Dagstuhl

6. Specification • A contract specification in SCIFF is an Abductive Logic Program • Abducibles represent hypotheses (expectations)about the behaviour of the interacting entities. • Declarative semantics: definition of compliance to the specified contract. NorMAS 2007 Seminar - Dagstuhl

7. The SCIFF language • Description: • Events: actual behaviour • Expectations: desired behaviour • Specification • Knowledge base: declarative knowledge • Integrity constraints: relation between events and expectations NorMAS 2007 Seminar - Dagstuhl

8. Events • Represent the actual behaviour. • Syntax: H(Description, Time) • Description is a ground term. In this talk: tell(Sender, Receiver, Content[, Dialog]) • Time is an integer. • A set of events is called history. NorMAS 2007 Seminar - Dagstuhl

9. Events: example The event H( tell( telco, c, phone_bill(390512093086, 145886, 205), 19) says that telco sent to c a phone bill (for the number 390512093086, whose identifier is 145886 and whose amount is 205) at time 19. NorMAS 2007 Seminar - Dagstuhl

10. Expectations • Represent the desired behaviour • Can be • Positive: events expected to happen • Negative: events expected not to happen • May contain variables • Variables can be constrained (CLP). NorMAS 2007 Seminar - Dagstuhl

11. Expectations: positive • Syntax: E(Description, Time) • Example: the expectation E( tell( telco, c, phone bill(390512093086, Id,Amount), T) means that telco is expected to send to c a phone bill for the number 390512093086, with some identifier Id, for some amount Amount and at some time T. NorMAS 2007 Seminar - Dagstuhl

12. Expectations: negative • Syntax EN(Description, Time) • Example: the expectation EN( tell( telco, c, phone bill(390512093086; Id,Amount), T) means that telco is expected not to send to c a phone bill for the number 390512093086, with any identifier Id, for any amount Amount and at any time T. NorMAS 2007 Seminar - Dagstuhl

13. Fulfillment (informally) • Positive expectations are fulfilled if they are matched by events; negative expectations are fulfilled if they are not matched by events. Otherwise, violated. • H( tell( telco, c, phone_bill(390512093086, 145886, 205), 19) • fulfillsE( tell( telco, c, phone bill(390512093086, Id,Amount), T) • violatesEN( tell( telco, c, phone bill(390512093086; Id,Amount), T) NorMAS 2007 Seminar - Dagstuhl

14. Knowledge base • Set of clauses whose body can contain expectations: • Head Body • where Head is an atom and Body is a conjunctions of atoms and expectations NorMAS 2007 Seminar - Dagstuhl

15. Integrity constraints • Implications • Body→ Head • where Body is a conjunction of events, expectations and atoms, and Head is a disjunction of conjunctions of expectations. • Variables can be constrained (useful esp. for deadlines) NorMAS 2007 Seminar - Dagstuhl

16. Sample contract clauses: KB NorMAS 2007 Seminar - Dagstuhl

17. Sample contract clauses: ICs NorMAS 2007 Seminar - Dagstuhl

18. Sample contract clauses: ICs NorMAS 2007 Seminar - Dagstuhl

19. Sample contract clauses: ICs NorMAS 2007 Seminar - Dagstuhl

20. Sample contract clauses: ICs NorMAS 2007 Seminar - Dagstuhl

21. Sample contract clauses: ICs NorMAS 2007 Seminar - Dagstuhl

22. Semantics: contract instance • Given a contract specification S = <KB, IC> and a history HAP, SHAP is the pair <S, HAP>, called the HAP-instance of S. • HAP is compliant to S if there exists a set of expectations with certain properties (see following slides). NorMAS 2007 Seminar - Dagstuhl

23. Semantics: consistency • A set EXP of expectations is ¬-consistent if and only if for each ground term p and integer t and • A set EXP of expectations is E-consistent if and only if for each ground term p and integer t NorMAS 2007 Seminar - Dagstuhl

24. Semantics: fulfillment • Given a history HAP, a set EXP of expectations is HAP-fulfilled if and only if and • Otherwise, EXP is HAP-violated. NorMAS 2007 Seminar - Dagstuhl

25. Semantics: abductive explanation • Given a contract specification S = <KBS, ICS>, an instance SHAP of S and a goal G, EXP is an abductive explanation of SHAP for G if and only if where CET is Clark’s equational theory and TX is the constraint theory. NorMAS 2007 Seminar - Dagstuhl

26. Semantics: goal achievement • Given an instance SHAP of a contract specification S = <KBS, ICS> and a goal G, iff there exists a ¬-consistent, E-consistent, HAP-fulfilled set EXP of expectations that is an abductive explanation of SHAP for G, we say that G is achieved w.r.t. EXP (and we write SHAP╞EXPG • A history HAP is compliant to a specification S iff SHAP╞EXPtrue. Otherwise, HAP violates S NorMAS 2007 Seminar - Dagstuhl

27. Example: compliant history NorMAS 2007 Seminar - Dagstuhl

28. Example: non-compliant histories NorMAS 2007 Seminar - Dagstuhl

29. Expectations and Norms (CMOT special issue on NorMAS’05, published in 2006) NorMAS 2007 Seminar - Dagstuhl

30. Runtime verification System NorMAS 2007 Seminar - Dagstuhl

31. The SCIFF proof procedure • Extends Fung and Kowalski’s IFF • Rewriting system (transitions) • Success = Compliance, Failure = Violation • Proved terminating, sound and complete • Implemented in SICStus Prolog + CHR and integrated in SOCS-SI (a component interfaced to coordination and multi-agent platforms) NorMAS 2007 Seminar - Dagstuhl

32. Static verification • Verification of contract properties • Performed at design-time by the g-SCIFF proof procedure. • Differently from SCIFF, given a contract it can generate compliant histories, besides checking histories for compliance. • How? H abducible and a further transition that turns positive expectations into events NorMAS 2007 Seminar - Dagstuhl

33. Property verification with g-SCIFF • To verify whether a formula f is a property of a contract C, we run g-SCIFF with C as a specification and f as a goal. • success with a history HAPproves that HAP is a counterexample of f (so f is not a property of C) • failure suggests that f may be a property of C. NorMAS 2007 Seminar - Dagstuhl

34. Static verification example • If a phone bill is sent, then the customer will pay for it. • Negation: NorMAS 2007 Seminar - Dagstuhl

35. Static verification example • g-SCIFF goal: • Success with • HAP is a counterexample of f. NorMAS 2007 Seminar - Dagstuhl

36. Conclusions • The SCIFF framework for business contracts: • Specification • Run-time compliance verification • Design-time contract property verification • Future work • Completeness result for (restricted?) g-SCIFF • Management of violation (CTD? Priorities? In progress) NorMAS 2007 Seminar - Dagstuhl

37. Expressing and Verifying Business Contracts with Abductive Logic Programming M. Alberti1, F. Chesani2, M. Gavanelli1, E. Lamma1, P. Mello2, M. Montali2, P. Torroni2 1ENDIF, University of Ferrara 2DEIS, University of Bologna Thank You!