How to Set Up a Clause Library

A clause library is a bank of pre-approved wording, one entry per clause type, each with an approved version, one or two fallback variants, and a note on when to use which. Most legal teams do not build one on purpose. It accumulates by accident, a folder of clauses copied out of old contracts, with no owner and no record of why any particular version was chosen. This guide is the step-by-step build: what to harvest first, how to structure each entry so it survives a real negotiation, and three places where an Indian statute changes what "approved wording" has to say, not just how it is filed. (Adira, which publishes this guide, sells CLM software that includes a clause library; disclosed here because the rest of this page is written to be useful whether or not you ever buy anything from us.)

If you are not sure whether you need a clause library or a template library, our companion piece on clause library versus template library draws that line first, since building the wrong one wastes the effort a working library would have saved. Otherwise, start below.

Step 1: Harvest clauses from your best contracts, not all of them

Do not start from a blank page, and do not start from every contract you have ever signed. Pull ten to twenty of your best, most recently negotiated agreements per major contract type, meaning the ones your legal team (or founder, if there is no legal team yet) would point to and say "this is how we actually do it," not whatever is easiest to find. A five-year-old MSA nobody has looked at since is not a source, it is a liability waiting to be copied forward.

Go clause by clause through each one and pull the wording for indemnity, limitation of liability, confidentiality, IP assignment, governing law, termination, and whatever else recurs across your contract types. Copy the actual signed wording verbatim rather than summarising it, since paraphrasing at this stage is how a library ends up with wording nobody actually agreed to. Where two of your best contracts disagree on the same clause, flag it instead of picking one silently, that disagreement is a decision for the named owner in Step 5, not something to bury by whichever version got copied first.

Step 2: Categorise by clause type, and link each entry to its explainer

Structure the library around clause type, one category per clause, not around contract type. A single "Indemnity" category should serve your NDAs, MSAs, and vendor agreements at once, rather than duplicating near-identical indemnity wording inside twenty document-specific folders. This is the most common mistake when a clause library grows out of a template library: teams keep the document-first structure and just add more documents, instead of pulling the recurring clauses into their own reusable layer.

Every category should link to a plain-English explainer of what that clause does and what to look for, so a non-lawyer choosing between the approved and fallback version understands the trade-off instead of guessing. Adira's explainer set covers the standard categories a first library needs: start with indemnity, limitation of liability, confidentiality, IP assignment, non-compete, and governing law. A library entry with no explainer attached is a wording bank; a library entry linked to an explainer is something a junior team member can actually use safely.

Step 3: Give every category an approved and a fallback variant, with usage guidance and risk notes

This is the step that separates a working clause library from a pile of clauses. Every category needs at minimum an approved variant, the wording your team opens negotiation with, and at least one fallback variant, the wording you accept when the counterparty pushes back, with a stated trigger for when the fallback applies. A category with only one version is not a library entry, it is a hope that nobody ever negotiates.

Each variant needs a short usage note (when it applies, to what kind of counterparty) and a risk note (what you give up by using the fallback, in one or two plain sentences). Take limitation of liability: the approved variant might cap liability at 12 months' fees with an uncapped carve-out for IP infringement and confidentiality breaches; a fallback might raise the cap to 18 months' fees for a strategic counterparty, with a risk note that says exactly that, "raises exposure by 6 months' fees; use only where deal value justifies it, flag to finance." Without that note, the fallback becomes the default the next negotiator reaches for, since nobody wrote down why it costs more.

Step 4: Tag by contract type and jurisdiction, India-correctly

Tags let a negotiator find the right variant fast, and in India, jurisdiction tagging is not a nice-to-have, it is the difference between a clause that holds up and one that quietly does not. Three tags matter most.

Contract type. The same indemnity category might need a different default variant for an NDA (narrow, low-stakes) versus a vendor MSA (broader, tied to deliverables) versus an employment offer (usually absent, replaced by confidentiality and IP terms). Tag each variant by which contract types it is approved for.

