In March 2009 I did this Q&A with Kingsley Martin, developer of KIIAC, a software for creating templates and clause libraries for use in drafting contracts. I continue to think that KIIAC is invaluable for anyone looking to create a new template from a large group of comparable precedent contracts, so it was with interest that I noted that Kingsley has just started the “Contract Analysis and Contract Standards Blog.” If you’re interested in achieving efficiencies in the contract process, you might want to keep an eye on it.
Incidentally, based on my conversations with Kingsley, I think we might have slightly different views regarding the amount of editorial input that’s required when using KIIAC to create a template. I say that determining which suboptimal version of a given kind of provision is the most prevalent is, by itself, of strictly limited use.
Ken,
Thanks for the mention in your blog. I'm looking forward to an online debate on the perfect contract versus satisfactory contract: the legal equivalent of Adam Smith's maximizing returns versus Herbert Simon's satisficing returns.
In the meantime, just one point of clarification: in additional to finding common clause terms and all deal specific variations, kiiac identifies the non-negotiated core language. And, while it may not be the "best" in an ideal world, it does represent prevailing standard of practice.
Kingsley: The only reason to opt for "satisficing" is if optimizing would cause you to incur disproportionate costs. That's not the case if, ahem, I'm providing the editorial input: you'd be ensured a close-to-optimal outcome for a cost that would be nominal, assuming suitable economies of scale.
And with all that's at stake in contracts, I can't imagine too many law firms and clients would be willing to openly acknowledge that they're willing to make do with "good enough."
Furthermore, "good enough" might make sense when you're dealing with a continuum, such as how sharp a knife blade is, but I'm not sure that it makes sense when you're dealing with contract language, which I see in binary terms: the language is clear and articulates the intent of the parties, or it isn't and doesn't. There's nothing "good enough" about thinking that “best efforts” represents a more exacting standard than “reasonable efforts,” or using “indemnify and hold harmless.” or articulating as an obligation something that should be expressed as a condition. Instead, those are usages that could bring someone to grief.
And if my writings stand for anything, it's that the prevailing standard of practice bears little relation to that which is clear and concise.
So I see KIIAC (should I be using all lowercase? or a capital K?) as primarily being of use for determining WHAT to say in a contract, not HOW you say it. I prefer to handle the HOW part myself.
Ken
Kingsley: The only reason to opt for "satisficing" is if optimizing would cause you to incur disproportionate costs. That's not the case if, ahem, I'm providing the editorial input: you'd be ensured a close-to-optimal outcome for a cost that would be nominal, assuming suitable economies of scale.
And with all that's at stake in contracts, I can't imagine too many law firms and clients would be willing to openly acknowledge that they're willing to make do with "good enough."
Furthermore, "good enough" might make sense when you're dealing with a continuum, such as how sharp a knife blade is, but I'm not sure that it makes sense when you're dealing with contract language, which I see in binary terms: the language is clear and articulates the intent of the parties, or it isn't and doesn't. There's nothing "good enough" about thinking that “best efforts” represents a more exacting standard than “reasonable efforts,” or using “indemnify and hold harmless.” or articulating as an obligation something that should be expressed as a condition. Instead, those are usages that could bring someone to grief.
And if my writings stand for anything, it's that the prevailing standard of practice bears little relation to that which is clear and concise.
So I see KIIAC (should I be using all lowercase? or a capital K?) as primarily being of use for determining WHAT to say in a contract, not HOW you say it. I prefer to handle the HOW part myself.
Ken
Ken,
Thanks for posting this interview and keeping up with the various automation solutions.
My own experience is that the technology is not far enough along to make document automation worthwhile for most lawyers whose practice involves drafting a broad spectrum of complex documents. KIIAC, however, looks innovative, and seems to be moving in the right direction.
The only product I know of that is capable of satisfying my document automation needs is HotDocs. Its biggest drawback is the steep learning curve; but once you learn it, nothing I've seen comes close to it in terms of sheer power and flexibility.
My other problem with HotDocs is that none of its promises of doing most of the work for me seem to pan out. I actually have this same problem with other document automation programs that I've tried. The only way that I've found to get HotDocs to do what I need it to do is to spend countless hours telling it what to do: putting each paragraph, phrase, and word into the right templates; thinking through options and decision trees; writing and rewriting the code; setting up Word outline and numbering templates; testing and fixing; etc. I think that's just the nature of document automation, until the AI gets a whole lot better.
Paul: Actually, I think document-assembly technology most certainly is as sophisticated and intuitive as it needs to be. I've often written about ContractExpress (formerly DealBuilder), developed by my sponsor Business Integrity. Most recently, in this blog post I wrote about their cloud version of ContractExpress. And I did <a href="https://www.adamsdrafting.com/2007/06/27/exari-q-and-a/this Q&A with their competitor, Exari. Doubtless we'll see improvements, but as things stand both products are more than up to the task of permitting efficient automation of the contract process.
By contrast, HotDocs is twentieth-century technology. For one thing, using HotDocs requires the input of programmers. But someone recently purchased HotDocs from LexisNexis; I suspect we'll be seeing a new version of it before too long.
So the challenge is no longer the technology. Instead, the challenge lies in building the questionnaire, having it reflect appropriate choices, making sure that the pre-loaded language is clear and consistent, and keeping everything up to date. That's a significant task that I suspect is beyond the resources of most organizations. (Particularly law firms, which generally are called on to draft a broad and unpredictable range of documents.) That's why I'd like to see organizations have the option of outsourcing that part of the process to an authoritative vendor.
As for KIIAC, I regard it as a machine tool that, when I'm dealing with a suitable set of precedent contracts, allows me to determine what kinds of terms are being used in deals and with what frequency. But I think Kingsley has broader aspirations; he can chime in!
Ken
Ken,
I'm always looking for things to do other than bill hours. So I've just downloaded the trial version of ContractExpress, and I'm looking forward to playing with it. While I'm heavily invested into HotDocs, a good part of that time represents forms work, which won't be lost if I switch systems. So I'm always open.
As for your comments on HotDocs:
1. You are correct in that it requires the input of programmers (or a lawyer who is willing to learn to program). HotDocs is most certainly a computer language, with a steep learning curve.
2. I don't know what you mean by "20th Century Technology"–maybe I'll get it when I see what ContractExpress can do. I do see that ContractExpress is purely cloud-based, which is something that I have mixed feelings about.
3. Pending my review of ContractExpress, I would say very emphatically that the technology is a big challenge, and will remain a big challenge for the foreseeable future. Show me a document automation system that (1) works smoothly not only with the first draft, but with every draft until the final draft, (2) understands legal phrases and concepts (best analogy I can come up with is the "Web 3.0/Semantic Web" ideas), and (3) understands and can intelligently format outline levels, tables of contents, cross-references, and so forth with no user input. We are nowhere near the point where the technology is no longer an obstacle.
Ken,
In truth our opinions are closer than suggested by our exchange. You are correctly pointing out there is a standard of clarity and suitability for purpose. I agree that any systematic effort to develop forms and/or drafting guidelines should aspire to the very highest standards.
I'm observing—through the lens of contract analysis software—a reality, where, for any given clause, there is a near infinite range of semantically similar language, all intended to achieve the same result. And, in most cases the courts would interpret this wide array of terminology as having the same intent.
Moreover, kiiac can also analyze any subset of precedents, such as those from leading law firms. While there may be isolated issues in these documents, it's hard to imagine such firms drafting suboptimal clauses. Indeed, many lawyers look to these precedents as guides.
Continued below….
Ken,
In truth our opinions are closer than suggested by our exchange. You are correctly pointing out there is a standard of clarity and suitability for purpose. I agree that any systematic effort to develop forms and/or drafting guidelines should aspire to the very highest standards.
I'm observing—through the lens of contract analysis software—a reality, where, for any given clause, there is a near infinite range of semantically similar language, all intended to achieve the same result. And, in most cases the courts would interpret this wide array of terminology as having the same intent.
Moreover, kiiac can analyze any subset of precedents, such as those from leading law firms. While there may be isolated issues in these documents, it's hard to imagine such firms drafting sub-optimal clauses. Indeed, many lawyers look to these precedents as guides.
Continued below….
Ken,
In truth our opinions are closer than suggested by our exchange. You are correctly pointing out there is a standard of clarity and suitability for purpose. I agree that any systematic effort to develop forms and/or drafting guidelines should aspire to the very highest standards.
I'm observing—through the lens of contract analysis software—a reality, where, for any given clause, there is a near infinite range of semantically similar language, all intended to achieve the same result. And, in most cases the courts would interpret this wide array of terminology as having the same intent.
Moreover, kiiac can analyze any subset of precedents, such as those from leading law firms. While there may be isolated issues in these documents, it's hard to imagine such firms drafting sub-optimal clauses. Indeed, many lawyers look to these precedents as guides.
No lawyer aspires to be merely "good enough." I don't believe a lawyer would rush through a drafting assignment and consciously select suboptimal language. They may, however, use prevailing language for reasons of certainty of interpretation. They may look to the body of precedent as a means to gain knowledge of market standards by analyzing customary practice. In the end, we agree it is the lawyer's job to craft the documents to meet a client's specific legal and business requirements.
You are also correct; I do have grand visions for kiiac. One of the missing tools in the market is technology that can review a contract: tell you how well the clauses compare to a selected standard, tell you what clauses are specific to your contract (terms that may have been accidentally brought forward from an earlier draft), and tell you what clauses may be missing. For all the significant utilities provided by document assembly software, it cannot help you if your task is not the first draft, but rather the more common task of reviewing a contract drafted by someone else. This is the vision of kiiac: create a transactional document review tool and, working with others, create the standards against which such contracts can be measured.
Ken,
I downloaded ContractExpress, and I read the manual (the Author Help File) and have tinkered with it this evening. It's an impressive program. But is it fair to compare it to HotDocs by calling HotDocs "20th century technology"? ContractExpress seems to make it easy for an attorney to create basic automated documents, without having to be a computer programmer. So does HotDocs (using "Model Document" markup).
But document assembly is like anything else–you only get out of it what you put into it. Suppose you want to go beyond using document assembly to replace variables and add or omit clauses based on how the user answers questions in an interview. For example, suppose you want to do complicated math based on the input from the user; or suppose your logic gets a bit complicated (if the user answer this question yes, and this no, and picks this item from a multiple choice list, do this–otherwise. . .); or suppose you need to use nested repeats or you need to concatenate variables. Believe me–if you want to fully automate a commercial loan agreement or purchase contract, this is just the tip of the iceberg.
It's a testament to ContractExpress that it seems to handle all of these more complicated matters. But how does it handle them? Well, its simple. You pull up the expression editor, and using the available expressions and functions (read about them in the help file), you program in the programming language that ContractExpress calls CEML (stands for "ContractExpress Markup Language"). As I read through this, it all looked very familiar to me. It looked a whole lot like HotDocs.
Is it a mark against ContractExpress that to go beyond simple automation, you need to learn the ContractExpress programming language (just like HotDocs)? Of course not. With the current levels of technology generally available, both programs are as simple as they can be for attorneys to use. But the very nature of, for example, a complex logic tree with nested repeats requires a certain amount of sophisticated input from the person putting the document together. To quote Einstein, "make everything as simple as possible, but not simpler."
My first impression of the differences between the programs is that ConractExpress is more GUI and prettier. HotDocs certainly could use a facelift. ContractExpress also seems to have a number of higher-level functions/expressions that HotDocs requires more steps to perform. On the other hand, HotDocs appears to give more granular control over the entire document assembly process. In the end, both programs seem to do the same thing and get you to the same place.
Ken,
I downloaded ContractExpress, and I read the manual (the Author Help File) and have tinkered with it this evening. It's an impressive program. But is it fair to compare it to HotDocs by calling HotDocs "20th century technology"? ContractExpress seems to make it easy for an attorney to create basic automated documents, without having to be a computer programmer. So does HotDocs (using "Model Document" markup).
But document assembly is like anything else–you only get out of it what you put into it. Suppose you want to go beyond using document assembly to replace variables and add or omit clauses based on how the user answers questions in an interview. For example, suppose you want to do complicated math based on the input from the user; or suppose your logic gets a bit complicated (if the user answer this question yes, and this no, and picks this item from a multiple choice list, do this–otherwise. . .); or suppose you need to use nested repeats or you need to concatenate variables. Believe me–if you want to fully automate a commercial loan agreement or purchase contract, this is just the tip of the iceberg.
It's a testament to ContractExpress that it seems to handle all of these more complicated matters. But how does it handle them? Well, its simple. You pull up the expression editor, and using the available expressions and functions (read about them in the help file), you program in the programming language that ContractExpress calls CEML (stands for "ContractExpress Markup Language"). As I read through this, it all looked very familiar to me. It looked a whole lot like HotDocs.
Is it a mark against ContractExpress that to go beyond simple automation, you need to learn the ContractExpress programming language (just like HotDocs)? Of course not. With the current levels of technology generally available, both programs are as simple as they can be for attorneys to use. But the very nature of, for example, a complex logic tree with nested repeats requires a certain amount of sophisticated input from the person putting the document together. To quote Einstein, "make everything as simple as possible, but not simpler."
My first impression of the differences between the programs is that ConractExpress is more GUI and prettier. HotDocs certainly could use a facelift. ContractExpress also seems to have a number of higher-level functions/expressions that HotDocs requires more steps to perform. On the other hand, HotDocs appears to give more granular control over the entire document assembly process. In the end, both programs seem to do the same thing and get you to the same place.
Ken,
I downloaded ContractExpress, and I read the manual (the Author Help File) and have tinkered with it this evening. It's an impressive program. But is it fair to compare it to HotDocs by calling HotDocs "20th century technology"? ContractExpress seems to make it easy for an attorney to create basic automated documents, without having to be a computer programmer. So does HotDocs (using "Model Document" markup).
But document assembly is like anything else–you only get out of it what you put into it. Suppose you want to go beyond using document assembly to replace variables and add or omit clauses based on how the user answers questions in an interview. For example, suppose you want to do complicated math based on the input from the user; or suppose your logic gets a bit complicated (if the user answer this question yes, and this no, and picks this item from a multiple choice list, do this–otherwise. . .); or suppose you need to use nested repeats or you need to concatenate variables. Believe me–if you want to fully automate a commercial loan agreement or purchase contract, this is just the tip of the iceberg.
It's a testament to ContractExpress that it seems to handle all of these more complicated matters. But how does it handle them? Well, its simple. You pull up the expression editor, and using the available expressions and functions (read about them in the help file), you program in the programming language that ContractExpress calls CEML (stands for "ContractExpress Markup Language"). As I read through this, it all looked very familiar to me. It looked a whole lot like HotDocs.
Is it a mark against ContractExpress that to go beyond simple automation, you need to learn the ContractExpress programming language (just like HotDocs)? Of course not. With the current levels of technology generally available, both programs are as simple as they can be for attorneys to use. But the very nature of, for example, a complex logic tree with nested repeats requires a certain amount of sophisticated input from the person putting the document together. To quote Einstein, "make everything as simple as possible, but not simpler."
My first impression of the differences between the programs is that ConractExpress is more GUI and prettier. HotDocs certainly could use a facelift. ContractExpress also seems to have a number of higher-level functions/expressions that HotDocs requires more steps to perform. On the other hand, HotDocs appears to give more granular control over the entire document assembly process. In the end, both programs seem to do the same thing and get you to the same place.
Paul: Thanks for your comment. You have more hands-on experience than I, and I may have been too quick to dismiss HotDocs. I'll let others who are more knowledgeable than I wade in. Ken
Paul: This is Andy Wishart here, CTO at Business Integrity. Many thanks for signing up to ContractExpress.com to try it out before posting your feedback. You clearly have substantial experience in document assembly to know the issues and to adapt so quickly to a new platform like ours.
I agree with you that document assembly remains a great garbage-in / garbage-out tool and there is not yet a magic AI wand for reducing the complex tacit knowledge which specialists know about contracts into a simple form like the ContractExpress CEML notation or HotDocs MDML notation*. Kiiac is a great step in that direction though. Combining it's intelligent analysis of a reference set with a best of breed document assembly solution could really provide gains in building out document assembly templates.
I hope you get a chance to push ContractExpress.com further to understand why more and more law firms are choosing our solution for document assembly. We believe that our simple yet powerful authoring environment enables you to build templates quickly and with confidence. You should check out the info behind the traffic lights in ContractExpress Author – it understands all the relationships between the variables and can warn you when you are asking a question on the questionnaire before a question which controls it. But it is also beyond authoring where I believe we differentiate. From the same author tool, you can build templates which can be deployed through our on-premises document assembly solution, through our integration with Microsoft SharePoint or through our ContractExpress.com cloud solution. The later is proving very popular for firms who want to provide document assembly templates to their clients. Wilson Sonsini's Term Sheet Generator is a great example of using our technology for this purpose.
Ping an email to support@contractexpress.com if you have any more questions about our solution.
* just for the record, we have been producing document assembly solutions based on our CEML notation for the past 10 years, long before HotDocs introduced MDML.
Andy,
Thanks for your reply. On CEML v MDML, my point (which I didn't make very clearly) was that both languages contain similar concepts/categories like expressions, functions, and conditional statements. It seems that this is just part of document assembly, the same way that different makes of cars still have engines and steering wheels. But from my brief review, CEML has some functions that I'd like to see in HotDocs.
I doubt that there are enough vested document assembly users to make it worth your while, but it sure would be nice to see a conversion utility to convert templates from other document assembly products to ContractExpress/Deal Builder! I can imagine that this would be incredibly difficult to do, but I thought I'd ask.