Draft 3.6: the deal-point form, and why boilerplate should write itself

How many decisions does a lawyer actually make when drafting a services agreement from the firm’s template?

We counted, across a sample of first drafts produced on our accounts in the first quarter of this year. The median was 23. Parties, term, fees and payment terms, the cap, the carve-outs, the notice period, governing law, a handful of commercial specifics. Everything else in a 35-page document was either determined by those 23 answers or was unchanged from the template.

Draft 3.6 is built around that count. It is available from today.

What changed

• The deal-point form. Starting a new document from a template now opens a form rather than a blank draft. The form asks only the questions whose answers vary between deals of that type, as identified from the firm’s own closed deals and the playbook. For a standard MSA, that is around twenty questions; for an NDA, under ten.
• Everything else is composed, not asked. Boilerplate, definitions, mechanics, and any clause whose content follows from the deal points are written by Draft using the playbook position and the voice profile from 3.4. The lawyer does not see a question about the counterparts clause because there is nothing to decide.
• Dependent questions. Answering that the counterparty is a regulated financial institution reveals the questions that matter only in that case. Answering that there is no personal data in scope hides the DPA questions.
• Each answer is traceable in the draft. Every clause in the resulting document shows which deal-point answers and which playbook entries it was composed from. Change an answer and the affected clauses are re-composed and marked.
• Form templates per document type, editable by administrators. Questions can be added, removed, reordered and given help text.

Why boilerplate should write itself

A boilerplate clause is one whose content is not negotiated in this deal. That is the definition. If it is not negotiated, there is no decision for a lawyer to make about it, and asking a lawyer to make one is asking them to re-decide what the firm decided when it wrote the playbook.

The counter-argument is that boilerplate is where errors hide, and a lawyer who does not look at it will miss them. We agree about the errors. We disagree about the remedy. The errors in boilerplate are overwhelmingly errors of consistency: a definition used before it is defined, a cross-reference to a clause that was renumbered, a survival list that points at the wrong number, a notice clause that names the wrong address. Those are not caught by a lawyer reading the template for the hundredth time. They are caught by a system that composes the boilerplate from the deal points and checks the result. Draft 3.6 does both, and Review catches what Draft misses.

The lawyer’s attention belongs on the 23 decisions.

If a question on the form has had the same answer in the last fifty deals, it should not be on the form.

What it assumes

The deal-point form makes assumptions, and they should be understood.

It assumes the playbook is current. Clauses composed without a question are composed from the playbook position. If the position is stale, the clause is stale. The 3.6 administrator console shows which playbook entries the form for each document type depends on, with their last-reviewed dates.

It assumes the firm’s closed deals reflect what varies. The initial question set for each document type was derived by looking at what actually changed between the firm’s own closed deals of that type. A firm whose last fifty MSAs all happened to be with UK counterparties will not be asked about governing law by default. The question can be added, and the form flags when a default is being applied silently to something that has varied in fewer than three of the sample deals.

It assumes the template is the starting point. The form composes from the firm’s template and playbook, not from the counterparty’s paper. For deals on the other side’s template, Review is the right tool, not Draft.

What to check

1. Open the form for your most common document type and read the questions. If something that matters to your practice is missing, add it. If something is there that never varies, remove it. Ten minutes with a practice head is enough.
2. Draft one document and read the trace on three boilerplate clauses. Confirm they resolve to the playbook entries you expect.
3. Change one answer after drafting and watch what is re-composed. The dependency tracking is the part most likely to surprise, in either direction.
4. Review the “silently defaulted” list shown at the end of the form. These are the decisions Draft made for you because the sample suggested they do not vary. Make sure you agree.

Known limitations

• Forms are per document type and do not yet share answers across types. Drafting an MSA and then a related DPA asks for the parties twice. We are testing a matter-level answer store.
• Numeric and date answers are validated for format, not for sense. A cap of twelve months’ fees on a one-month engagement will be drafted faithfully.
• Dependent-question logic is authored by us for the standard document types and by administrators for custom ones. The authoring interface is adequate and not more than that.
• Documents started in 3.4 or earlier do not retain deal-point traceability if opened in 3.6. Only documents created through the form carry the trace.
• The form is available in English, German, French, Spanish and Mandarin interfaces. Other interface languages show the English form; the composed document is still produced in the target language.

Twenty-three decisions. The rest should take care of itself, and now mostly does.