Why concepts and clauses?

Variables without concepts are not conceptually grounded.

What does {{amount}} mean in a template? How about {{height}}?

Contrast with a locale-independent concept model/ontology/data model:

concept **Loan** has-a-property **Amount (a Monetary Amount)**

Why Clause Templates?

Natural language references concepts and concept properties. Concepts are referenced in locale-specific natural language, with unambiguous semantics.

These snippets of natural language (Clause Templates) are the reusable components of agreements/contracts/documents that are generated from concept instances (data).

• Clause Template: Loan Repayment Terms

• Concept Reference: Loan

• Locale: en

The {{amount}} is payable on the 1st of each month, until the full balance has been repaid.

This allows one to find text that is about loans, or loan amounts, independent of the locale of the natural language; and the text is semantically distinct from text that is about the amount of goods purchased, or the amount of time taken for a package delivery before fees are incurred.

Implications of Not Using a Concept Model

Absent a concept model, companies end up with a flat “sea of fields”, with all the semantics of the fields carried by the field name. Typically the field name has to be supplemented by notes in documents or spreadsheets to define a common business glossary or ontology. In some cases companies encode concepts and ontology within the names of fields themselves, creating fields such as Address_Line1, Address_Line2, Address_City, Address_State etc. This scales poorly, particularly when dealing with real-world business models that often contain different types of complex concepts and relationships. For example, a hospital will need to model a Patient concept, a car manufacturer may have to model a Car or an Engine, or a Product Warranty. These are complex concepts, in that they typically have many properties (some required, some optional), and may have related concepts (a Patient may elect a Next of Kin, for example; a Person).

This clumsy approach is also fraught with risk, as it encourages teams to use fields with the same name for different semantic purposes, which leads to poor data quality and downstream reporting and analytics challenges: “When you use the field {{amount}} for an NDA contract, what do you mean exactly? When I use it in a PO, this is what I mean…” Conflating the name of a variable, {{amount}} for example, with its semantic meaning, “the amount of a purchase order” vs. “the capped liability amount for an NDA,” creates a need for documentation for variables that lives outside of the systems that use the variables, often in spreadsheets, documents or even on PostIt notes!

A mature approach to manage the data points within clauses acknowledges that clauses ARE concepts. Payment Terms is a concept that is itself specialised into lots of different types, each with their own semantics and properties:

Source: Google

In summary, I would encourage you to approach the management of contract data with a hierarchical concept model in mind: different types of contracts include different types of clauses. Clauses are concepts with properties. Contract natural language expresses (uses) a clause concept. There may be many ways of expressing a Net-30 payment term concept, not least in different natural languages, but the concept should remain semantically the same and be consistent. When done well, this will enable you to query for all contracts that include a Net-30 days payment term, independent of the exact natural language used to express the concept, be it minor variations in wording,or whether the contract is in German or Japanese.