My contract-drafting class at the University of Pennsylvania Law School focuses on the building blocks of contract language. But we’d be reckless if we didn’t also consider process—more specifically, the implications of the fact that contract drafting is an industrial-scale team sport. To that end, we devoted last week’s class to two online document-assembly demos.
The first was a demo of QShift, the clause-based document-assembly system developed by Ixio Corporation. The presenters were Laura Williams and David Munn, fresh from their presentation on legal technology at the ACC annual meeting. Laura is corporate counsel with Seattle-based Safeco Insurance Company. Previously, she was Ixio’s general counsel and director of professional legal services. (Click here for the Q&A I did with Laura about QShift.) David is an attorney with Fair Isaac Corporation, a Minneapolis-based data-analytics and decision-management company.
David and Laura outlined the basic idea behind document assembly, then demonstrated how QShift works. David wrapped up by showing us how Fair Isaac uses QShift, thereby adding a real-world angle that one doesn’t always get in a technology demo.
Next up was Tim Allen, CEO of Business Integrity, developer of DealBuilder, the logic-based document-assembly software. (I’ve previously mentioned my relationship with DealBuilder.) Tim described DealBuilder’s origins and what it can be used for. He then went on to demonstrate, with dizzying efficiency, exactly how it works.
I’m sure that much of both presentations went over the heads of my students. But I’d rather that than have them be unaware of developments that have the potential to make contract drafting a much more efficient process.
I’ve given a lot of thought to the usefulness of fielding document assembly systems, machine learning, structured documents, and other means of facilitating what transactional lawyers do.
This is exciting stuff for those of us neck deep in contracts practice. It doesn’t take a rocket scientist to see that there are some programmatic principles governing the structure and content of contracts (even for the most complex deals), but it might actually take a rocket scientist to extract these rules in a meaningful way.
For now, the obvious application for document assembly seems to be in procurement groups or law departments that do a high volume in relatively simple agreements. The most difficult part of offering a few different flavors of standard language and cobbling these together on demand is drafting the candidate provisions in the first place. A leasing company, for instance, could make excellent use of this kind of tool.
But many of the most interesting applications of technology to contracts practice are not ready for the field (or the field is not ready, in many cases). For example, where document assembly tools build structured or self-describing documents (e.g., XML), much of the value of having metadata is lost when changes are made outside the system that generated the document.
The real revolution will be when contextual metadata can be preserved beyond the first draft. What is most interesting to me is a tool that can answer questions like: “of the 900 deals we’ve done of this type, what are the standard indemnities?” or “what is the average liability limit?” Why? Because I get these questions from clients more than any other, and I would very much like to answer them more definitively.
IBM has a patent and a product for managing its own complex contracts, and I’ve wondered whether that product will ever go further than the current tools. What is also interesting is that Microsoft had some rather sophisticated assembly tools in Word 2003, but seems to have lost interest in them since. And we can’t forget Adobe, although Acrobat’s forms and other transaction support features are there, albeit confusingly implemented.
Meanwhile, the next phase of bringing transactional practice into the current century will be tight collaboration between practitioners and technologists to isolate the tacit rules that govern a lawyer’s decision-making. We are definitely in the early stages of this, since most lawyers are barely caught up with the current version of Microsoft Office.
Sol: I think that document assembly can be of use even for documents that are more complex. It can perhaps get you only halfway to where you need to go, but if that saves you several hours, it would be well worth it.
I agree that now the challenge is to make sure that the language of document-assembly templates is as sophisticated as the document-assembly software. That challenge isn’t susceptible to a technology solution, except to the extent that I’m able to make document-assembly products available to a broader audience. That’s something I’m working on.
Regarding the possibility of preserving contextual metadata beyond the first draft, currently my goals are decidedly more humble!
Ken