Automated Negotiation and Contract Markup

[Dave Marvit <dave@marvit.org>]

Automated Negotiation and Contract Markup
Dave Marvit <dave@marvit.org>
Dr. Leff  <D-Leff@wiu.edu>

Automated negotiation reveals several requirements for the  
representation of electronic contracts. However, they do not fit the  
discussion format (Jason’s) that seems appropriate for many of the  
other scenarios. As such, please consider this discussion as a way of  
expressing these requirements. The scenario this discussion refers to  
is available at:
http://lists.oasis-open.org/archives/legalxml-econtracts/200302/ 
msg00016.html

Our model for automated negotiation involves two parties exchanging  
‘proposals’ that represent suggested sets of business terms. These  
proposals require a parameterized representation of the terms. However,  
the proposals need not be the contract itself. All that is required is  
that a contract can be uniquely generated from a set of agreed-upon  
parameters.

This also means that there need be no indication in the contract of  
which terms are negotiable. In fact, from a game-theoretic standpoint,  
there should NOT be any indication in the contract of what is or is not  
negotiable. This reveals more information to the other party than one  
might want to.

It is also a requirement that the negotiation system must be able to  
represent constraints. Some of these constraints can be shared between  
the parties (if you deliver blue widgets then I need them by Tuesday)  
while others are probably best kept internal (I cannot sell more than  
six blue widgets because I only have 6 blue widgets to sell).

In any case, the ability to share constraints mandates that contracts  
be able to represent constraints in a parameterized way.

Making sure that our contract representation supports full  
parameterization and constraint representation is useful in many areas.  
We can easily see how it would be valuable in automated negotiation, in  
drafting, and in compliance. There are probably many other areas as  
well.

So, two requirements emerge.
1. Complete Parameterization such that a contract can be uniquely  
generated from a parameter set.

2. Some method of representing constraints in the contract that can  
also be parameterized.

As far as we have determined, there are no other requirements that an  
automated negotiation system imposes on the format of eContracts.  
(Comments are especially welcome on this point.)

A couple of open questions:
1. Is the markup needed to represent constraints and parameters in a  
contract necessarily the same as the markup that is needed to extract  
them from a contract? (For example, extraction is important for  
compliance, while going from parameters to contract is important for  
negotiation, drafting, and automated contract generation – and possibly  
Dr. Leff’s ‘Dispute Resolution and Litigation Involving Contracts’.)

2. Are requirements for, and applications of, parameterization and  
constraint representation different in different legal application  
areas? For example, do the same methodologies work in contract  
representation and in, say, legal filing applications, or generalized  
document construction outside of the legal realm?


As always, comments are much appreciated.

Dave Marvit and Dr. Leff