4 ms·

Probably need something very close to strong AI.

dctoedt 15y ago
1. The problem is that contract language, like Perl, is very much TMTOWTDI or "Tim Toady": There's More Than One Way To Do It. 2. Exacerbating the problem, a lawyer drafting a contract (like most programmers I've known) often can't resist the urge to "improve" specific provisions, sometimes for style but more often to try to subtly micro-optimize his client's future position, to the disadvantage of the other side. 3. All this means that the other side's contract reviewer has to read the entire contract every time, looking for "improvements" by the drafter that might not be in the best interests of the reviewer's client. 4. Strong AI wouldn't be needed if clients would push for Perl's TMTOWTDIBSCINABTE or "Tim Toady Bicarbonate" attitude about contract language: There Is More Than One Way To Do It, But Sometimes Consistency Is Not A Bad Thing Either. 5. In an ideal world, there'd be: a) a Creative Commons repository of benchmark language for various flavors of different types of contract provisions, and b) client- and market pressure for lawyers to edit the benchmark language when drafting a contract. That would allow the other side to run a quick diff, e.g., using Compare Documents in Microsoft Word, to see which benchmark provisions were used as-is, which were modified, and which were omitted altogether. 6. Contract reviewers could maintain private copies of the benchmark language repository, annotated with tags such as, for example, "FAVORS EMPLOYER" and/or "HEADS-UP" and/or "ALWAYS ASK FOR THIS." These annotations would show up in the Compare Documents results, for free, canned "legal advice." 7. The foregoing could greatly reduce the cost and delays associated with contract legal review. But lawyers (and many clients) will almost never do so voluntarily, because they hate the idea of giving the other side's contract reviewer any help -- even though doing so might help their clients get to signature more quickly. 8. I've been experimenting with something like the foregoing as a side project; I'll post an announcement if and when I get an MVP.

1. The problem is that contract language, like Perl, is very much TMTOWTDI or "Tim Toady": There's More Than One Way To Do It. 2. Exacerbating the problem, a lawyer drafting a contract (like most programmers I've known) often can't resist the urge to "improve" specific provisions, sometimes for style but more often to try to subtly micro-optimize his client's future position, to the disadvantage of the other side. 3. All this means that the other side's contract reviewer has to read the entire contract every time, looking for "improvements" by the drafter that might not be in the best interests of the reviewer's client. 4. Strong AI wouldn't be needed if clients would push for Perl's TMTOWTDIBSCINABTE or "Tim Toady Bicarbonate" attitude about contract language: There Is More Than One Way To Do It, But Sometimes Consistency Is Not A Bad Thing Either. 5. In an ideal world, there'd be: a) a Creative Commons repository of benchmark language for various flavors of different types of contract provisions, and b) client- and market pressure for lawyers to edit the benchmark language when drafting a contract. That would allow the other side to run a quick diff, e.g., using Compare Documents in Microsoft Word, to see which benchmark provisions were used as-is, which were modified, and which were omitted altogether. 6. Contract reviewers could maintain private copies of the benchmark language repository, annotated with tags such as, for example, "FAVORS EMPLOYER" and/or "HEADS-UP" and/or "ALWAYS ASK FOR THIS." These annotations would show up in the Compare Documents results, for free, canned "legal advice." 7. The foregoing could greatly reduce the cost and delays associated with contract legal review. But lawyers (and many clients) will almost never do so voluntarily, because they hate the idea of giving the other side's contract reviewer any help -- even though doing so might help their clients get to signature more quickly. 8. I've been experimenting with something like the foregoing as a side project; I'll post an announcement if and when I get an MVP.