Benchmark Contracts . . . Of Course!

Dear Fellow eContracts TC Members:

I think we can all be pleased with the level of progress made so far and that which we are poised to make. As our velocity toward solutions has picked up, I have come to appreciate the need for even more simple methods of communicating and demonstrating our work to facilitate collaboration, visual progress metrics and mutual understanding. In that spirit, I informally propose the following for consideration. Unless people hate the idea and say so on the list, then I will propose that we formally consider it as a work method at our next meeting.

I propose that each member of this TC submit one “key benchmark contract” and as many additional example contracts as they wish. The purpose would be to have a consistent and “real world” canvas to visually articulate our ideas upon. The TC would use the key benchmark contracts when explaining proposed ideas. This would assure that whatever ideas we are entertaining work for at least the contractual domains of practice represented by members of our TC. Which this may or may not be a statistically significant cross section, I believe that it at least demonstrates workability in important economic sectors and across knowledge domains. It also assures that whatever we are talking about works, at a minimum, for those of us who are donating the “sweat equity” into the standards making process. Finally, it gives us an “apples to apples” method of debating any given proposal and the relative merits and draw backs between competing proposals.

I propose that we first use this as a way to demonstrate the decision (or competing options) prior to a vote on the clause issue (aka, the main contract content question). If there are two or more proposed approaches, then as part of the discussion leading to a vote, TC members should be able to see exactly how each would be applied to the benchmark contracts to inform their decisions and explicitly debate the relative merits and problems of each approach. If there is only one proposal, then I still think even that should be put through the test of being applied to the benchmark contracts so as to determine that it “really works in practice” without obvious difficulty – at least in the sample contractual domains represented by our varied participants. If it is desired to decide “front matter” and “back matter” (e.g. contractual recitals before the clauses, etc) as a second stage, then those proposals would be demonstrated alone upon each benchmark contract AND in addition to the other structural markup already by then decided.

After we have concluded the question of structure (which is itself always revisitable until our final specification vote, depending on what other monsters we uncover as we go), then I propose that we express the “legal” markup (aka “semantic” markup) applied to the benchmark contracts, as it is conceived and developed and debated and ultimately voted upon. This should be done directly on the content of the contracts, and also (prior to any final decisions) applied cumulatively in addition to the structural markup and any other markup we have decided.

Of course, every mention of an idea need not be rigorously applied to all or even one benchmark contract. That would be too onerous and would chill innovation, I believe. However, to fully understand a new idea or proposal once it has been seriously put forward for consideration, it will be helpful to apply it to our exemplars. Similarly, at key decision points (e.g. when contemplating the relative merits/problems of amendments to a proposal, when voting on final or competing proposals, etc) I think we should go through this process.

Finally, I believe that this process will serve as a critical source of knowledge management for our group in three senses. First, as mentioned, it will provide a clear, consistent and familiar method of communicating and evolving and reaching consensus upon ideas throughout our process – this is efficient. Second, it will give us a way to visually articulate what we have done and what still remains to be done (we can “see” that “the structure is done, but semantics remain”, or that “the semantics of sequence and revenue recognition are done, but dispute resolution and risk allocation remain”, etc). Being able to visually situate us within our worksphere should reduce the confusion and risk of tangents. Third, it will serve as an excellent repository of the discussions we had, the decision points we reached, the various options we considered (and may wish to conveniently revisit later) and the ideas we generated. This is the essence of the digital archive and the foundation of a knowledge system. Those implementing the standard later, as well as those doing future evolution of the standard, will all benefit tremendously from a clear, longitudinally consistent expression of our work. It makes the impenetrable morass of plain text e-mails and echo-only conference calls (i.e.: the “minutes”) renderable in knowledge that downstream thinkers (including ourselves) can actually access and use.

Finally, I note that Rolly and others (Jim, etc) have already instinctively done this by submitting contracts as exemplars. This is great. To make the most of it, I think it is best for each TC member to pick his or her “key” contract and consistently use that through the process. Additional benchmarking contracts can and will be useful (e.g. to demonstrate an especially complex structural challenge that does not commonly appear in contracts but which we may wish to address via the final specification). But to assure longitudinal consistency for decision making and stationary goal posts, I believe it necessary to assure at least one span of “key” metric contracts – hence the word “benchmark”.

Thanks for consideration of this idea. In the future, when I have thought ideas out better, I’ll be able to communicate them is far fewer words ;-)

Best,

- Daniel Greenwood, eContracts TC Chair, OASIS/LegalXML

==============================================
| Daniel J. Greenwood, Esq.
| Director, E-Commerce Architecture Program
| Massachusetts Institute of Technologu

legalxml-econtracts message