Duration and territory, for anything involving IP. An IP assignment variant tagged only "approved" is not enough. Section 19(5) of the Copyright Act, 1957 states plainly: "If the period of assignment is not stated, it shall be deemed to be five years from the date of assignment." Section 19(6) adds: "If the territorial extent of assignment of the rights is not specified, it shall be presumed to extend within India." (Read both on Indian Kanoon.) A library storing one generic "IP assignment" clause without explicitly stating period and territory in the wording itself is storing a clause that, once signed, quietly becomes a five-year, India-only assignment regardless of what anyone intended. Every IP variant needs its own explicit "in perpetuity, worldwide" (or your actual approved terms) written into the clause, not left to a tag alone to fix.

State, for anything stamping-linked. Stamp duty rates and instrument categories differ by state under the Indian Stamp Act, 1899 and the state acts that amend it. A clause allocating who pays and cures stamping should name which state's act applies, since a clause silent on this, or written once and reused nationwide, risks the exact problem Section 35 of the Stamp Act creates: "No instrument chargeable with duty shall be admitted in evidence for any purpose... or... acted upon, registered or authenticated... unless such instrument is duly stamped." (Indian Kanoon.) A clause reused across a different state's contract is not automatically void, but it can leave the document unusable in evidence until someone cures the deficient duty, plus a penalty that can run to ten times the shortfall on a high-value instrument.

Non-compete restraint, tagged during versus after. If your library carries a restrictive-covenant category, the tag that matters most is whether the restraint operates during the relationship or after it ends. Section 27 of the Indian Contract Act, 1872 says: "Every agreement by which any one is restrained from exercising a lawful profession, trade or business of any kind, is to that extent void." (Indian Kanoon.) An in-employment exclusivity variant is a normal, enforceable entry. A post-termination restraint variant is not a fallback, it is something to exclude entirely or mark clearly as unenforceable boilerplate, since storing it as "approved" invites someone to reuse a clause a court will strike out. Our deeper piece on non-compete clauses in India covers the case law, including a 2025 Delhi High Court decision that struck down a post-termination restraint dressed up as "non-solicitation."

Step 5: Assign an owner per category, or the library rots

A clause library with no named owner degrades the way any unowned document does: duplicate variants pile up, nobody is sure which is current, and a clause referencing a repealed section or an old stamp duty figure keeps getting reused because nobody's job is to catch it. Split ownership by category rather than assigning one person the whole library. Whoever is closest to a given risk should own it: finance for payment terms, general counsel or the founder for indemnity and liability, HR or the same counsel for employment-linked restrictive covenants. Set a fixed review cadence, even a simple annual one, and require sign-off whenever the underlying law changes, a court decision shifts a settled position (as happened with non-competes in 2025), or a new fallback is added after a real negotiation.

Step 6: Integrate the library into drafting and negotiation, not just storage

A clause library that lives in a folder nobody opens during a negotiation has failed at the one job it exists to do. Integration means two things. First, whoever drafts a new contract should pull wording from the library by default, not write from memory or copy the nearest old document, the exact habit that created an unowned pile of clauses in the first place. Second, when a counterparty redlines a clause, the person handling it should check the redline against the approved and fallback variants in seconds, decide whether it falls inside the fallback (accept) or outside (escalate), and record which variant was actually used. To test this on a single contract first, mark up a draft clause by clause for free in Weave, Adira's browser-based tool, no library or account required.

Red flags: signs a clause library was built wrong from the start

Normal	Red flag	Why it matters
Ten to fifteen categories covering your highest-volume contract types	Fifty categories added speculatively before the first negotiation used any of them	Breadth without use means nobody has actually tested whether the variants are right
Each variant sourced from a specific, named past contract	Variants written fresh, with no real deal behind the wording	Untested wording looks approved but has never survived a real counterparty
IP assignment variants state period and territory explicitly in the clause text	Variant relies on a "worldwide, perpetual" tag with generic clause text underneath	Section 19(5)-(6) defaults apply to the clause as signed, not to a tag in your system
Non-compete category, if it exists, is limited to in-employment exclusivity	Post-termination restraint stored as an "approved" fallback	Section 27 voids it regardless of how carefully it is drafted or tagged
Stamping-linked clauses are tagged by the state of execution	One stamping clause reused nationwide with no state tag	Rates and instrument categories differ by state; a generic clause can misallocate the cure obligation
Each category has one named owner and a review date	"Legal owns everything," with no individual accountable	Diffuse ownership is how libraries go a year or more without anyone noticing stale wording
Fallback variants are genuinely different from the approved wording	The "fallback" changes one word from the approved clause	Negotiators think they have real room to concede when they do not

