When drafting a template clause for a clause library, you would sometimes have a version that is drafted in the interest of one of the parties or in the interest of both parties.
I wonder what is the best way to approach this when populating a clause library within ClauseBase. For example:
Do you create and have separate clauses to address each situation and then maybe set these clauses as alternatives (this of course creates a number of similar clauses within the library)?
Do you create separate paragraphs within the same clause and make them conditional ? Something along the lines of the following (this gets not very convenient if you want different things for different clauses):
1. {#contract^acting-for-buyer: Some clause drafted in the interest of the buyer.}
2. {#contract^acting-for-seller: Some clause drafted in the interest of the seller.}
3. {#contract^acting-for-both: Some neutral clause.}
Or do you use some other magic trick?
Would be interesting to know how any of you approaches this (and whether you are happy with your approach) before making the decision myself.
Maybe ClauseBase folks have some recommendations as well.
The ClauseBase philosophy is that many roads can lead you to Rome — there is no “right” or “wrong” approach here, and it will depend several factors, such as:
How much “magic” do you generally tend to include in your clause library? Some law firms opt for a plain approach without too much conditions and datafields, because this has a low barrier and is closest to the traditional way of working; other firms quickly gravitate towards very heavy clauses with many options and conditions inside.
Another advantage of plain clauses is that they allow you to add straightforward attributes (e.g., 3 out of 5 stars for a neutral clause). For “chameleon clauses” that can take many different shapes due to conditions inside them, you cannot assign a single amount of stars, because such clause can morph into many different shapes that would each have a different “star” attribute.
By the way, if you would opt for plain clauses but want to avoid repetition, a recommendation would be to single out common parts into external snippets that are then shared between multiple variations of the same clause.
How many other variations are there in your clause? In your example, you end up with three different versions along the “in favor of” axis. If you would also want to include two other axes (e.g., “relative length” and “formalness”) that bring their own deviations to the clause, then you would end up with an explosion of clauses in your library. In such situation, I would tend to go for one big “chameleon” clause.
Chameleon clauses also have the advantage that they are easier to control within the Q&A, because you have to only manipulate some datafields through questions/answers. Particularly when you have many different variations (> 5) of the same clause, it becomes somewhat burdensome to include all of them as alternatives in a change set of the Q&A.
A downside of chameleon clauses is that they can lead to surprises for average Assemble Document users who are unaware of how the clause will actually morph. We have seen unfortunate situations with “magic values” that completely morph a certain clause into something else (e.g., if the contract value happens to be between X and Y, then suddenly entire paragraphs get added or deleted) — this is fine if you are the clause author because you then know what a clause may do, but other users have to be educated about this kind of magic.
By the way, we are currently extending the platform with functionality to improve how end-users can fine-tune individual clauses with complex conditions, to minimize surprises. Stay tuned!