The Ultimate Guide to Clause Libraries
A step-by-step guide
Download as PDF file.
In the previous chapter you have learned what clause libraries are, and how legal experts can benefit from building one. If you’re still with us – terrific! That means you are ready to start taking your first steps into a new way of legal drafting.
But knowing that you need a clause library is not the end game. The next step is to start building one. What are the questions you should ask yourself before you start? What do you put in your clause library? And how do you structure it?
Specialisation in legal teams has been the norm for the past few decades. Few legal experts nowadays can claim to do it all (how many legal experts do you know that juggle labour disputes and securitisation transactions)?
This means that the average legal team will have quite a diverse collection of clauses. In order to make the relevant content available to the right legal experts, it will be necessary to create silos. Think about how your organisation is structured – which departments, which legal matters? Those will likely be a good starting point to set up your base silo structure, but some cross-departmental groups may also be necessary (e.g.: providing legal services to the aviation industry often sits at the intersection of corporate law, employment law and financial law).
Geographical location can be another factor to play a role in creating these silos (or even sub-silos). The IT law team of an international law firm may wish to provide certain clauses to both its Brussels and Paris offices, but cordon off some more jurisdiction-related clauses in sub-silos.
Deciding which and how many silos you need is the first step of setting up your library. From there, you can further set up your folder structure.
The first way to structure your clause library is by starting from the legal domain to which the clause relates. From there you can further divide your folders depending on the type of agreement and on the subject matter of the clause. In the example below, we have illustrated what this structure can look like.
Another starting point can be the type of document in which a clause would typically be used. In this case, you will have a general subject matter at the first level and then further divide your clauses depending on the document you would likely find them in. This approach is especially useful if you are focusing on a highly specialised area of law.
As we have mentioned above, the way in which you structure your library is your choice. There is no perfect approach – both options have their advantages and disadvantages. If there is a rule to structuring a clause library it is this: “be consistent”.
Whichever route you choose to take, know that you will likely need to refer to other parts of the library from time to time.
Say you practice corporate law and chose to implement option 2 above:
For all of three documents, you might consider creating a separate folder for Confidentiality clauses. You could create an agreement-specific folder “Confidentiality” for each individual agreement, but you will likely be able to reuse a lot of material between the three. Instead, consider creating references (also sometimes called “shortcuts” or “proxies”) from one location to another. That might look something like this:
Many organisation have written thousand of clauses in the past. How do you create a clause library out of them without spending hundreds of hours on it? It’s a common misconception by legal teams that their clause libraries should contain all of the clauses the organisation has ever created in the past, contained in documents widely dispersed over email inboxes, document management systems, shared drives, etc.
There are several issues with this assumption. We’ve collected the most important ones below.
Suppose your organisation has drafted 500 share purchase agreements in the past. Would you want the clauses from all 500 documents in your library? Here are just a few issues to take into account:
Or take the example of a confidentiality clause. A quick search through your firm’s documents will likely yield hundreds, if not thousands of different results. A quick search online will likely yield thousands, if not tens of thousands of results.
Now think about the different ways you can actually write a confidentiality clause. Most likely, it will take a position on one of the following legal nuances:
In total, there will probably be around 5 to 10 different legal nuances per clause type. Those legal nuances then tend to be combined into typical clusters, e.g. a short unilateral aggressive clause with explicit penalties versus a balanced mutual clause with no penalties. The amount of clusters (combinations) will differ somewhat, but is typically quite manageable — e.g., about 50 in practice, of which you will probably only use of a subset.
Conversely, when you would create an inventory of all the confidentiality clauses in all the contracts your organisation has made in the past, you will probably end up with hundreds if not thousands of examples. The underlying reason is that there are thousands of cosmetically different ways to write a clause, even though legally speaking many of those would boil down to the same clause (i.e., the same combination of legal nuances).
Forcing yourself to search through all those cosmetically different clauses every time you want to insert a confidentiality clause will lead to frustration and manual rewrites.
The trick is to find those versions and only upload those legally different clauses. This requires an element of human creativity and expertise that AI is currently not capable of replicating.
Law is constantly evolving. New jurisprudence, new legislation, new interpretations, etc. What is common practice today might be ridiculed tomorrow.
Like Lucille, you will likely not be interested in using clauses that were written before the last 10 years. Why, then, would you want to capture those clauses?
You already have access to all these clauses through other tools
If your organisation has been around for at least a few years, you will likely have access to a case management system, filing system or a document management system that contains a treasure trove of information. Any such tool worth its salt will already have search functionalities that allow you to search for text on the basis of keywords. In other words, an easy way of finding text already exists.
Of course, clauses found through such generic systems are not structured in any way, with many disadvantages as a result:
Do not underestimate the "missing context" problem. It's not so difficult for legal experts to assess what is explicitly written in a clause — most legal experts can probably quickly decide whether an explicitly written element is appropriate or not.
Much more difficult is to think about what is not written in a clause. For every clause you extract from an old file, you must be aware that there could have been reasons for omitting legal elements.
Take, for example, a penalty in a confidentiality clause. When a penalty is present in the clause and you don't think it is appropriate for the contract you are drafting, you can decide to either remove the penalty, or take another clause without a penalty.
Compare this to the situation where you extract a random clause from a random old contract, and the penalty happens to be missing there, e.g. because one of the parties deliberately removed it as part of the negotiation. Are you sure that you will think about re-inserting it when necessary? Are you confident that your junior colleagues will do so?
Most legal experts will probably admit that they will think about the 3 or 4 most primary elements of a clause when they are in clause-hunting mode. But whether they will also think about the secondary elements, is much less certain.
When building a clause library, you are probably interested in doing more with your clauses than just storing bits of static text. Any element added to a clause effectively augments the clause, i.e. increases its usefulness.
There are many different types of augmentation.
A first augmentation is to provide some background about the origin of the clause, e.g. the specific client or transaction from which it was extracted. Particularly when your clause library allows you to search on this information, this can be very useful to include. In practice, however, the origin is mostly useful for personal libraries, as opposed to libraries that are used in a team. After all, knowing that a clause was created for “Project Alpha” or “Client Smith” may be useful information for the person who was involved in those situations, but may be useless (or even confusing) for the junior lawyer using the library afterwards.
More useful is to include information on how or when to (not) use the clause, i.e. to provide some guidance to the library user. Depending on your library software, you can either draft such information as free text, or use a standardised format.
Third, you can also include legal references, such as case law, legal doctrine or references to statutory provisions associated with the clause in question. You may even want to include hyperlinks towards external websites or internal intranet sites.
It doesn’t take a village to build clause libraries. You can perfectly create a clause library on your own, for your own. But even if you work in a team, you will find that there are really only two types of hats that can be worn.
Like a curator in a museum, the Curator has two main responsibilities:
The User’s primary role – as the name might imply – is to use the clauses contained in the library to draft legal documents. In that capacity, they also act as useful sources of information for the Curator, as they can flag potentially interesting additions to the library, which the Curator can then decide should be included or not.
Anyone can be designated as the organisation’s Curator (multiple Curators may even be operating at any given time). The best Curators are typically:
Identifying who acts as a User in your organisation is a little more straightforward – it’s anyone who is not a Curator.
We’ve talked about the important of quality vs quantity and how it’s much better to have 10 standardised, legally nuanced clauses of a given kind than a deluge of 10.000 unstructured clauses.
Extrapolating on that, it’s important to realise that building a clause library can be a gradual, organic effort and doesn’t need to be Herculean feat of uploading hundreds of thousands of clauses in one sitting. Getting your blueprint in place is crucial. After that, you can just add clauses to the library as you come across them and gradually watch it grow.
