Written by Daria Turanska
The hard part of automating a contract is not the law. It is the branching.
I have drafted contracts for fifteen years, and when I started building automated document templates at FasterDraft (https://fasterdraft.com), I assumed the legal knowledge would be the constraint. It was not. Writing a correct indemnity clause is a solved problem for anyone with the training. Working out which combination of twenty user answers should produce that clause, and which four combinations should produce a different one, is a different discipline, and it is the one that decides whether the finished document is any good.
Our templates run on a conditional logic system: questions the user answers, and bracketed tags in the document body that switch passages on and off based on those answers. Once a template has enough questions, the number of documents it can generate stops being something you can hold in your head. That is where the real failure mode lives, and it is not the one people expect.
Clauses that are right alone and wrong together
Every clause in a badly behaving template can be individually correct. The document is still wrong, because two conditions both fired and produced passages that contradict each other, or because no condition fired and the document simply has a hole where an obligation should be.
A residential lease is a good example of how quickly this compounds. Whether there is more than one tenant, whether the tenancy is joint or several, whether pets are permitted, whether a deposit is held in a scheme, whether the property is furnished. Each of those is a sensible question. Together they define a combination space that no one is going to review by hand, and the defect will always be in a combination nobody thought to open.
What I would tell anyone starting this: draft the question tree before you draft a single clause. If the tree is wrong, you will discover it later as a clause problem, and you will fix it in the wrong place.
Test combinations, not clauses
Legal review instinctively works clause by clause, because that is how contracts are read and how they are negotiated. Template review cannot work that way. The unit under test is the generated document, and you need to generate the awkward ones deliberately: the maximum-answer path, the minimum-answer path, and the combinations that a reasonable person would call unlikely, because those are exactly the ones that were never opened during drafting.
The bugs that survive are almost never in the paragraph everyone stared at.
Proofread the boilerplate hardest
The third thing I learned the least gracefully. A disclaimer sat in the footer of our site, across the whole catalogue, reading “does not advice” instead of “does not advise” for longer than I would like to admit. It was in the part of the page that exists precisely so that nobody reads it, including the person who wrote it.
A sequencing problem in the purchase flow lasted a similar length of time: the process asked for an e-signature before it asked for payment. Nothing about that is a drafting error. Every individual step was correct, in an order that made no sense, and no amount of reviewing the legal text would have surfaced it.
Both were found by walking the whole path as a user rather than inspecting the pieces as an author.
If there is a single transferable idea here, it is that document automation moves the expertise one level up. You stop being responsible for the sentence and become responsible for the system that decides which sentences appear. Those are genuinely different jobs, and the legal training that makes you good at the first one gives you almost no warning about the second.
The clause you never wrote will not be caught by reading the clauses you did.
Author Bio:
Daria Turanska is a contract lawyer with fifteen years of drafting experience across the US, UK and Australian markets, and holds an LLM from the College of Europe. She is Legal Manager at FasterDraft (https://fasterdraft.com), a legal document template platform she runs solo, and previously worked at PwC and French Start Up.