Organising concepts

Users who have gained some experience with ClauseBase, often ask how to properly organise concepts within ClauseBase. While there is no one-size-fits-all answer on how to organise your concepts — what did you expect in a legal product? — this page tries to provide some general guidance on this topic.

Feeling uneasy is normal

First, a word of comfort. It is perfectly normal to feel somewhat overwhelmed by the question on how to organise your concepts. This issue just does not exist in the traditional MS Word workflow, where you happily copy/pasted text and did not have to think about central reuse.

Feeling somewhat overwhelmed by the concepts is actually a good thing, because it means that you are clearly walking in the right direction of reusing clauses.

Reminder: concepts have a dual nature

As stated under Creating Concepts, concepts have a dual nature, as they can be simultaneously used to:

1. Hosting concept labels — mimic legal terms that would customarily be drafted with a capital (e.g.: “the Purchaser”);
2. Hosting datafields — provide a storage location for datafields (e.g.: the Purchaser’s name, address, company number, etc.)

When reading the discussion below, you should be mindful of this dual-nature of concepts.

Dealing with multiple legal domains

One of the circumstances where the question of concept organisation easily surfaces, is when a law firm or legal team spans multiple legal domains, e.g. employment law, corporate law, IT law and IP law. In all of these legal domains, chances are fairly high that the same concept labels are being used for legal concepts that seem identical at first sight.

For example, in all those domains, documents will probably have a defined term “Contract” or “Agreement”, for which you want to use #contract as the concept, with legal terms such as “Contract” or “Agreement” as the concept labels. So far so good, because those concept labels are probably identical across those legal domains, so there are few concerns. In other words, with respect to the first nature of concepts (hosting conceptlabels), few issues arise.

This starts to break down, however, with respect to the hosting of datafields, i.e. the second nature of concepts. Across those legal domains, there will certainly be a few characteristics of contracts that will be shared across, e.g. the commencement date and the duration. However, there are probably many more characteristics that differ between legal domains. After all, corporate lawyers may want to insert datafields relating to shares and shareholders into #agreement, while employment lawyers may need datafields relating to the collective labour agreement, IP lawyers may want to have datafields relating to the country-specific or worldwide nature of a license agreement, etc. So with respect to this second nature of concepts, issue do easily arise, due to different needs.

The solution in such case is probably to un-tangle the two functions of a concept, e.g. by putting the datafields into separate concepts — such as #shareholder-agreement, #employment-agreement and #ip-agreement, or even better into more detail-oriented concepts, such as #share-structure, #collective-agreement and #ip-territory. Those additional concepts will then probably host only datafields, and never be used for their conceptlabels, but that’s perfectly fine.

Reusing clauses with different concepts

The problem of concept organisation is very tangible when you want to reuse clauses across diverse legal domains. For example, assume you have a boiler plate duration clause with an asymmetric termination notice period that states:

• In employment law: #Employer can terminate the contract at [number] months' notice, while #employee can terminate at [number] months' notice.
• In commercial law: #Company can terminate the contract at [number] months' notice, while #consultant can terminate at [number] months' notice.
• In IT law: #User can terminate the contract at [number] months' notice, while #hosting-provider can terminate at [number] months' notice.
• etc.

The potential reusability of this clause across the legal domains is obvious. However, each clause refers to different #concepts, so at first sight you would be stuck. There are two possible solutions, however,

Solution 1: using higher-level generic concepts

A simple solution is to use higher-level concepts: instead of using concepts #cow, #cat and #dog in a clause, you could simply refer to #mammal. Or, even higher up in the chain, you could refer to #vertebrate, so that you could also cover #shark and #parrot.

Applied to our example, this would mean that instead of #employer, #company and #user, you could use something like #paying-party or #service-receiver, whereby you ideally already provide concept-labels within that concept that point to the “real” concepts (e.g., concept-labels “employer”, “company” and “user” in our example). From a technical point of view, this is a very easy solution, with the obvious advantage that you can draft clauses that work across legal domains.

However, there is a strong downsides: naming your higher-level concept may be difficult. In the example above, you can already feel that “paying-party” and “service-receiver” are somewhat awkward — such abstract terms are hardly ever used in real-life contracts. The mental gymnastics that you will ask from the clause authors that come after you (which could also be your future self next year) will be quite high.

