In a contract, defined terms are words given a specific meaning. E.g.,
“Start Date” means September 1, 2019.
“Usage Data” means information reflecting the access or use of the Services by or on behalf of Customer or any User, provided that for clarity Usage Data shall not include any Customer Data or any information that identifies, or reasonably would permit identification of Customer Data.
Defined term detection is tech that finds defined terms in contracts.
Defined terms really matter. Words in contracts—especially defined terms—don’t always mean what a reader would expect. People (or at least careful people) who review contracts have to frequently check relevant defined terms as they go in order to determine what contract clauses actually mean. Since contract reviewers regularly look for defined terms, defined term detection can be useful to power features that more easily expose reviewers to defined terms they care about. For example, a pre-signature (e.g., contract negotiation) or post-signature (e.g., CLM or contract analysis) system could offer:
- Hover over defined terms, so that a user could see what any defined term means just by hovering over it, either in the app’s document viewer or results.
- A searchable index of defined terms for each document. (Since not all defined terms are defined in the definitions section of the agreement (often article 1) - some are defined in the body of the agreement (though ideally are listed in the definitions section).)
It’s not uncommon for defined terms to be embedded inside other defined terms. In the “Usage Data” example above, “Services,” “Customer,” “User,” and “Customer Data” are all embedded defined terms. In fact, each of these defined terms may have further defined terms embedded within them. They can resemble Matryoshka dolls, in a way. This can be tricky for software UIs seeking to expose defined terms, though is also a reason why defined term detection exposing software can be useful for contract reviewers (in that it can take contract reviewers work to find a defined term that they need). Sometimes, embedded defined terms will be defined terms under another agreement. For example, a contract might read:
“All terms not defined herein shall have the meaning given to such terms under the [Master Agreement].”
So, to find the meaning of some defined terms, a reviewer may need to go to another agreement. This is especially common in families of related documents. At this point, my guess is that it is unlikely that different Contracts AIs will pull the defined term from a different document. To get this right, the Contract AI would require all of the related contracts at the same time, the ability to identify defined terms, the ability to group related documents (e.g., MSA to individual agreements), and then linking the terms to the document. Not impossible, but difficult.
Note that some provision extraction models pull defined terms. E.g., the Zuva DocAI “Affiliates Definition” or “Control Definition” AI fields return specific defined terms. Defined term detection is broader, finding all defined terms in a document (though not necessarily being able to identify specific defined terms).
If evaluating different defined term detectors, you will probably be primarily reviewing for accuracy. Test detectors on a variety of different documents, ideally like those that your system will see in the wild. Also test embedded defined terms - what a system returns for defined terms inside of defined terms.
Share this article:
