[legalxml-econtracts] Scenario: Contract Generation Systems

[Sergio Maldonado <sergio@smaldonado.com>]

Title: OASIS LEGALXML ECONTRACTS TC - SCENARIO

OASIS LegalXML eContracts TC Requirements Process

Scenario -  Contract Generation Systems

Name	Contract Generation Systems
Principal Stakeholders	Legal Professionals in Private practice
Scenario Owner	Sergio Maldonado, sergio@smaldonado.com
Draft Number	1
Draft Date	February  23, 2003
Contributors

Introduction

 Although in legal terms a "contract" can be defined as the final result of an exchange of promises (for the breach of which the law gives a remedy or the performance of which the law recognizes a duty), the same term is often used to refer to a written draft produced by either one of the parties along the way with the intention of being agreed upon in the near future in accordance to a certain legal figure as such figure is recognized in a given legal system. In effect: A pre-assembled compilation of certain terms that, according to the applicable legal system, would frame the resulting relationship within the limits of a specific legal figure.

A "legal figure", as defined above, could therefore be a "sale of goods", "supply of services", "copyright licence", "real estate tenancy", "confidentiality agreement"... etc, its scope, obligations and limits determined by the applicable statutory and case law in the legal system where such figure arises.

Scenario Statement

Virtually everybody needs to make use of a "pre-assembled" contract (a "draft"), as defined above, at some point in time. Such pre-assembled contracts enable everyone to enter into more or less sophisticated legal relationships with relative simplicity. As lawyers, we also make use of pre-assembled contracts, as they avoid us having to start from scratch every single time.

However, pre-assembled contracts pose important limitations:

a) Non-lawyers are not able to ascertain the flexibility of the terms: Some of them must remain as they appear on a sample draft for the contract to have the desired effect (namely, that the parties end up creating the envisaged "legal figure"), while some others may be subject to a choice of pre-defined options (therefore allowing certain negotiation) and some others remain absolutely flexible.

b) Lawyers may find it a daunting task to update all relevant terms in their pre-assembled contracts, plus all those in the sub-agreements that such pre-assembled contracts may have emerged from every time a new court decision or statute directly interferes with them.

c) Lawyers and non-laywers alike will normally find it extremely hard to produce a similar contract (or obtain an analog legal figure) in a separate legal jurisdiction where the flexibility of the terms for such legal figure might vary greatly.

Computer-based systems have arisen in the past allowing lawyers and businesses to obtain "customized" pre-assembled contracts and tackling the aforementioned limitations with more or less success, but mostly limited to a specific area of law (and very limited range of legal figures) and a particular legal system.

 The arrival of XML may now provide the necessary tools towards creating fully-operating, computer-based "contract-generation" systems (or "wizards") with much greater ease and interoperability.

Contract Generation Systems and XML

Contract Generation Systems (CGS) should be able to:

1. Identify particular sub-agreements within a given draft (each sub-agreement could represent a "legal figure")

2. Group clauses by reason of the sub-agreement they belong to (eg. a particular "quantity" may belong to a "sale" in a contract that combines a sale of goods and a supply of services)

3. Capture the different options available to the formulation of every single clause (and thus, a "force majeure" clause will by nature be much less flexible/negotiable than a "choice of jurisdiction" one)

4. Pre-assemble a draft from a group of particular sub-agreements

5. Deliver the final result in a number of different formats (PDF, Word, HTML...)

 

For a start, I have provided an example (unfortunately still in Spanish, although generating a contract in English if required) here:

http://www.smaldonado.com/marcos/services/cw_es1.cfm

In any case, the example is based on a wizard (a series of forms) that gathers from the parties:

a) the parties' details

b) the parties' choice of legal system (which will determine the nature of the contract as well as its language)

c) the parties' input for "open" clauses (eg. "price")

d) the parties' choice amongst a set of mutually exclusive options in "semi-open/semi-negotiable" clauses (eg. intellectual property rights in the resulting works) 

Such details are eventually used against a particular document/contract draft that becomes a datasource to the final "customized" draft where parties' data are treated as variables and clauses are automatically numbered. The process can prove extremely painful without the assistance of XML, as it requires a great amount of redundant conditional statements and the manipulation of multiple variables. Additionally, proprietary "translators" and tough programming are required for the final result to be output in multiple formats (in the example provided, RTF and HTML).

XML would effectively do away with all this.

Requirements

XML  should enable the use of particular sub-agreements or complete drafts as datasources, themselves being self-descriptive of:

a) An applicable legal system according to which the resulting legal figure will arise (eg "California Law" or "Law of England and Wales")

b) The legal figure/figures that the parties intend to create (eg "Confidentiality agreement" or "Leasing")

c) The particular clauses (so that each clause can be easily tracked without need for scanning the actual content of the element -eg "Choice of Jurisdiction")

Besides that, XML enables the automatic substitution of the parties' names and details through the use of entities.

Additionally, XSLT allows for multiple different outputs of the same XML document.

As a consequence it is submitted as a suggestion that an eventual eContracts Schema counts with:

- A main element/attribute describing the legal system which inspires the contract (itself miles away from the applicable law or jurisdiction chosen by the parties in the event of a dispute). A combination of ISO country codes and region/state/province codes would also provide a predefined range of limited values that would greatly enhance automation (eg. UKSC for Scotland).

- A main element/s describing the "legal figure"/range of "legal figures" that the contract will create once it becomes binding to the parties. Although a shortlist of them is hardly viable, a naming convention could be agreed so that parsers can be easily built for a smaller range of familiar figures in each particular discipline (eg: SG for sale of goods)

- An identifiable Clause element nested within the particular legal figure it belongs to (so that, for instance, in a Software Development contract certain clauses can be associated to the Confidentiality sub-agreement and certain others to the IP licensing sub-agreement)

- Various entities representing, mainly, the parties.