Another downside is that if you mix clauses with the higher-level #paying-party or #service-receiver concepts with clauses that use a more specific #employer or #company concept, you will end up with two different concepts in the list of defined terms. You should then be careful not to assign a definition to the higher-level concept, or you would end up with a definition list that contains two entries for two legal concepts that actually cover the same legal idea.

Also note that clauses will tend to become quite abstract, so you may end up with obfuscated language that was mangled to cover all those different domains. Before you know it, the drafting quality of your clauses may have been degraded to generically formulated clauses that are drafted in such way that they cover as much situations as possible in order to allow them to be easily copy/pasted between MS Word contracts.

Solution 2: using concept mapping

A more technical solution is to map concepts, so that concept #employee (and/or its datafields) gets temporarily mapped to concept #user when the clause gets inserted into an IT-contract. This way, you can draft your clauses with the more specific concept (#employee), thereby avoiding the mental gymnastics, and also not end up with near-duplicate concepts in the terms list. This can be an interesting solution for reusing a limited number of clauses between legal domains.

Solution 3: avoid reuse

As further described below, the number of clauses that span across different legal domains, is actually quite limited. Therefore, do not focus on those few clauses when thinking about the organisation of your clause/concept library. A few duplicate entries in your entire firm’s clause library is really not problematic — think about how far you have come since the days of MS Word where everything was always copy/pasted, and the feeling of the small sin of having a few duplicate entries is really not that bad.

Untangling your organisation structure

Another possibility for untangling, may be found in your organisation structure. Large legal teams tend to have multi-topic sub-departments, such as “IT & IP” or “Employment & Pensions”. When first starting with ClauseBase and discovering the possibility to organise access rights and libraries around groups, you are probably inclined to organise those groups so that they are identical to the organisational structure of the entire legal team. Accordingly, there will be an “IT & IP group” and an “Employment & Pensions group”.

From a document perspective, however, IT and IP are quite different. They may share a few (typically boiler plate clauses), but in practice we see it happen more often that even those boiler plate clauses are differently written by IT-lawyers and IP-lawyers.

In the context of ClauseBase, it is therefore probably a good idea to also split up such groups, and create entirely different concepts in the IT-group and the IP-group:

• One group dedicated to IT contracts/clauses, with its own IT-related clause library.
• One group dedicated to IP contracts/clauses, with its own IP-related clause library.
• A hybrid IT & IP group, that is mainly used as a shared storage facility for work-in-progress (e.g., ongoing contracts for clients). In other words, this IT & IP group would then be mainly used in access bundels, to set the access permissions of folders for which both IT-lawyers and IP-lawyers need access.
  
  Perhaps this hybrid IT & IP group can also host its own IT/IP clause library, to host the (probably few) clauses & templates that are truly common across the two subdepartments. In practice, however, these truly common clauses tend to be limited.

With such organisational structure, the question of how to organise your concepts diminishes quickly, because you can treat IT and IP is entirely separate silos.

Misunderstanding the customer library

ClauseBase always creates a company-wide / firm-wide clause library for every customer. Combined with the platform’s general encouragement to reuse clauses as much as possible, the existence of the customer library will cause many users to think that clauses and concepts should preferably be put in the customer library.

Probably that is not a good idea. From what we see and hear from customers, there are always use cases for customer-wide clause libraries (hence their existence), but those use cases are almost always limited. Due to the different legal subject matter and drafting style, finding common clauses across legal domains tends to be difficult, if not impossible.

In practice, the customer library therefore gets populated as follows:

• A limited number of truly common boiler plate clauses (e.g., applicable law and survival clauses). Note that party introduction clauses may seem a good candidate too, at first glance — but in reality those clauses in fact tend to be quite different among legal domains.
• The bulk of the customer library gets populated with clauses and templates that relate to the company/firm itself:
  • for law firms:
    • disclaimers and general terms & conditions
    • the common parts of law firm engagement letters (many parts are however specific per department/partner)
    • biographies of lawyers, for use in pitches
    • descriptions of recent projects, for use in pitches
  • for inhouse legal teams:
    • clauses describing the structure of the company/group
    • those clauses of the company’s play book/internal rules that span across legal/subject domains

Being realistic about centralisation

You should probably think about reuse and centralisation as a nudging factor and a gliding scale, instead of a hard rule.

