How to Build a Contract Schema: A First Look

Start with a business problem, define the fields and refine them using real contracts to make AI more effective

Hi everyone,

To get the most out of contract AI, you need a good contract schema: a blueprint that specifies and defines which fields to capture, what they mean and how to structure them.

I defined my first contract schema back in 2018 at Axiom, before AI use became mainstream, and have continued building schemas in the AI era. Here I focus on the principles that haven’t changed and are likely to remain useful, even as AI models and related capabilities continue to evolve.

A good contract schema balances two interrelated objectives:

• Value for the customer or end user: The schema should help produce data that is accurate, consistent, searchable and useful for answering business and legal questions and reporting.

• Efficiency of capture: The schema should make it straightforward to extract or capture that data using AI or other techniques.

Defining a contract schema: start with the problem

There’s no one right way to define a contract schema, but I’ve found a hybrid approach to be effective. Start from the top down by defining the initial problems to solve and drafting an initial schema. Then use a bottom-up approach to test and refine the schema using real contracts.

1. Start with the problem. Decide what business problem or use case you’re solving for. Common examples include making contracts easier to find, M&A diligence, regulatory remediation (e.g. data privacy), internal risk reviews and revenue optimization.

2. Identify the data points needed to address it. Different use cases need different sets of fields:

   • Making contracts easier to find usually requires metadata fields such as document titles, party names and effective dates.

   • M&A diligence or integration typically requires fields such as assignment, change of control, governing law, notice, termination rights, restrictive covenants and other fields specific to the industry, company, and deal.

   • Risk reviews often require fields such as indemnification and limitation of liability.

   • Revenue optimization may require fields such as price increase rights and payment terms.

3. Structure those data points into a schema. A good rule of thumb is to balance enough granularity to be useful without making the schema overly complex to understand or use. Include a mix of yes/no fields indicating whether clause language is present and fields capturing which parties it applies to, exceptions or carveouts, dates and quantities.

4. Test against your actual contract population. A schema isn’t defined in a vacuum. The specific contract population you’re working with impacts the priority of the problems, whether the first pass of the schema is useful and how efficiently the schema can be applied to capture data.

M&A Diligence / Integration Use Case: Assignment

To illustrate, let’s go through a common use case: M&A diligence and integration.

Corporate transactions such as mergers, acquisitions, divestitures and internal reorganizations can trigger assignment restrictions and related counterparty outreach requirements. This means one entity (typically the entity being acquired, divested or reorganized) often has some obligation to get permission from or notify its counterparties to transfer those contractual relationships to a new entity.

These are important because often there are valuable customer or other commercial contracts in place that the acquirer or new entity wants to continue (e.g. as part of a business strategy to enter into a new market). Failing to obtain the relevant permissions can trigger termination rights or otherwise jeopardize the relationships and create other legal or commercial obstacles to completing the transaction.

Turning the assignment use case into a schema

We can translate this use case into a set of questions and conditional logic:

• Does the contract contain assignment language?

• If yes:

  • Is the contract freely assignable or are there restrictions?

  • If restrictions exist, are they:

    • Prohibitions in all cases?

    • Consent requirements?

      • If consent requirements exist, are there exceptions? (e.g. assignment to a subsidiary or related entity)

    • Notice requirements?

These in turn can inform an illustrative schema as follows:

\(\begin{array}{|c|l|l|l|l|} \hline \textbf{#} & \textbf{Field} & \textbf{Type} & \textbf{Allowed values} & \textbf{Applies when} \\ \hline 1 & \text{Assignment language present} & \text{Single-select} & \text{Yes / No} & \text{Always} \\ \hline 2 & \text{Assignability} & \text{Single-select} & \text{Freely assignable / Restricted} & \text{1 = Yes} \\ \hline 3 & \text{Restriction type} & \text{Single-select} & \text{Prohibited (all cases) / Consent / Notice} & \text{2 = Restricted} \\ \hline 4 & \text{Consent exceptions} & \text{Single-select} & \text{Yes / No} & \text{3 includes Consent} \\ \hline \end{array}\)

Testing and refining the assignment schema using real contracts

We’ll want to test our initial schema to identify opportunities for refinement.

We can do this by applying the schema to actual contracts, as shown below, reviewing the resulting data and deciding whether we want to make adjustments.

\(\def\arraystretch{1.35} \begin{array}{|l|l|l|} \hline \textbf{Contract language} & \textbf{Field} & \textbf{Value} \\ \hline \textbf{S152 (NDA)} & \text{1. Assignment language present} & \textbf{Yes} \\ \text{``Neither party shall assign or delegate its obligations under} & \text{2. Assignability} & \textbf{Restricted} \\ \text{this Agreement, either in whole or in part, without the prior} & \text{3. Restriction type} & \textbf{Consent} \\ \text{written consent of the other party.''} & \text{4. Consent exceptions} & \textbf{No} \\ \hline \end{array}\)

For example, the categories above can overlap and require both consent and notice. Sometimes we may want to add a field that includes the types of exceptions to consent, or expand the pick list options in an existing field to account for new scenarios.

The goal is a schema that helps solve for your use case and can be applied consistently across the contracts you care about.