Contracts are generally in the form of mostly unstructured text. The core function of an Embeddable Contracts AI is converting that unstructured text into semi-structured (e.g., provisions) or structured (e.g., entities, normalized values, “answers”) data. Other Contracts AI features derive from this core. Let’s walk through some different types of data produced.
Provision Extraction Provision extraction is the AI finding clauses in a contract, e.g., an agreement’s term, termination, indemnification, exclusivity, tenant’s right to sublet, or default for cross default clause. This is generally a classification task: it works by the artificial intelligence reading text, and deciding that a given batch of text (ranging from a few words to a few paragraphs) is (or is not) an exclusivity clause, say. Provision extraction generally involves taking unstructured contracts and turning them into structured data.
Clustering is the grouping of related information together. In general, contract information tends to be grouped along two attributes:
Provision-level clustering. Document clustering. Provision-level Clustering In provision-level clustering, similar provisions are grouped together. So, for example, clustering might enable an end user to see change of control clauses in other documents similar to one they had just reviewed.
Grouping similar provisions together can be a useful feature because it:
Enables end users to review pools of contracts more quickly for clauses they care about. Provides end users with another tool to make sure that they don’t miss information that they might care about. Can be used to cluster documents (e.g., Documents A, B, C all have Change of Control variant X, Assignment variant Y, and Exclusivity variant Z). Can be a way to help build training data for teaching provision extraction models. Though note that it can be dangerous to rely too heavily on this approach to generating training data because provision-level clustering can miss different ways of phrasing the same provision. Provision-level clustering has a risky side. Provision-level clustering is a mediocre way to find provisions, and can lull users into a false sense of security. Here is what I wrote years ago (2013?) on using a comparison-based (clustering) approach to finding provisions in contracts:
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.
Document comparison shows differences between one document and another (or others, in the case of multiple document comparison). This can otherwise be known as redlining and blacklining. Think track changes, but (potentially) in situations where track changes wouldn’t work, like where one or more documents are not a Word document (e.g., a PDF or image file), or where you need to compare multiple documents against one base document.
Document comparison is useful in multiple situations:
Contracts are frequently part of a family of agreements: a base agreement; amendments to it; renewals; sub-agreements; as well as schedules, addendums, and statements of work under it. At Kira Systems, we had one customer contract family that I suspect was 25 documents. Contract AI users can be well served by seeing all these documents together. Related document linking (aka related document grouping) attempts to automatically identify documents that are part of the same family.
Contract risk scoring assigns a risk grade to agreements (or clauses), based on some predetermined view of what constitutes contract risk. Risk definitions could be determined by a vendor, or they could be custom for an individual organization deploying the technology.
Certain clauses - or wordings of clauses - have the potential to be high risk. These include:
Restrictive covenants - exclusivity, non-competition, and (less so) non-solicitation. Indemnification. Most favored customer treatment. (Unlimited) limitation of liability. Some other clauses could be medium-to-low risk, depending on the organization. These include (an incomplete list):
Signature Detection and Recognition
Signature (and Other Handwritten Information) Detection and Recognition Signature detection helps determine whether a document has been signed. A related feature identifies whether pages have any handwritten information on them. Recognition refers to actually converting that handwritten information to text (i.e., analogous to OCR on printed text).
Signature detection is useful because:
Often there can be many draft versions of an agreement floating around, and the signed version will be the one that matters. (Unless it’s been amended, in which case the amended agreement will matter too.) If doing post-signature contracts work—like contract analysis or contract management, users will care (most, or maybe exclusively) about the executed agreement. In multiple post-signature areas (contract analysis, CLM, VDRs, lease management), users can really care whether agreements are fully executed. Sometimes parties think documents are fully signed but they aren’t (or they are fully signed but no-one can find the fully signed agreement). Signature detection can guide end users to higher priority spots - e.g., agreements that are not executed. Detecting other written information in documents can be useful too:
Optical Character Recognition (OCR)
Many contracts come in the form of image files - i.e., they are scanned documents. In order to review them, the images need to be converted into (correctly laid out) text. This is where Optical Character Recognition (OCR) comes in. OCR converts images into text. So you can upload a contract (or other document) in the form of an image file into the Embeddable Contracts AI application you’re using, and OCR will convert that file into text, which the Embeddable Contracts AI can process further (e.g., identify document type, extract clauses).