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 like 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. E.g. 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 if in a PO this is what I mean…