In the traditional world of MS Word, nothing is centralised, because everything gets copied and pasted. Things leads to mountains of managerial and quality-related issues, and is clearly not ideal. However, it is very easy to do and requires no effort on the short term.

A fully centralised clause library (with all concepts and clauses stored in the customer library) is the opposite: it your operational circumstances allow for it, then it can bring enormous advantages in terms of management and quality. However, it is not a walk in the park to achieve, because it requires planning upfront, and quite a lot of coordination among stakeholders. After all, any change in a centralised clause library will be immediately felt by all “downstream” users of a clause.

In practice, you will usually end up somewhere in the middle, for example with centralisation per legal (sub)domain. Some authors will go for a hard centralisation approach, in the sense that they will vigorously guard the centralised concepts/clauses, so as to avoid a proliferation of clauses/concepts in each domain. Other authors will go for a soft centralisation approach, where they try go for centralisation if somehow possible, but are forgiving in allowing for exceptions.

Practical examples:

• In practice, firm-wide clause libraries are not realistic for large, full-service law firms with different domains. This would imply that a few uses would have sufficient knowledge of all these separate domains to carefully plan how all the clauses and concepts should interact with each other.
• Conversely, strong centralisation is usually achievable for boutique law firms that focus on one or two legal domains, and are usually smaller. It is realistic to expect that the administrator can sufficiently manage the entire area, and make sure that concepts/clauses do not conflict with each other.
• “Organically grown” clause libraries should probably go for a soft centralisation approach per legal domain, with a limited number of truly shared concepts, and a large number of concepts that are specifically created for certain types of contracts:
  • Group library for domain X
    • Central concepts
    • Central clauses
    • Subdomain X.1
      • Concepts for X.1
      • Clauses for X.1
      • And perhaps even a sub-subdomain X.1.1, with its own clauses
    • Subdomain X.2
      • … mirroring the structure of X.1 …
  • Group library for domain Y
    • … mirroring the structure of X …

Avoid perfection and over-planning

Users who think about concept organisation in ClauseBase, may hesitate to start working because they are afraid that their concept organisation is not yet perfectly laid out, and that a lot of unknown variables will surface further down the road.

It is perfectly normal to have this feeling — lawyers did not have to deal with this problem in the old world of MS Word, so it is natural to feel awkward about this. Perhaps it is useful to look at how other sectors who deal with organisational complexity have managed this.

In the software world, there are essentially two ways to start developing: either the waterfall methodology, or the agile methodology.

• The waterfall methodology was devised a long time ago, when it became clear that constructing software is quite complex, easily leading to “spaghetti” of source code. This methodology essentially requires you to plan everything upfront, so that a “software architect” meticulously walks the end-users through every detail of the software, in order to arrive at an exhaustive plan that covers all functionality. The ideal is that the actual programmers will then simply have to execute this plan, feeling safe that everything is covered.
  
  It turns out that this is very often a bad idea: by the time the software is finished a year later, the world is almost guaranteed to have changed, so that some requirements have changed in the meantime. Even worse is that customers / end-users happen to be extremely bad at expressing their desires: they have a hard time envisaging what a system should look like in practice, and will only realise that something is missing or working poorly by the time everything is ready. In fact, customers / end-users will very often contradict themselves, and realise at that moment that they actually desired the opposite of what they expressed during the planning phase.
  
• The agile methodology starts from the lessons learned from the waterfall methodology, and aims to produce intermediate versions of the software as soon as possible — even if those intermediate versions are only partially ready, full of bugs, etc. The idea is to get customer/end-user feedback as soon as possible, and continue iterating the software, so as to arrive at a software system that is constantly improving, while everyone realises that the perfect system will never be reached. Furthermore, because all programmers know that changing the software will be a certainty, they will tend to plan for change when actually constructing the software (as compared to the programmers working with the waterfall methodology, who are much more inclined to have a static view on the software — as, after all, the software was exhaustively described in the plan).

In our experience, the parallels between the world of contract drafting and the world of programming are striking from a certain distance:

