Skip to main content

Clause library

What this page is — the shared store of approved wording that templates insert, each clause carrying a risk level and an ordered list of fallback positions your organisation is willing to accept.

What it is for — so a clause is written and approved once, every template using it stays current, and negotiators know what they may concede before a redline arrives.

The problem it solves — the same clause is rewritten in every template, versions diverge, and negotiators concede positions legal never approved.

Route: /org/papers/designer → Clause Library · Permissions: View this project's clause library. / .manage for project clauses; View the org-canonical clause library. / .manage for org-wide clauses.

Figure 1 — Each card is one clause, with the policy governing whether it may be changed.

1. What it is​

A clause is metadata plus versions:

PartHoldsChanges by
ClauseTitle, category, tags, risk levelEditing the card
VersionThe body (rich text, may contain {{field}} tokens) and the fallback positionsSaving creates a draft version
Approved versionThe one templates renderApprove — and it is then immutable

Risk level is the setting that does the most work, and it does not mean what it sounds like:

Risk levelMeansEffect
standard (default)Normal wording—
negotiableExpected to move in negotiationInforms redline grading
do_not_alterLegal has locked the positionA counterparty change touching it is a material change and re-triggers approval

do_not_alter does not stop your own team editing the clause. It governs what happens when the counterparty changes it.

2. Why you would use it​

  • One update, every template. The same liability paragraph pasted into eleven templates is eleven updates; inserted from the library it is one approval.
  • Legal reviews wording once. Nothing reaches a template without being approved.
  • Negotiators get pre-authorised concessions. Fallback positions are what Redline grade measures counterparty proposals against — so "can I accept 18 months?" has an answer.
  • Locked positions protect themselves. A counterparty edit to a do_not_alter clause sends the document back through approval automatically.

3. How it spreads​

SurfaceReads
Template Clause blocksThe current approved body
Redline gradeStandard body, risk level and ordered fallbacks
Counterparty suggestionsRisk level — material-change detection
Every unsealed document using the clauseThe approved body, at render time

4. Step by step​

  1. New Clause → title, category, risk level, body, fallbacks → Create Clause. It is a draft, pending approval.
  2. Approve on the card → confirm. The latest draft becomes the approved, immutable version.
  3. Insert it from a template with a Clause block.
  4. To change wording: Edit → Save Clause creates a new draft. The approved text keeps serving until you Approve again.

5. Field reference​

FieldRequiredRulesRefusal
TitleYes—title is required
CategoryNoBrowsing and search label—
Risk levelDefaults to standardstandard, negotiable, do_not_alterinvalid risk_level "x"
Clause body—Rich text; {{field}} tokens merge each document's values; dictation and read aloud—
Fallback positionsNoOrdered, most preferred first — position 0 is the smallest concession. Reorder with arrows—
Card statusMeans
approved (green)An approved version exists; templates render it
pending approval (yellow)Only a draft exists; Clause blocks render empty
Org-wideShared across projects

Search clauses filters by title and category on the server.

6. Worked example​

A general counsel creates Limitation of Liability.

FieldValue
CategoryLiability
Risk levelnegotiable
Body"Each party's aggregate liability shall not exceed the fees paid in the 12 months preceding the claim, excluding breaches of confidentiality and IP infringement."
Fallback 018 months of fees, same carve-outs
Fallback 124 months of fees for data-breach claims only (super-cap)

They approve it. Four templates insert it with Clause blocks.

Six weeks later a counterparty proposes "liability capped at 18 months' fees". Redline grade returns within_playbook: true, matched_fallback_index: 0 — the reviewer accepts without escalating.

In March, legal tightens the carve-outs. Counsel Edits — a new draft — and the approved 12-month text keeps rendering meanwhile. On Approve, every unsealed document using the clause renders the new wording at once; the 40 already-sealed agreements keep what their signers saw.

7. The admin contract​

Must be trueWhereWhat breaks without it
Every inserted clause is approvedThis tabClause blocks render empty
Fallback positions are definedThis tabEvery concession grades out-of-playbook in Redline grade
Risk level is set honestlyThis tabLocked positions change without re-approval
The role holds Create/edit/approve project clauses and fallbacks.Role editorNo New, Edit or Approve
Org-wide clauses need the org permissionRole editorProjects can read but not change them

8. Downstream​

When you…Then
Approve a new versionEvery unsealed document using it renders the new text; sealed PDFs do not change
Save an editNothing visible changes until it is approved
Mark a clause do_not_alterCounterparty changes to it re-trigger approval
Change fallbacksRedline grade uses them from the next grading

9. Don't confuse this with…​

Template builderA template's own wording. It inserts clauses
The type's redline playbookJSON on the AI Config tab — used only by the Compromise drafter, not Redline grade
Suggest clauses (Drafting AI)Proposes new wording. A library clause is wording already approved
Locked Clause blocksMark one insertion do-not-alter. Risk level marks the clause everywhere

10. Troubleshooting​

SymptomCause
A clause renders blank in a documentIt has never been approved
An edit is not liveEdits are drafts until approved
A clause changed on documents nobody touchedA new version was approved
Everything grades out-of-playbookNo fallback positions on that clause
do_not_alter did not stop an internal editIt governs counterparty changes, not your team's
Edit is missingYour role lacks Create/edit/approve project clauses and fallbacks.