The following sections also relate to data. Please consider the holistic data requirement when designing the data model:
Data used for Contact Generation is (for the most part) captured during the initial contract generation interview. At this point, the system will create an “answerset”, which is a key-value pair table of the answers provided by the user (or calculated from other variables). This answerset is stored against the contract object and is reused whenever a user revisits the interview, including the generation of amendments or orders for that contract. This avoids the user needing to rekey answers/data in subsequent processes.
Even though the answerset will populate the ‘Data for Contract Management’, it is distinct from it and should not be assumed to have a 1:1 relationship with it.
There is no set of scoping questions. Rather, each contract to automate is reviewed during the ‘Authoring workshop’ where each moving part is marked up with the ‘rules’ that relate to it, as well as which areas are data points (and where the source of the data will come from).
CLMA has designed a Universal Contract Model (UCM) dataset that covers most use cases. This should be the starting point, and indeed it should remain the bulk of the data model. Please refer to for the latest version of the UCM.
Where a data point does not exist in the model, then it can be extended through the use of custom variables. However, please bear in mind that related functionality (e.g. out of the box reporting, etc.) are based on the UCM data model. If the UCM is not used, then it will result in the related functionality being unusable.
To determine whether further data points are required, it is necessary to understand what the data is used for (during contract generation). There are six types of data:
- Straight forward data points (e.g. effective date, etc.) These are values which will be displayed ‘as-is’ in the document being generated
- Multiple Choice Questions (e.g. payment terms = 30 or 45 or 60 or 90 days). These are used to provide a list of predetermined values that a user can select (as opposed to them typing freely)
- Conditions (e.g. variable x is greater than y). These are used to determine whether specified content should be shown/hidden
- Gating questions (e.g. Does the contract include special provisions?). These questions are used to set Conditions that will determine whether subsequent questions will be presented to the user. I.e. it can show/hide logic (as opposed to content).
- Calculations (e.g. Sum the values of variable x and y). These are used to derive/calculate a value using the values of other variables.
- External Query. These are related to integration points where data is received from a 3rd party application (or even internal system, as in the case of looking up clauses from the Clause Library)
From a best practice point of view for designing the data model (for Contract Generation), always start by mapping the data points required to the UCM. (It is easiest to complete this during the Authoring Workshop when the contract is being marked up. If there is a data point required, then consider which of the 6 data types best fit the need. (In the case of calculations or data lookups, also ensure that the pre-requisite data is available to perform the calculation or “call out” to the 3rd party system).
Also, when custom data points are required, follow the established naming convention to avoid confusion / improve ease of maintenance.
- As variables are reused across the documents that will be generated during the contract’s lifecycle, it is important to understand when to reuse a variable (as it is a shared variable e.g. for amendments) and when to have it’s own version of a variable (to avoid overwriting the value of the main contract).
- Consider whether the document being generated needs to be 100% ready to send to the customer, or whether it’s to get to a “good first draft”. Avoid over-engineering the template. (Don’t try and automate the complex stuff. Let the machine do the onerous work and the human the complicated work.)
- Cater for the main use-cases. When adding in data to cater for edge cases, be very cautious. It is easy to inflate the data model, but this has potential downstream consequences (e.g. reporting data). Sometimes it is better to just treat exceptions as exceptions i.e. something that can be tweaked manually on the odd occasion it is required, rather than handling each and every rare edge case. (Just because you can, doesn’t mean you should.)
Things to avoid
Not using the UCM and designing a whole custom data model from scratch.