>> Venky Ganti: Okay. We can get started. I'm Venky Ganti. It's my pleasure to
introduce Professor Kamal Karlapalem from International Institute of Information
technology. He has contributed over the past couple of decades a variety of areas like
data mining, data warehousing in multiagent systems, workflows, and now he's currently
interested in contracts and we'll hear some of his recent work on this particular topic.
Thank you.
>> Kamal Karlapalem: Thank you, Venky. And it's my pleasure to be here and give this
talk. I got into this area from the workflows point of view. So I was doing these
workflows, and then we were looking at cross-organizational workflows and how we can
basically extract some components of the workflows for inter-organizational or
cross-organizational or applications.
Then we came across these electronic contracts, and this turned out to be an area which is
pretty much [inaudible] for different kinds of work and opens up a lot of interesting
issues.
So in the agenda we'll start with what -- a little bit about electronic contracts, then the
modeling. And one of the key things that I would like to emphasize here is from the
notion of a contract to its actual enactment and production environment, how do we go
about and how do we use workflow technologies to some extent to support this.
So one aspect is it is the data mining aspect that comes in or text mining where you talk
about extracting concepts from contract documents. And it's some form of either
semiautomated or user-enabled or end user-enabled contracts to workflows, mapping that
you need to do.
And a third most important component that we look at is the closure. So in -- what
happens is a company signs large number of contracts. And many of these contracts we
don't know whether they have been closed, whether they have been completed, and they
are in this -- many of them could be [inaudible]. So, therefore, how do we look at the
commitment and payments which is actually the months that you pay for various
deliverables that you do within the contract. So how does the commitment and payments,
they both interact.
So there is the age-old definition which is a contract is an agreement between two or
more parties, especially that is written and enforceable by law. Written in the sense like
you can look back, you can keep a copy, and they are consistent, and you can go to a
lawyer or a judge and say that, you know, this person is supposed to do this deliverable
and he has not done it and therefore I'm going to sue that person.
Recently we [inaudible] also talks about promise and agreement. The key aspect here is
breach of which is recognized by the law and legal remedies are provided.
So these two -- that means lawyers make use of these contract clauses and various other
things to pursue cases and to actually come up with a report to say that how much liable
an organization or a customer is.
So one of the key issues is why are the contracts even there. Contracts are there because
they give you rights. So, for example, if there is a contractor who is building -- who is
repairing the highway, then unless they sign a contract, they can't dig on that particular
highway. So you get rights to actually do the work. So without a contract you don't get
any rights.
And within organizations it is one which regulates the behavior among organizations.
So, for example, the FDA might say that a company which is trying to do some drug
design and drug testing, these are all the things that it should provide by the law and the
FDA should take care of certain aspects of it before it can be -- the drug can be put into
the market.
So it has to be set of obligations that are fulfilled between parties, refused or waived as
future events occur. So if the -- in the early part of the drug testing, you can say FDA
might come up and say no way, it doesn't go anywhere. So -- but it may say some new
obligations have to be made because of the potential of the drug and so on.
So let's look at some contract. This is a part of a hundred-page contract text document.
This is related to a specific aspect of taxes and payments. The highlighted parts are
interesting in the sense like there are pointers, like clause A of schedule A of the contract,
entitled to receive the contract price. So you need to know where you can extract this
contract price and then link it up with it.
Payments against delivery certificates, acceptance certificates, so the system should know
what an acceptance certificate is, who gives that acceptance certificate, the workflow
behind the acceptance certificate. The payments will be made by the purchaser only after
satisfying the satisfactory completion of each milestone as stipulated in systems
requirement document referred in schedule B. So this, again, somebody has to actually
support that.
Here is another contract which talks about change management form. This is basically a
procedure, like the kind of FDA example that I gave, is that in order to -- for a company
like [inaudible] to do some change management for some particular organization, they
have to follow these set of processes.
Even in health insurance, you go for health insurance and then you are hospitalized.
Then the health insurance essentially says within 24 hours you should do this, within 48
hours you should submit this, before you meet somewhere some doctor you should get
this clearance. And if you don't do any of those things, the health insurance companies
might say no way, I'm not paying you anything. So, therefore, the procedural aspects are
quite embedded within the contract document, and extracting that is a big challenge.
So here is another one which talks actually about payment and if you're doing the supply
of goods, by the failure to supply the goods by the time specified on the order will make
supplier liable for unconditional liquidated damage of half percent per week subject to a
maximum of 10 percent.
So this has to go into some application, it has to go into some workflow. Someway it has
to be there so that you know that this has to be conformed. So there is lot of these
nitty-gritty issues that have to be taken care of and has to be supported.
How do we do it now? We have application designer who looks into it, who looks at
these requirements, and we have silos where each of these contracts are separately done,
each of these aspects, maybe this aspect is done by one software, this aspect is done by
another software, and they don't really talk to each other. So therefore you need to have
an integrated view of all these vertical applications.
So what we do is we don't really -- this is a complete lifecycle. Basically this is the initial
stages, do I want to do business with you. Then you say that, okay, what kind of business
do we want to do, and let's have a contract. Then this is the actual stage wherein all these
nitty-gritty details with lawyers are written up. And after that comes the contract
enactment and contract monitoring.
Now, currently in most organizations, this is done by the application software division of
that particular organization, maybe using some workflow management systems, maybe
something like project -- Microsoft Project or some documentations which goes -- the
e-mail oriented Lotus, oriented Solutions. And it is all embedded in those kinds of
softwares, but not as a separate e-contract management system.
I'm not saying it is not being done; it is being done. But we are not having an integrated
view. So I want to [inaudible] that we need to have an integrated view for this.
So we'll go into the modeling aspect of contracts. So if you drill down and find out what
is the code component contracts, you can say contracts help parties; that is, the
organizations or people involved in the business process. That can be Microsoft, it can
be with a caterer who is supplying food for the Microsoft, it can be the activities: the
food should be available by 10:30 in the morning for the tea or coffee session, and if it is
delayed by 15 minutes then the caterer is liable. Right? And the activity, somebody is
checking up: has it come by 10:45 in the morning.
And then there are clauses: the coffee should be of two kinds, decaffeinated and
caffeinated, and it should be of sufficient quantity to serve 250 people who are there.
Right? Multiple coffees, right? And so on. So these clauses have to be done. And the
whole table must be cleared by 11:15 a.m. And you put in these clauses.
And over a period of time you can also have these contracts that can be -- which are
already in place to be renegotiated. So, for example, I can have a contract with Office
Depot to supply my stationery and then I say that, okay, in January of this year I'll say
that I want to renegotiate the price for which I'm taking the notebooks or something.
There is a notion of commitment and transactions stated in the contract, the payment
transactions, the delivery transactions that are done. Exclusions. That is, this particular
contract is -- has -- so since this particular customer is a previous customer, I exclude him
from these clauses. Right? So, for example, if you're looking at a car rental thing, I
might exclude some clauses for you.
Authorization, who is authorized for this contract. And arbitration. Arbitration and
jurisdictions, they both come when the contract fails. That is, who is going to arbitrate,
who is going to actually resolve this conflict between I delivered this and the other person
is saying you did not deliver that. And then of course the code or the jurisdiction where it
has to be fought. So if you look at the clauses, clauses are of different kinds.
Obligations, these state what the parties involved should do. That's resulting in
deliverables and criteria for quality of service. These are the quality of service
parameters.
Payments, we have seen certain payment clauses which can be very intricate and so on.
I'll talk about payments a little bit more. Penalties, if I don't deliver on my obligations,
what are all the penalties that I need to have.
Permissions, what parties are allowed to do, how much they are to do. Prohibitions, what
the parties are not supposed to do. For example, a building contractor cannot have
workers not wearing hardhats, otherwise it's illegal for them to do that. So therefore you
need to -- or you should prohibit them from doing that.
So e-contract is a contract modeled, specified, executed, controlled, monitored by a
software system. Like a database system does so many things with respect to data. This
is a system, software system that does with respect to contracts, and all or are large
number of activities are queried by the software system. There is a human involvement,
there is a system involvement in managing contracts.
So if you look at the contract document, they are fairly structured. If you look at -- you
go to your Microsoft Live and pick up some 20 contracts, and you'll find they are fairly
structured. They are numbered, there are some clauses, there are some generic clauses
which are there. A good way of finding this out is to look at Amazon's written policy,
and you'll find that it is a contract that you're signing when you buy a book.
From the perspective of formatting and semantics, so some semantics are like
government regulations, some legalese that you don't have to worry about it. Some
semantics are actually pertaining to that particular contract in terms of payments, in terms
of quality of service that you are providing.
It can be viewed in different context while you are composing, printing, visualizing,
signing and so on. So this itself is a fairly good challenge for some people to how do I
present the contract documents to lawyers as well as to the project managers who are
actually working on that particular contract. They both need two different views, but
some interrelated common information.
Consists of standard elements. So, for example, the housing -- so if you are renting an
apartment in Seattle, then there's a standard contract that you sign. And then there you
just say per-month rent is so and so forth and so on. So there can be that. And some
individual extensions. So -- can be there. So, for you, in order -- since you are having air
conditioning, we will charge you more. Or we have this requirement for you.
It needs to be exchanged, manipulated in collaborative session, is signed by attaching
signatures. These days "I agree" isn't good enough for signature.
So you have parties, activities, clauses. They can have subcontracts. For a housing
contract I can do plumbing to somebody, electric things to somebody, payments. Most of
the contracts in organizations they have a budget attached to it. So if you are over the
budget or under the budget those issues come in. It needs synchronization across all of
them and has a duration. And these are some additional metadata that you deal with the
contracts.
So when you're going to modeling part of the contracts, contracts being documents have
to be read to understand the intricate details. Somebody has to go through that. A human
being typically goes through it and picks up the various aspects of it. They have structure
and some implicit relationships among concepts. So parties, activities, clauses, and
payments.
Conceptual models have long -- for long have been able to help to visualize and
communicate some of the interrelationships between various entities and various
concepts which are there.
And meta-models, at their simplest level, act as templates for a conceptual data model.
They form a template which can be filled in and it [inaudible].
The key idea here is this Text2Model is a very interesting open area; that is, I've given
you a text document, and then I have some intricate template of relationships that I'm
going to show you. How do I pick up things from this text and fill in this template with
fairly reasonable accuracy, or with certain amount of accuracy or precision, and then
some users come in and do the more intelligent work. And most of the mundane thing is
taken care of by this particular software system.
And I think this is a very open research area. Context is just one example for it. Health
care patient records and all the things is another application for this. You know, so there
can be many applications where you do this Text2Model kind of a thing. I have a
template, I have text, how do I fill it.
So here we have this template -- yeah.
>>: So the model in a sense -- so for a legacy contract, this could be useful. But
wouldn't it be more natural to go from model to X, so you have the model first and then
use your data contract on that?
>>: Yeah, this issue of getting the right extraction.
>> Kamal Karlapalem: That's a good question. See. When I said this piece of work, we
are starting with -- after the document. Now, before the document, there is business
exchange and also contract preparation. At that time you may be doing some modeling,
and then you might be actually coming up with those issues. So wherein you can say first
I have, you know, a protocol and so on for the contract, so you can think of that.
So here is one particular meta-model. So you have contracts of parties, clauses and
activities, so they are all related. A single party can be involved in multiple activities,
satisfying multiple clauses. A contract can have subcontract, which is served as also a
contract.
Parties have different roles. I'm a lender, I'm also a [inaudible], so a bank is both giving
the loan for that and is getting something constructed for itself. Clauses refer to
themselves.
Activities have clauses. There is some synchronization among them. There is a budget,
and there are certain rules that are involved in this particular contract.
So now the basic idea is given a contract document, I want to -- there can be many
contracts, subcontracts, that I need to fill in here, parties I need to fill in here, activities I
need to fill in here, and clauses. But the easier part is just listing of the activities, listing
of the clauses, listing of the payments. The harder part or a more difficult part is actually
saying this activity is related to this clause, is related to this payment.
Those kinds of relationships is what you need to extract, and that is the key issue here.
And that's an open problem. We haven't solved that, but it is an open problem and it's
something that we should be looking at.
So here is a typical contract of buyer-seller. Buyer-seller contract has parties. Parties is
buyer, seller and the bank. Activities are order of goods, shipment of goods, delivery of
goods, transfer of funds between the buyer and seller. Clauses could be payments
exceeds, delivery time is something, and delivery approval.
And here are some rules that are there. So this is a part of the -- we did some work on
modeling rules in ER model way back and we used parallelograms for showing the rules.
And we can say goods damaged during shipment, goods not received, not sufficient
balance, invalid account details and so on. These rules can be also modeled.
So when somebody looks at this particular diagram, they'll be able to figure out what
exactly is that contract talking about, what are the main points of that contract, and they
can -- in the future it should be possible to click on this and look at workflow associated
with that and so on.
So meta-models are -- actually provide a guided approach for conceptual modeling.
Templates can be designed for specific domains for shipping contracts. There is one
template for house rental contracts, there is another template for some -- for these kinds
of vendors there is certain template. Provide generality and also reusability and
extensibility. You can extend these models, the meta-models.
So there have been other approaches like CrossFlow, COSMOS, and EREC, other
approach for doing this.
So the key thing is not the modeling part. I mean, I can do the modeling, I can fill up the
model either by humans or by some software or some tools support. But the more
interesting challenge is for a comprehensive solution for e-contract management. Given
a contract, I need to deploy that contract in the realistic setting. So how do I go about
doing that? So we did some preliminary work in this area, and I'll talk about that now.
So the basic system starts with e-contract document, then we have a template filler, then
we get activity/clause specification. From that we get workflow specifications and
commitment specifications, when does the e-contract end.
And then you have the XFlow enactment environment, and there is a commitment
engine. So commitment specification and commit engine, I won't talk about it in this.
The details of this, what I'll talk a little bit about why -- what kind of issues are there in
commitment aspects. But we'll go through these phases in one [inaudible] manner.
And if you want to look at it from the architecture point of view, you have the contract
document, you have a meta-level where there is this ER meta-schema, then there is a
conceptual layer where you have the data model, the activity party clauses relationships.
Then you have activity commit diagrams, which talk about where does the activity end
and when does it commit. And then at the logical level you have databases, workflows
and workflow instances which are actually supporting this contract. So you can think of
both from the -- from the software point of view and also layering the software across
things.
The key thing that I want to put in here is that there may be already large number of
systems here which do some amount of this work. Now, this kind of an architecture
helps you to compose these solutions which are already available to support under a
single umbrella of contract document.
And that is what I want to convey in this particular talk; that is, it is high time that we
start doing this so that you get a comprehensive view of contract and of where all it
reaches in this organization and how it is actually enacted and supported.
So you have a contract document which is plainly a text document. You have a template
filler; uses named entity tagger and sentence classifier. We used the Rainbow toolkit.
And then activity/clause specification which can be done by humans and with some help
from the system.
So this is the easier part, you know, getting the party names, person names, organizations.
Temporal references. Places. Payment quantities [inaudible]. All these, and then
extracting those sentences which are related to this is the easier part.
>>: So go back to the question [inaudible] asked, which is -- I mean, why [inaudible]
because here you are first [inaudible] the document, then you are tagging it, and then
you're going to extract things from it. But if it gave you that nice software, you'd just
define the contract in a more active manner so that the software pieces fall out of it. You
identify [inaudible] and you are perfectly happy to [inaudible] and sounds -- that sounds
more kind of -- I don't know.
>> Kamal Karlapalem: Yeah. I think there is a [inaudible] -- yeah, it's true that for
some ->>: [inaudible] additional added steps.
>> Kamal Karlapalem: Right. Let me answer it in two ways. Okay. First way is if I
have multiple organizations, I'm looking at large organizations, like you are building an
airport. Okay. Or you are -- you have large number of entities, parties which are there.
They may not have a single software on which they have to build all these things. They
are -- each one is individualized, they are saying that this is what my contract obligations
are going to be. Right? And it is finally somebody signs a book or a huge document
which does that. So there is that class of things. Then there is ->>: So what you're saying is since there's multiple parties to any contract, only one
would be in the position of being able to generate from their model because it's unlikely
that they're all sharing the same model and framework, right? So the other parties all at
least have to be able to read it and digest it as a document.
>>: But, you know, that's what databases do; databases give concurrent access to parties,
and then they work together and [inaudible] something, right? I mean, why is it the case
that because the -- I mean, you can always [inaudible] the current state of the contract
[inaudible].
>> Kamal Karlapalem: Yeah. No, no, that's ->>: [inaudible] from using the same piece of software and maybe collaborating -- you
know, you can -- I can [inaudible] someone else can read that. This is no different, right?
>>: It's a lack of standards, right?
[multiple people speaking at once]
>>: There are some efforts, I know at least in the EU there's a joint e-commerce effort.
>> Kamal Karlapalem: In fact ->>: I'm trying to say this is all [inaudible] easy to do none of that, but I'm saying is
philosophically is that the path we should [inaudible] or this is the path we should
[inaudible]
>> Kamal Karlapalem: I think [inaudible] the point is well taken. In the sense like
suppose if I have some XML [inaudible] version of this model, even after that I still need
to do lot number of things. And maybe some of them will become that more easier.
That's all. But the problem of contract management still arises. Okay. So it is how much
level of support and from where you are providing it.
So there are these standard bodies which are trying to do that, which are trying to say,
okay, we can come up with ebXML or some e-contract XML-oriented standards. But
then, as I was saying, some of these -- let me give you this example of, say, TCS. Now,
TCS signs huge number of contracts with their various partners. And some of these
contracts are actually requests for proposals and the documents for that, and they are just
Word documents which are actually exchanged. And from that you need to glean out.
So now they have -- and they are -- the document by itself is collaboratively dealt with
within the organization. Okay. But finally it is a document that is sent and people say I
approve this document. And that's the legacy aspect of it.
Now, for them to change over from to that to a modeling, there's a change in perception
that has to take place. So if I'm able to move forward to a level where I say that
everything is modelized and I can, you know, just drag and drop things and say this is my
contract, well, then, good, I'm very happy with it. Even after that I can do a lot of things.
But there are subtle reasons why you still want a document. You know, the subtle reason
is you can just say I scratched this clause for you. You know, you and I were talking
across the table, we scratch some clauses, we add some things, we do things and we sign
it off.
>>: The document is a view.
>> Kamal Karlapalem: Right.
>>: And against [inaudible] being the core, the idea is that the core is actually an active
[inaudible] program.
>> Kamal Karlapalem: Right. Exactly. Exactly.
>>: And the document is a [inaudible] which essentially captures the contract [inaudible]
presentation that can be viewed by common people, but the creation, maintenance,
versioning [inaudible] are much better managed ->> Kamal Karlapalem: By software. Yeah. True. But -- yeah.
>>: [inaudible]
>> Kamal Karlapalem: Right. Exactly. It's right. So therefore these are the easier parts.
The -- so we had a patent reconditioned model where we actually look at -- where we
tagged actually the clauses, the activities, and the payment statements, and then we used
both the negative and positive examples and tried to get a Rainbow classifier to learn it,
and we got something like 70 percent accuracy on new contract statements. But that's
some way we could do that.
So given such a contract statement, we could fill it up with these templates, like parties
are so, dates are so much, places are this, the clauses are -- so these are all actually
sentences that we picked up from there. After these sentences we can go back to the
original contract and see if we omit some things and drag and drop some parts of it into
this. And this becomes a building block for the next steps.
So from here you can get it to workflow specification saying that this is the workflow that
is supporting this aspect, this activity of AE contractor, this -- this workflow is actually
going to say whether these clauses is satisfied or not. So if it gives success, the clause is
satisfied, if it gives failure, the clause is not satisfied.
>>: [inaudible]
>> Kamal Karlapalem: This is by humans. This it done by humans. Which some
[inaudible] of you -- you can think of the software that will do this, but it is tricky. It's
not -- because you need to say I do this, then I do that. Some parts are missing from that.
>>: [inaudible]
>> Kamal Karlapalem: [inaudible] right.
>>: I mean, I conceptually get this, and then I [inaudible] the program.
>> Kamal Karlapalem: Right. Exactly. Yeah. Go ahead.
>>: It sounds like, then, you intend to do this in this repeated situation, so you're not so
much wanting to analyze a particular contract as a certain pattern that's parameterized; in
other words, one of these word forms that gets filled in for individual contracts, then you
have a corresponding workflow that works for a whole class of contracts that fit a certain
pattern. Is that [inaudible]?
>> Kamal Karlapalem: Exactly. You can leverage that. You can leverage it in that
manner. Right. The first thing that -- first time you have to do it, you have to do all the
process. Later on you can amortize it over various set of contract [inaudible]. Yes. Then
you get into XFlow -- XML definition of the workflow, and then you can give it to a
software that will actually enact it.
And then you have events we use the SNOOP language to say that this particular clause
is satisfied, therefore now I need to make this payment and so on. So those kinds of
events can be -- will actually run the other aspects of the contract.
Okay. And this was the rehash of what we did in this thing starting from here to enacting
the contracts.
Okay. So the contracts modeling and enactment is one part of it. The other part of the
work is relating to the closure part of the contract, how do I close this contract, how do I
do -- there are -- in case of certain kinds of contracts, you have lot more sense of
activities. So you are doing an activity, we don't know whether that activity is successful
or it has failed, whether it is partial or it is completed. And even if it is fail, then what
else you can do.
So these things become very ambiguous. And in a contract kind of a setup, you need a
mechanism to model these things and support the closure of this contract. At some point
of time we should say I'm done with this contract, now I'm going to start off with
something else. So how can organizations keep track of [inaudible] contracts; that is, it is
no longer in that twilight zone of -- yeah.
>>: [inaudible] why is it not just an application [inaudible]?
>> Kamal Karlapalem: It is an application. Basically used the existing information
extraction techniques. We didn't dial up any new information extraction techniques.
But ->>: I think the [inaudible] contracts [inaudible].
>> Kamal Karlapalem: It gives us a -- it gives us the domain to do some things easier.
So I know that this kind of synthesis actually talk about classes. So that kind of domain
expertise we put in there. But nothing great there, you know, nothing -- but the key
aspect there that I wanted to bring out is Text2Model, in the sense like I have some set of
templates where there are multiple things related and I have text documents. How do I
fill in very nicely. And that's a nice research challenge. It's a nice wonderful problem to
handle. And it has beauty in it to look at. It's got some nice aspects. Yeah.
>>: It sounds like, then, from the text side you're looking at clauses, but really that's a
reference point. The thing that's important in your model is commitments that you're
trying to monitor in terms of relevant events to see if they're fulfilled or unsatisfactory
fulfilled. And then there's a reference to the clause because that's the point at which you
arbitrate or that you go back to the other party when there's a problem.
>> Kamal Karlapalem: Yes. We'll come to that. That's exactly what we are going to
talk about.
Okay. So let's start with a contract for building a house. So if you look at the parties,
there is a customer, there is a builder, a bank, and an insurance company in all that. Ask
for customer specifications, some activities like plumbing and electrical work is
subcontracted. Customer gets mortgage from the bank. The house is insured
comprehensively for market value. Right? And then several
bi- or tri-lateral
contracts may exist for building the house.
And this whole thing is one single contract. From my end point of view, I'm just buying
a house. I don't care about all these subcontracts that are happening around, and I want
that house to be satisfactory and I'm done with it. And if something happens, I'm taken
care of. Right? So this is the environment that we look at.
So this itself is fairly complex. And the initial specifications of the requirements and
later verification of the execution with respect to compliance of the clauses are very
tedious and complicated. How do I know that -- they are supposed to use two-inch pipe
for water. How do I know that they have used really two-inch pipe for water and it has of
this quality, it is fire resistant and so on and so forth. Right? I mean ->>: You have to break the house.
>> Kamal Karlapalem: Yeah, you have to break the house. Or you need somebody to
certify it and then you know you get to that. So somebody inspected that to say that it has
been done. Right? So it is not trivial for -- and you don't want to look into all these
nitty-gritty details, but you need -- the onus is there on somebody that it has been done.
And that is the very key important thing. Who carries that buck to do that is the critical
aspect there.
So there may be interdependent with other activities and clauses. They may be executed
by different parties. The plumbing is done by one and there's electrical wiring which is
done by other. They both are working together. And the wall is being constructed by the
third person. And they are long-lasting. And outcomes of their executions may be
unpredictable. Okay.
So the key issue here that we want to say is the e-contract should reflect both the
specification and execution aspects of the activity at the same time. You know, what are
the outcomes of the execution, what is acceptable, what is not acceptable, and how does it
drive this particular contract. They both are equally important. Where the former is the
composition and logic of the contract and whereas the latter is the transactional properties
of the contract saying that this is done or not.
So the -- you need precise specifications of activities, mapping them to deployable
workflows and providing transactional support for their execution. These are the key
ingredients.
So if you look at the transactional properties, we talk about atomicity and commitment,
and either everything that's done or nothing gets done. And you want to most probably
go for successful completion. That is the commitment. I don't want pluming not to be
done in the house, right? So it is -- it has to be done.
So and then when you want to do the recovery if things don't work, then you want to be
either compensate that or you retry to execution. And this can involve various
sophisticated interactions. Like for an activity, complete and partial executions might be
compensated. Both successful and unsuccessful executions might be compensated. We'll
see examples of this. Even committed transactions may be retried. Retry may mean, in
addition to reexecution, adjusting the previous execution, you do it in some ways.
Activities may be compensated or retried at different times related to the executions of
other activities [inaudible].
>>: [inaudible] rather than [inaudible] the usual workflow management [inaudible] some
people particularly novel here that makes it different.
>> Kamal Karlapalem: Yes. It is in the way that both composition and retrying work
together, and a notion of recommitment that I'm going to talk about.
So suppose -- now these examples are -- do they deal with a house kind of an
environment. You can think of a modern business similar examples.
A pipe is fixed correctly as specified by the contract. So it is committed. Okay. As far
as the plumber is concerned, it is done. Later while constructing a mini-wall the pipe
breaks. So as per the clause, any damage or loss of the goods during the construction of
the house is responsibility of the builder, and the builder has to repair it or replace it at no
additional cost.
So this committed thing has to be retried and resetup. So you have to redo that whole
thing. And as far as your contract lifecycle and everything does, you know that this has
been committed and it has been redone at some later point of time.
In the process of repayment of the bank loan, if a check is bounced for some reason, the
customer has to pay penalty in addition to the actually amount. You are again
compensating for the things that has gone wrong.
So each activity must be closed at some time, so it has to be done. So activities have to
be done. So that is on closure, no execution related to that activity would take place. So
that means it is done, finished, over, and it is not looked at again.
>>: [inaudible]
>> Kamal Karlapalem: So activity here could be a -- could be like plumbing, for
example, that we have done.
>>: [inaudible]
>> Kamal Karlapalem: Right.
>>: So then the pipe was done.
>> Kamal Karlapalem: Right.
>>: [inaudible] broke.
>> Kamal Karlapalem: Right.
>>: So what point was it closed? I mean ->> Kamal Karlapalem: Exactly. We'll come to that. Exactly. That example we'll again
revisit and then I'll tell you where exactly -- where it works on.
Okay. So the closure could be done on complete or incomplete execution, on successful
or failed execution. So when you do it, you might have different possibilities that
happened.
So on closure of the contract activity, so the whole e-contract can be treated as an
activity. And it is composed of various workflows which are there [inaudible]. And now
you can actually say that this is successful, this is fail, and then how do you retrace back
and do various things. So that was the complete picture that we'll get into. So this
involves element of payment and other issues between the parties.
So e-contract closure is referred as an a contract commitment; that is, we use e-contract
commitment logic to refer the entire logic behind the commitment of the various
activities of the e-contract, and closure of the activities of the e-contract. So there is -everything is done. So this whole hierarchy of things is completely done.
So when you start off with this, you need to start off with some notion of a composition.
In the sense like my e-contract consists of these five parties, around 20 activities which
are actually in a workflow. And now I need to say -- I need to have a formal model to
say how this whole thing gets done.
So you have to start with something basic. So you have this notion of basic activities,
those which cannot be decomposed into smaller ones. They may be electronic or
nonelectronic. Some of it done by humans, [inaudible] kind of things. And we would
like the execution to be atomic; that is, either they are completely executed or not. These
are the ground rules on which we are basing our solution. Okay. So our incomplete
executions are unavoidable and we consider them also.
So each activity is executed under some certain -- some -- under certain constraints. Like
who can execute, when it can be executed, which executions are acceptable. So, for
example, when I'm doing a -- laying a road, I need to ensure that there is enough friction
on that particular road to ensure that it is satisfied. Right? So a complete or incomplete
execution satisfying constraints specified at the time of execution is called successful
termination.
The constraints are specified in terms of st-predicate. And the execution which does not
satisfy st-predicate is a failed termination. So I need to say that these things, these
particular logical expression has to be true for this particular activity to be there. How do
I come up with that is a different issue and the related aspects assigned to it. But as a
model, this is a clean model which says that this is the logical expression that has to be
satisfied.
So going through the painting of wall, it is incomplete while being painted. Okay.
Complete after painting is finished. So once I've finished a painting, it is complete.
S-termination if painting job satisfies the st-predicate, like there is one coat underneath
and one coat on top of it, like a white primer and then a color, and no smudges on the
ceilings and various other things. Then this is a paint job. It's done.
So these are the kinds of predicates that you need to come up with to say that it has been
done properly. And this is where even management becomes very critical in a business
sense. Like for this kind of a predicate with various clauses, one event can come from
one system, another event can come from another system, and you have to wait for all
these events to occur to finally say yes, this is done. Okay. So that's where the event
management aspect comes into play.
The constraints may change; that is, the st-predicate of an activity may change because
over a period of time some governmental regulations have changed or something else has
changed. So you can -- so that's again the beauty of this particular thing is that my
st-predicates, I can modify them, as with the needs of the contract, the execution time.
Specification time, these were the constraints, but the execution time, these are the
constraints, so therefore it gives me a very dynamic solution for this.
So I might say that this wall -- you know, there was a prior -- earlier there was a dark
blue color on this, now I want to go into light yellow, so I need two primers. So there are
two [inaudible] to remove that blue effect or something, right, in addition to one
undercoat. So such changes may invalidate the previous execution and then the
execution needs to be adjusted.
So one way of adjusting these earlier executions is compensation. So your compensation
is to nullify the effects of the execution. You have done something and you want to go
back and do something else. So options that are absolute compensation, if possible,
ignoring the original executing -- execution and compensating -- running and
compensating the activity. I've given you -- I've written a check for much larger amount
than what I was supposed to do; I get back a compensation for something else.
Compensation may be constrained by time. Like I need to return something by seven
days.
For an activity, some executions may not be compensatable. This again goes back to the
specification environment and execution environment. In my specification environment I
might say that as for the contract our [inaudible] will fly from Chicago to Detroit. But at
the time of buying the tickets, it may say that they are generally supposed to by fully
refundable tickets but none of them are available or something, it's not available, or
they're supposed to buy nonrefundable tickets and only fully refundable tickets is
available, then you need to buy it and then you need to go.
So therefore -- so compensatability property is attributed to an execution of an activity,
but not to the activity itself. That particular instance of execution, you are compensating.
So retriability is the ability to get complete execution satisfying possibly new
st-predicate. So what happens is you came up with this and then you realize -- so let's say
electrical wiring. So you are not -- you are supposed to do electric wiring like this, but
then you realize that if you do it in this manner, then that electric wiring will have
interference with respect to the cable wire or some other wire which has gone in there, so
now therefore you need to satisfy and you need to redo that, and then you need to
reorganize it so that it doesn't have that conflict.
So retrying may involve partial or full roll back and then a reexecution. Retriability is
also time independent. And some executions of activities may be retriable, some of them
may not be. Again, retriability is attributed to an execution of the activity and not an
activity itself. And retriability and compensatability are orthogonal.
So when you talk about going back to the model, you say that the basic activities, when
they start off, they are both compensatable and retriable. I can compensate this
[inaudible], maybe this possible, maybe not. But from the point of view I can say it is
with that basic start, it becomes noncompensatable but it is still retriable. Then it
becomes noncompensatable and nonretriable. So this is the level set which it reaches.
So an execution may be compensated or retried several times. Execution may be retried
several times in this. And an executed [inaudible] may remain in state (a) forever, and
simply and similarly in state (b) forever. And execution in state (b) is weakly committed,
and the execution in state (c) is strongly committed.
Okay. So therefore the plumbing example is in the state (b) and they have done it -- I
have not finally taken up the house, so therefore I can retry it because it broke and then I
have to fix it.
>>: So what is [inaudible] what is the following definition of noncompensatable
[inaudible]?
>> Kamal Karlapalem: Yeah. No, but noncompensatable in the sense that it cannot go
back to null execute. Yeah, you can -- you can do that in some [inaudible] exactly.
Yeah. Yeah. But then it is still compensatable and retriable scenario. You are not in this
scenario. Right?
So if you look at it, the stages of an activity, you start with it, start, execution is in
progress, then the execution is stopped and you are checking what is the status. When
you look at the status, it can be complete or incomplete fail-termination; it can be
s-termination, or incomplete but weakly committed s-termination.
And then finally when you -- so here you can retry it multiple times. And finally you get
into the states which are closed strongly committed s-termination, or closed non-null
f-termination where you have to do something. I have done partial road and then my
contract, I can't do anything more, so now it's your business. The lawyers come in and
they start doing something else at that point at time, or nontermination. I haven't even
started anything. It is as if like I've given you back the clean slate. Now this is up to you.
So this -- a complete s-termination -- so here this is the explanation of what happens in
these loops. I don't go into the details of these two aspects. Same thing here.
So the final state of execution is closure with three possible states: null, non-null
(complete or incomplete) f-termination -- it is completed but it is not what I wanted or it
is what I -- it is incomplete -- and finally I got exactly what I wanted. And I paid money
to Amazon to deliver me this book; they delivered me this book; it is complete and I'm
done. Or I asked Amazon to deliver me a book but some pages are missing; they
delivered the book but, you know, it's not the thing, so I need to do something else with
the aspect of that.
So this whole work is actually a CoopIS 2007 paper, and we have a composition model
there and where we talk about quite a lot of issues with respect to sequence of activities
and restructure activities, composing activities, and how these weakly committed
executions and the successful executions interact, how do you go about all those details.
I'm not into it, but this is a paper that you can look at if you want further details.
But so this is about commitment, but the key aspect is the payments. So when you talk
about commitment, you need to make payments. So you have done the plumbing, so you
need to make -- and suppose you are doing a -- not doing a bulk house thing but you are
getting it done by various plumbers and electricians and you are paying piecemeal to each
one of them, then you have a lot of payment issues.
So payments are made to parties, constrained by clauses. And they are meant for and not
closely related to execution of activities. That means the successful completion of
activities, the failed completion of activities and so on.
So one should be able to ascertain that actives have been executed satisfactory to deserve
the payment, so this is the underlying system. So it doesn't matter how you're defining
your contract, but when you are defining your contract, you need to bring in -- put in
these hooks to say that this part is done, so this payment has to be made.
Now, currently it is actually a kind of interorganizational workflow between the accounts
department and the other department and there is all these events that float around -between them for the payment to happen.
But these require good understanding of execution of states of activities, and, hence,
execution state of the e-contract. So we need to identify the execution states of activities
in terms of transactional, so compensatability, retriability, and commit properties, and the
related states to costs of payments of that.
Now, the issue that comes up is when you compensate or when you retry, who pays for it.
What is the cost. Now, they -- those are some gray areas which may not be included in
the contract document, and therefore you need to get somebody else to arbitrate on that or
you just discuss across a table and decide on that.
So the cost is associated with s-termination of an activity. If it is successfully terminated
and everything, this is what I pay you. Right? So different s-terminations may cost
different amounts depending upon the environment and the way which done, which
clauses, so I might have a distinction of clauses. It depends upon which distinction this
[inaudible] satisfied. I pay according to that.
So an activity(ai) that is not executed may cost nothing. If executed but compensated,
cost(ai) may be nonzero, but payment may be zero because you have not done anything.
So the reexecution may incur additional costs, therefore the final value of cost(ai) may be
known only after the end of the execution. So if I've reexecuted it, I need to know. So if
reexecution costs are not charged to C, then payment(ai) may be known on weak
commitment of the things. So at the weak commitment stage, I know what I need to pay,
even though I'm not satisfied with that or whatever.
So in context of payments, there are two aspects: one is the enabling of payments, and
then making of payments. Making -- so for each activity, either a single or multiple or
partial payments may be enabled at various states of execution.
We go back to our contracts. You have clauses, you have activities, and you have parties
and you have payments. Now, payments, I can make multiple payments for a single
activity, or I can make a payment for multiple activities. I can make a payment based on
satisfaction of one clause or many clauses and so on and so forth. They are highly
interrelated. And therefore managing this logic within the system is a very interesting
subarea, and it's still very open, not much work has gone in.
And so the commitment aspects and the payment aspects become very critical. Suppose
if you are doing software as a service paradigm and then you have implicit contracts with
all your customers, then how does this whole thing work around. And those -- some
interesting issues will definitely come up there.
Payment can be fully or partially refundable or nonrefundable. So you need a payment
monitoring system that should keep track of state of termination, payment-enabled,
payment-made points, and then amounts, for each activity.
So in -- at the end, what we essentially do is we want to deploy the integrated view of
e-contracts. And modeling to enactment to commitment to payments to closure (path).
That is exactly what we wanted. See the end-to-end understanding of the whole thing.
Now, there are a lot of open issues, open problems, we can build upon it. But this
end-to-end understanding is extremely critical if you want to solve this problem.
A simple prototype system to show viability of the idea. Existing solution, standards,
systems can be plugged in to support an integrated view. So most organizations already
are doing this. They have this path. But they are all individual silos, individual software
systems that are supporting different components with human intervention: e-mail, Lotus
Notes and things like that going on. Maybe it's time to look -- having this e-contract
view may help you to integrate things better, will help you to understand things better,
help [inaudible] in different ways.
So advantages are improve productivity, obviously, right; things go more faster, you
know where your contract is. Accelerated contract lifecycle. Reduced risks. And
improved security; you know that everybody's doing the same thing in this contract, not
different people are doing different things.
Increased profits and superior -- this is an interesting data mining-related work, in a sense
like what I would like to do is I have this like Wal-Mart, it has, you know, a hundred
thousand contracts with its vendors who are supplying various products. I want to know
which clauses are profit making, which clauses are not making profit. You know, which
are losing, where I'm getting a lot of lawsuits and various kinds of things. I would like to
do that kind of work, and then I want to redo my contract so that it is more profitable for
me. You know, other team, other people will also do the same, but at least I can check it
out.
Better compliance enforcement. This is extremely critical because government
regulations might say that you have to keep this data up to five years. After that you are
to destroy that data, you can't have that data, and you need to be able to show that.
Right?
Electronic bookkeeping. This goes back to what you are saying is that, you know, you
need to have -- the legal aspects are extremely critical because what happens is I as a
project manager in TCS, I would like to have a window in front of me where I'm looking
at a contract thing. My lawyer who is in Bombay is also looking at it and we are talking
about how do we get out of this clause. And we work it out. And that is extremely
critical.
Authorizations. Alerts and tracking is the key thing.
So if you go back you can see voluminous documents or voluminous models, if you want
to use that word.
Ambiguity and fuzziness of natural languages. Legalese is fantastic. I mean, if you see
the legal statements, they are mind-boggling in terms of their ambiguity.
Managing and monitoring is human intensive. Autonomous nature. Cross-checking for
payments. Cross-checking for payments is an independent activity. You can take it up as
it's a great problem [inaudible]. Like if I'm making a payment, are all the things that are
supposed to be done for this particular payment done.
Standard formats. Now there are some very good formats for doing this.
Computer-supported contracts. And security.
Handling all these aspects within a system is a fairly good challenge, and that's the -- so I
want to [inaudible] this notion of look at it as a contract. So there are two issues here:
The CEO of a company might come and say to the lawyer, the chief legal office, what is
my liability among all the contracts that have signed, is it 100 million or 500 million? If
all the clauses go wrong, what then what is it my liability. Right? That could be one
thing.
The other thing could be what I'm saying is I can say instead of shareholder value I can
say contract value. You know, which are the contracts which are making profit for me. I
also like to say that a company has contracts with their employees. Employees do work
for a company and there is a value for that particular contract. You can even drill down
to that particular level.
So here are some things. A good starting point is the Internet Computing Spotlight article
that we had in July. We are modeling -- the basic model was in ER. It's some more
modeling work with enactment [inaudible]. I did talk about the whole aspect of contract
evolution and template selection and so on. Those were in ER 2006. Active conceptual
modeling is a new area that is coming up where you can think of having executable
conceptual models and that could essentially work towards what you are trying to say.
And the ER 2007 we did some deep modeling in the implementation. Commitment is in
CoopIS this year and payment is in SCC last year. Already 2009 I think. Okay. And we
have been giving tutorials on this in -- at [inaudible]. Thank you.
[applause]
>> Venky Ganti: Any questions?
[multiple people speaking at once]
>> Kamal Karlapalem: Yeah, exactly.
>> Venky Ganti: Thanks.
>> Kamal Karlapalem: Okay. Thank you. Thank you. Thanks.