• Clause / template authors do not always know what the complex system should ultimately look like.
• End-users will often only realise what a system should look like, by the time they can actually interact with the system.
• Most importantly: change is almost a certainty, but perhaps not in the way you expect. Even for straightforward documents where the legal contents hardly ever changes profoundly (e.g., an NDA), change is almost guaranteed… because the legal world is migrating from the world of MS Word to automation in software platforms such as ClauseBase.
  
  In our experience, most legal experts have a very hard time to imagine what automation can really do for them, and are therefore inclined to start from their traditional MS Word file, mapping it in a very straightforward manner to an automated document and Q&A. Soon, however, they will discover the true potential of what ClauseBase can do for them, and desire changes to the document — e.g., making it much more dynamic, inserting additional options, etc. This will almost certainly lead to quite some changes in the way clauses are constructed, and how concepts should be organised.

The lesson we want to convey: do not fall into the trap of the waterfall methodology, by postponing your actual implementation until you have all requirements laid out. Similar to software development, it is very hard for end-users to capture the complexity of an interactive contract, and get it right the first time. Instead, we advise you to proceed in small steps, do lots of experiments to test hypotheses, and work closely with stakeholders. Problems will then be identified earlier and worked around.

After all, you can be almost certain that whatever you create, even with the most carefully planned approach, will need to change once your end-users lay their hands on your work. So opt instead for some planning, and make use of all management options you can find in ClauseBase that will facilitate change — such as external snippets, data expressions, placeholders, parameters, shared Q&A conditions, Q&A proxies, etc.

Dealing with client-deviations

Even when you have carefully planned your entire clause library for full centralisation, reality may suddenly bite you.

For example, assume you have check with all stakeholders in the company/firm in order to draft 4 different payment clauses, that should cover the various situations you may encounter in practice.

Everyone is happy, until one day the audit department of client A — who, on your advice, uses version 2 of your payment clause — will suddenly require a specific sentence to be inserted in the payment clause. This sentence is not relevant for any other client, so you are confronted with the question of whether to create a 5th version of the payment clause, or whether instead you simply insert a condition {#client^name = "A": ... } that will insert that specific sentence. In the short term, when this is the only deviation you encounter, using a client-specific condition is probably the way forward.

However, as things tend to go in reality, a few weeks later there will also be a client B with a specific request, and then a client C, and then … Or perhaps you do not have to deal with specific client-requests, but with specific requests from your colleagues from other legal domains, who argue that “This is a perfect generic clause, but inserting this additional sentence is really crucial to make it enforceable in [legal domain X], in light of the recent decision of Supreme Court [Y]”. Who are you to argue against the Supreme Court?

At some point in time, you end up with a supposedly generic payment clause that is loaded with specific deviations. This will not only become problematic from a management point of view, but also from a mental point of view, because those clauses tend to become puzzles that are so complex that you quickly lose control.

At that point, you should probably create client/domain-specific version of version 2 of the clause, and use those specific versions in the relevant client/domain-specific template. You may initially feel bad about this, but an important adagium in software development (where managing complexity is of the utmost importance) is that simplicity often means making more things, not fewer. So as soon as you feel that you are intertwining texts and forcing them to become part of a single clause to such extent that it becomes difficult to understand, you should start making copies of the clause…

… or you should further sub-divide your clause, as described in the next section.

Further sub-divisions with external snippets

The strength of ClauseBase is that it allows you to think at the level of clauses, instead of at the level of entire templates. When thinking about the organisation of your clause library, you can take this idea one level further, by thinking at the level of snippets, i.e. parts of a clause.

For example, in the problem of the generic payment clause above (a generic clause with a certain part that is very specific for several clients), you could opt for the following structure:

1. Generic clause constructed as follows:
   
   1. Generic paragraph alpha.
2. Generic paragraph beta.
@#client-specific-payment-stuff
   
2. Contents of the separate clause client-specific-payment-stuff:
   
   {#client^name = "A": @#specific-payment-stuff-for-A | "B": @#specific-payment-stuff-for-B | "C": @#specific-payment-stuff-for-C}
   

This has the advantage that the client-specific parts get centralised into a specific sub-clause, which allows for re-use of that client-specific part, and avoids that the generic payment clause gets “polluted” with client-specific elements.

The globo-panel is your friend

To get a quick glance of the available concepts (and to avoid that you would create concepts that already exist), you probably want to use the globo panel. It shows you all the available concepts at the left side of the screen, and allows you to easily search for available concepts and datafields.