A library entry, badly built versus properly built

Badly built (IP assignment category): Tag: "Approved, IP assignment, all contract types." Clause text: "The Contractor hereby assigns to the Company all intellectual property rights in the deliverables created under this Agreement." Usage note: none.

What is wrong: the tag claims broad, permanent ownership, but the clause text is silent on period and territory, so Section 19(5) and 19(6) apply regardless. With no usage note, whoever pulls this entry has no way to know it defaults to five years, India only, until a dispute surfaces the problem years later.

Properly built: Tag: "Approved, IP assignment, contractor and vendor agreements, India-governed." Clause text: "The Contractor hereby irrevocably assigns to the Company, in perpetuity and throughout the world, all right, title and interest, including copyright and all economic rights, in and to the Work Product, including all drafts, source code, documentation and derivative works, whether created before or after the date of this Agreement." Usage note: "Use for contractor and vendor IP assignments governed by Indian law. Do not remove 'in perpetuity and throughout the world', this defeats the Section 19(5) five-year and Section 19(6) India-only defaults. For employee-created work, check Section 17(c) instead." Risk note: "None at approved wording. If a counterparty insists on removing the perpetuity or territory language, escalate; do not accept silently."

What changed: the clause text itself states the terms the statute would otherwise default away, and the usage note tells the next person exactly why those two phrases cannot be quietly dropped during a redline.

How this connects to the rest of your drafting setup

A clause library rarely stands alone. It is the wording layer inside a larger structure: a contract negotiation playbook adds the decision logic, which clause is flexible, how far, who signs off, so a non-lawyer can use the library safely instead of guessing. If you are exploring AI-assisted drafting, a well-tagged library is one of the things that makes a company legal persona actually work, since a drafting tool grounded in a messy, untagged library just reproduces the mess faster.

FAQ

How many clauses does a first clause library need? Fewer than most teams expect. Ten to fifteen categories covering the clauses in almost every commercial contract, indemnity, limitation of liability, confidentiality, termination, governing law, dispute resolution, IP assignment, each with one approved and one fallback variant, covers most negotiations. Depth there matters more than breadth across fifty rarely-used categories.

Should a clause library include unenforceable clauses, like post-termination non-competes, so people know what to avoid? Only tagged clearly as reference material, never as approved or fallback. Storing a void clause next to real fallbacks without a hard warning is how it ends up copied into a live contract.

How is a clause library different from a contract playbook? The library stores wording: approved and fallback text for each clause type. A playbook adds negotiating logic on top: which clauses are flexible, how far, who can approve each level of concession, and where the walk-away line sits. Most functioning teams need both; the playbook is what makes a library safe for a non-lawyer to use unsupervised. See what a contract playbook is for the fuller build.

Can we build a clause library without buying software? Yes, at least at first. A shared spreadsheet with categories, approved and fallback text, usage notes, and a named owner per row is a real clause library, just a manual one. Software mainly adds automatic retrieval at drafting time and consistency once the manual version outgrows a spreadsheet.

Who should review and update the clause library? The named owner for each category, on a fixed schedule, at minimum annually, and immediately whenever a relevant law changes or a court decision shifts a settled position, the way non-compete enforceability shifted with a 2025 Delhi High Court ruling. A library with no scheduled review is the most common reason libraries stop being trusted.

Does a clause library make a contract automatically safe to sign? No. It makes drafting faster and more consistent with your own past decisions; it does not verify that a specific clause is enforceable for a specific deal or counterparty. An "approved" entry reflects your usual position, not a guarantee it survives a dispute.

This guide explains how to structure and govern a clause library, and the specific Indian statutory defaults, on IP assignment period and territory, non-compete enforceability, and stamping, that make careless clause reuse a real legal risk here, not just a filing problem. It does not tell you whether a specific clause in your library, or a contract built from it, is enforceable in your situation. Talk to a lawyer before relying on any clause library, including this guide's examples, in a live negotiation. This is not legal advice.