Clause authoring relates to where the clause content is not maintained in the Smart Template, but rather in a Clause Library. As such, a large part of the Template is a shell with a number of ‘Clause Lookups’ to pull in the relevant clauses/content into the relevant sections.
As each lookup is technically a variable, using the MS Word Add in, it makes it possible to determine whether the clause had been changed during negotiations.
There’s two approaches to authoring a template using a Clause Library:
- Specific contract type (where some content is managed in the template and supplemented with content from the clause library)
- A “blank”/genetic template where the user is presented with a list of clauses they want to include - allowing them to “build up” their own contract
The second option is typically a workaround / tactical solution to put in place whilst further contract templates are automated. In this use case, you’ll want to author it such that all clauses for a particular section are presented and the user can multi-select which clauses to use. It is therefore important to ensure the clause names are descriptive enough to avoid needing to preview each clause to see it’s content. This option is also not really suited for non-legal users, as it relies on the user’s knowledge of what should / should not go into the template.
For the first option, you want to design your clause lookups to automatically pick up new (and relevant) clauses without needing to update the template. As such, rely on query statements such as ‘Select all clauses where it meets x criteria’.
In addition, whenever you present a selection of clauses for a user, use the control that allows them to re-order the clauses. (When it is returned from the library, it might not be in the order the user wants/expects). Although you can include some ordering in your query, anything beyond an alphabetical order on a given parameter will be difficult. You can make some allowance for this in the naming convention, but don’t try and solve it all. In some cases the user will just have to set the order themselves.
One of the key considerations is around how granular to make a clause. Example: Section 12 may have 6 clauses (12.1 -> 12.6). Each such clause could also consist of multiple paragraphs. Do you take all of section 12 as a single clause? Do you break each sub-section into a clause? Or even take it down to the paragraph level? The answer depends on 2 factors: a) Where are the moving parts / what's different between clause variants. And b) how granular are the clauses in other sections.
There’s no ‘right’ answer as it depends on what fits the requirements best. For consistency sake you will want to structure clauses at the same level, however use common sense when contemplating the granularity of clauses. (Example: If 80% of the clauses are at section level, just treat the other 20% more granular - making it clear in the naming convention that it’s more granular.)
Another factor to consider is that when all/a lot of content is coming from the Clause Library, it’s more challenging to control things like page breaks / table breaks in a predictable way. This is due to the number and size of clauses being variable. For “regular” contracts this is not a problem, but if the system is being used to generate pretty prospectuses or marketing materials with lots of pictures and tables, then set expectation that there will very likely need to be a step post generation to “make the document pretty”.
Things to avoid
When marking up the document for authoring, do not rely on ‘inlines’ to change content. Rather repeat the whole paragraph / clause, so it can be captured as a clause variation. This is especially relevant when you have multiple variations of a contract being produced from the same template. Although you might repeat a lot of content, you are keeping the complexity low and much more maintainable.
Similarly, avoid having clauses whose content is dependent on other clauses. Example: Clause AA consists of a static paragraph and a second conditional paragraph, where the condition depends on whether another clause is present or not. Rather create 2 versions of the clause and pull in the second version using the same condition that pulls in the other clause.