ContractStandards Modular Libraries

As a bit of background, ContractStandards is a site for attorneys in need of contract language. It is a free reference resource that lawyers can use to get standardized contract and clause language, along with relevant research, case law, etc.

We use machine learning tools to analyze real-world contract language and generate “market standard” language from that analysis. We also offer customizable libraries to enterprise clients.

The way we manage both private and public content is through a system of linked clauses and contracts. Our platform treats clauses as modular Lego pieces that can be assembled in a variety of ways to create new contracts. Our model borrows heavily from similar concepts in software development and design.

This is a brief look at problems we encountered, our solutions, and user reception.

www.contractstandards.com

The Problem

When the site first started, we were maintaining two types of content: contracts and clauses. These libraries were not linked in the database. For consistency and maintenance purposes, we tried to manually keep the two libraries in sync. That is, we wanted the “License Fee” clause in the clause library to be the same as the “License Fee” clause we were using in our Software License Agreement in the contract library.

This manual syncing proved to be a logistical nightmare for the free content we were maintaining and our clients trying to manage their own resources. A change made in the clause library would not be reflected in the contract library and vice versa. If a user wanted to change to a clause in the clause library, they would also have to manually make that change in any contract using that clause.

The original contract Editor in ContractStandards. The contract was edited as one document. Syncing language in the clause and contract libraries required copy and paste and manual review.

The Solution

We wanted a system that made it easier for users to integrate their libraries. This content is often being reviewed by legal counsel, adjusted to different business needs, and adapted to reflect new legal challenges. Our system needed to reflect that dynamic nature.

The new system we built treated contracts as outlines of a document to be made whole by syncing clauses with that skeletal structure. By properly syncing clauses with contracts, users could create fully-formed, usable documents.

The contract editor in ContractStandards. The document is made up of several clause blocks. On the left side is the document outline. Users construct contracts by linking clause blocks from their clause library to the outline.

This new system offered a couple of benefits over the old:

1. Contracts are no longer static documents. The syncing mechanism we built meant that a change to an underlying clause would be automatically pushed to any synced contract. Thus, if a user wanted tougher intellectual property protection in their various sales and license agreements, they only had to update the relevant clause once in their library.
2. Clause language is reusable. Different types of contracts often use some of the same “boilerplate” language. Lawyers managing a template library do not want to have to maintain separate “Arbitration” provisions for all of their contracts. Ideally, lawyers have one snippet that works across all documents. Our platform allows that kind of reusability. If a user has some language already in their clause library, the system allows and encourages them to sync that language across many different contracts.
3. Greater insight into a user’s content. Syncing content also allows a user to very quickly see where their clauses are being used. It is one thing to create better clauses, it is another to ensure that they are actually deployed in the user’s agreements. Our platform allows a user to see a clause’s synced agreements so they can better assess how clauses are being used.

User Reception

When we first implemented the platform, feedback from users hit on the following issues:

1. Hard to see how all clauses came together. Despite the benefits of a modular system, users still missed a way to edit a document as a whole. Early versions let the user see all of the clauses assembled together but the user had edit the clause record in order to change text. This proved tedious and required a lot switching to new screens. In response, we built a contract editor that let you edit the clauses in your document. The layout preserved the modular feel but allowed for greater editing of the document as a whole. Users can make an edit in the contract editor and immediately publish that change to the underlying clause record.
2. Content too connected. As we made it easier to sync clauses across contracts and edit content in multiple places, users became concerned that they would change a clause in one context and create problems in other contexts. To address this problem, we borrowed again from the world of computer programming. Users can now fork clause language. If a user makes a change to a clause in a contract that they think might negatively impact other contracts (e.g., introducing more stringent terms or new defined terms), they can simply fork that changed language and save it as a variant of the original text.

Conclusion

In developing this new platform, we solved the initial problem of syncing content libraries. Contracts and clauses are linked in a way that reflects how they are used in practice and makes it easier to manage large collections.

However, in solving one problem, we exposed another. Our next barrier to adoption inside organizations is cultural. Most lawyers are not used to a modular contracting approach. To adopt the system, a change in contracting culture is likely necessary. That is never an easy thing.

This is an iterative process and it is hard to say exactly how a feature or product will evolve. I suspect our challenges going forward will focus on integrating our platform into existing contracting cultures or finding ways to encourage changes in the culture.