In my arbitration clause, I want to ask the user whether there should be discovery limitations and if there are, provide some options to include language for a couple of different types of limitations.
In my current automation platform, it is possible to nest conditions (“business rules”). In other words, my outside business role would be a true false about whether they were discovery limitations, and Inside there would be choices for the types of discovery limitations.
In Clausebase, I don’t see a way to nest conditions. Thus, I had to use “and” logic as follows:
In my current automation platform, due to the tight relationship between the “template” and the “questionnaire,” if a dependent question is not computed as being logically relevant as the questionnaire is being used, the non-relevant dependent questions automatically are not shown.
In this example, if the user had answered “false” for discovery limitations, then in my current platform, the other questions simply don’t get asked. The platform computes relevance.
I am noticing that in Clausebase, when I “batch create” cards in the Q&A, the logic implicit in the document is not automatically picked up and conditions automatically added to a card; I have to add the logical relationships by manually placing conditions in the Q&A, as below – even though it’s already implicit in the document. Am I correct?
ClauseBase allows nesting decisions any level deep, allowing you to model very complex legal logic. For example, by way of demo, we recently implemented an EU flight delay compensation that calculates whether you are eligible for compensation and (if so) calculates the amount and composes the letter for you. The amount of “business rules” for this calculation is almost mind-boggling: it depends on a combination the country of origin, target country, home country of the flight operator, distance, intermediate stops, number of hours of delay, weather conditions, certain behaviours of the passenger, etc.
Similarly, we very frequently draft party introduction clauses that demonstrate the rich modelling toolbox offered by the platform. Such as clause can then completely morph into something else depending on the type of person (natural person or legal entity?), the type of legal entity (for some types of entities it is required to switch the formal title of the representative), the country of incorporation, the sub-region of that country, the number of representatives for the entity, the number of intermediate representatives, etc. You easily end up with hundreds of combinations, for a “mundane” party introduction clause…
In ClauseBase, you can insert business rules at two locations: within the clauses themselves and at the Q&A level. There is no absolute right or wrong on which location you use (typically you combine the two, as they work in tandem). The reason for putting the business logic at the clause level, is that that logic will then be available across all the different documents and Q&As where that clause gets inserted; conversely, business logic at the Q&A level only applies in that particular Q&A.
For your particular example, both locations seem reasonable. If you want to reuse this particular clause across documents/Q&As, and always want to apply this same logic (discovery limitations? --> if yes, then provide options and limitations), then go for the clause level. If not, then I’d go for the Q&A level.
The fact that these two locations can work in tandem, but are formally separated, is the reason why the business logic is not “picked up” automatically by the Q&A in batch create. There is no reason to do so in ClauseBase, because the business logic at the two locations will work in tandem anyway; the Q&A logic layer does not need to “import” the logic of the clause level; it will always work on top of the clause level layer.
For logic at the clause level, you have to work with AND/OR/NOT. In addition — it’s unclear to me whether you are aware — you can nest conditions within conditions within conditions … any level deep.
For example, you could express “arbitration applies --> two options relating to arbitration are relevant --> and within the first option, two different suboptions apply” as follows:
{#disputes^arb-discovery: Arbitration applies, and {#arbitration^option1: option 1 can be invoked {#arbitration^suboption1: suboption X also applies | #arbitration^suboption2: suboption Y also applies} | #arbitration^option2: option2 can be invoked} | else: No arbitration applies.}
But in complex situations — which are more the rule than the exception in the legal context! — this quickly becomes difficult to read. Hence the existence of internal snippets, which allow you to reformulate as:
{#disputes^arb-discovery: Arbitration applies, and @OPTION1-OR-2 | else: no arbitration applies}
OPTION1-OR-2 = {#arbitration^option1: @OPTION1 | #arbitration^option2: @OPTION2}
OPTION1 = option 1 can be invoked {#arbitration^suboption1: @SUBOPTION1 | #arbitration^suboption2: SUBOPTION2}
SUBOPTION1 = suboptionX also applies
SUBOPTION2 = suboption Y also applies
OPTION2 = option2 can be invoked
From what I hear from users coming from other automation platforms, the internal snippets really help in avoid the typicaly “spaghetti” that you tend to quickly get in any real-life business logic.
At the Q&A level, you express the business logic through the question/card/change conditions, as you demonstrated in your screenshots. This may not be apparent immediately, but the reasoning mechanism is actually quite similar to the AND/OR/NOT — but expressed in a visual way through colored boxes. By created subgroups of conditions, you can go any level deep. Moreover, through the repository panel of the Q&A, you can centralise a complex condition, which you can then include in cards/questions/changes to combine with yet other conditions to model any complexity you like.
You are right that you model a dependency between two cards/questions by including a condition on that card/question that refers to the (lack of) answer or (in)visibility of some other question. Because ClauseBase deliberately avoids decouples templates, questionnaires and datafields, you get much more flexibility than in the other automation platforms. The downside is that you have to model some things more explicitly, but most users find this a small price to pay, due to the significantly increased flexibility.
Somewhat related to your question: we will add an option this weekend that allows you to state that a certain question will automatically cause all other questions in the same card (or in the same category of cards, or even in the entire remainder of the Q&A) to be disabled as long as that first question is not answered. This, in certain ways, also expresses a dependency relation.
Thanks for all this great information, which I will digest. Per #3, I did not appreciate that nested conditions were possible though I agree that it gets hard to follow pretty fast. Snippets are indeed great for this reason.
Minor note: in your help page for disabling subsequent, there’s a verb missing somewhere: “you can easily that.” Maybe “see?” Feel free to delete this comment once you address.
