Templating for Lawyers

Do it with Ethereum. Have the U.S. government create the smart contracts. What's stopping this now?

You might be interested in Merigoux et al 2021, "A Modern Compiler for the French Tax Code" [1]!

[1]: https://arxiv.org/pdf/2011.07966.pdf

I watched a project where the starting idea was to make and IDE for lawyers, applying the many learnings from modern IDEs including autocompletion, structure the document like code, etc. The main challenge was to get lawyers to adopt and move away from MS word. It ended up applying that approach to tools and document management for lawyers: https://tryprose.com/home

Breach of contract claims, beyond the most simple scenarios, often involve difficult normative questions. It's unlikely a simple dispute capable of being resolved by a computer would wind up going to trial. It would be settled or be the subject of summary judgment.

Sure, you might have word state -> boolean in a simple scenario. But what if the party alleges the contract, or a term, is void or unenforceable because of the existence of a vitiating factor? What if there are two competing interpretations of a term which depend upon considerations such as the purpose of the agreement?

It would be a very difficult task asking someone to agree to a contract which requires no value judgements. Even more so in the Nordic countries where such agreements are governed through a lens of 'good faith'.

We then wind up making value judgements, weighing the benefits of holding parties to a bargain capable of being determined objectively, on the one hand, and the elusive and complex notion of 'fairness' on the other.

We are then well and truly outside the boundaries of the capabilities of contemporary thinking machines.

Taxation is an area of back end law where lawyers should be worried about automation.

Some of us are graduated in Laws and have Master/PhD in computational forensics, language interpretation

Simply getting the context of some words make a whole difference. And that just to extract the verdict.

Language and humans can do many things that, sometimes, go long away from logic...

Yep - My thoughts exactly when I seen the verbiage in my court docs

Yes, they even define terms in their contracts' preambles.

But be very careful about capitalization (it's "Employee" if you refer to the aforementioned employee, not "employee"), a wrong lowercase initial letter, and you may lose a lot.

I tend to start my contacts like "Vendor and Customer agree: ..." and then add "Vendor" and "Customer" tags to the signature pages at the back.

There's really no reason to be repeating nicknames, legal entity names, jurisdictions of incorporation, addresses, and the like all over a contract.

I’m not a coder but a designer, but I also have some experience in this space. This is also one of those areas where the HN crowd will think, “I’m so much smarter they should just do X isn’t it obvious?” What happens is that clauses are often litigated over and over and the successful evolution of the clauses that survive court battles and arbitration are then used wholesale in future contracts because the law is so settled. So it’s hard to change clauses, even to replace some small things with seemingly equal things (names vs variables in this case) because that opens up cans of worms because the clause is no longer identical to the litigated one. So the efficiency gained by only needing to write your name once is lost in the danger of additional litigation.

One analogy would be to not roll your own crypto. You may think you got it right, but better to just go with the battle tested solution.

This is also one of the many reasons people incorporate in Delaware primarily. The law is settled and doesn’t change, people can rely on it, so they use the clauses that were litigated and have settled meanings for decades.

Sometimes having you do something manually is part of the point. Areas of legal risk or when you're acting against your own interests are areas where the attorney might want to draw extra attention. Think of it as an "Are you sure?" dialog.

An example: when I was doing basic legal assistance, we had a lot of folks who wanted a power of attorney. Many of them insisted on getting a general power of attorney. There are significant risks that such an instrument may be too powerful, and also that it may not be powerful enough. Eventually, we had a disclaimer on the back of the request form that they had to rewrite, by hand, before we would draft the instrument for execution.

By any chance, have any of your friends shared any notable shortfalls of - or annoyances with - Docassemble?

I can’t figure out how to reply at the top level, but if this sort of thing interest you, take a look at Docassemble

I can speak to this a bit. My mom is a lawyer and we've talked before about the need for better templating systems. The problem is that the market for solo practitioners and small firms is just not that large or lucrative, and AIUI the market for large law firms is already pretty mature, or at least there's a high barrier to entry.

But there's definitely a need among solo practitioners and small firms, and that need goes beyond templating to include better ways of organizing documents, automating workflows, ensuring security, and so forth. There are companies like Practice Panther which are trying to do this, but the problem I've seen with them is they encourage vendor lock-in and make it hard to do anything not officially supported by the platform.

Someone can come out with it and then someone will wrap a dashboard around it and advertise it as "look - you don't even have to write code!"

The biggest enemy of programming languages as general purpose tools for business is the idea that code == hard, and coder == expensive specialized labor.

If we reach a point where programming is taught as a basic skill like arithmetic or writing then maybe we can apply standard PL tools to basic business tasks.

I've written code a lot longer than I've written legal text. But the longer I've written both, the less "proximate" they've seemed. Drawing parallels pleases the mind, but it's more trouble than helpful, most of the time.

If you want to make legal texts even worse to read and write, throw in a heavy dose of CS-esque structuralism.

I'm a lawyer, and a former (and still occasional) programmer. In my experience, tools developed for (or at any rate, targeted at) lawyers seem to always be bloated, slow, and of negligible utility as far as I can tell. For "legal development" purposes (i.e., writing a letter, contract, memo, brief, etc.), nothing I've experienced surpasses plain old Word Perfect (still in use in some offices I deal with). Word's automated numbering system can burn in eternal damnation.

What might be useful would be better change tracking and management. The problem here is Word's dominance as a means of exchanging drafts. When working on an agreement, I and opposing counsel usually exchange Word drafts along with PDF redlines, which works well enough. Some attorneys like to use the "Track Changes" feature of word, but after a few turns you end up with a complete mess. Still, the sophistication and power of a git or mercurial would probably be wasted in the sort of contexts in which lawyers typically work (a series of form-based documents which are individually tailored in essentially one-off transactions).

I'll ignore your quip about productivity, except to note that you might feel differently if you were the one paying the fees.

I'm a coder and I still struggle to "see through layers". Imagine seeing the following in Ansible:

    shell: >
      cat {{ item }} | grep ansible
      echo $USER
    with_items:
      - hello.txt
      - hello2.txt
      - hello3.txt

You essentially look at 4 layers (YAML, Ansible, Jinja, Shell) and need to "run them in your brain" in the correct order.

My first paragraph mentions Markdown. My first link leads to https://type.commonform.org/.

Markdown first. Then Mustache on top of Markdown.