Contract versions and who agreed to what

The situation

A contract is drafted, reviewed by legal, negotiated with the counterparty, approved internally and signed. It has renewal and notice dates that matter, clauses that vary by jurisdiction, and a filing requirement. Today the drafts are files, the approvals are email, and the renewal date is in somebody’s calendar.

These are illustrative scenarios showing how the products are used, not customer case studies.

What gets modeled

The structure as it would actually be defined — sections that repeat are marked.

How it gets built

In the order somebody would actually do it. Each step names the capability it rests on, so it can be checked against the product pages.

1. 1

   Model the contract, clause by clause

   Clauses repeat, and each one records whether it deviates from the standard — which is the field the approval routing will read. The counterparty section is defined once and reused, so the same organization is not described three different ways.

   What it uses: Repeating sections, and reusable sections shared across record types

2. 2

   Point the clause types at the library legal owns

   Clause type reads live from the clause library rather than a list copied into the form. Legal adds a clause type in one place and it is available on the next read, with a long list loading as you type.

   What it uses: Live option sources with search-as-you-type

3. 3

   Turn on history before the first draft

   History is enabled on the contract schema, so every write keeps a snapshot to the depth you choose, and any retained point can be restored — with the restore itself recorded. This is the step that decides, a year ahead, whether the question of which version was agreed is a lookup or an argument.

   What it uses: Snapshot per write, restore to any retained point

4. 4

   Route by what the contract actually says

   A step reads the contract mid-run: a deviation from the standard clause set takes the legal path, everything else takes the fast one. A malformed condition does not fall back to a best guess. It refuses to match, and the run stops for someone to look at.

   What it uses: A step that reads the record mid-run, with conditional links

5. 5

   Approve it in a way that survives a dispute

   Internal approval is a human decision step that asks the approver to re-authenticate at the moment of signing and to pick a reason from your own codes. Once recorded, the decision cannot be edited. Each signature is chained to the one before it, so a later alteration shows.

   What it uses: Re-authenticated, chained signatures with reason codes

6. 6

   Hold the counterparty step open properly

   Sending for counterparty signature hands work to an external service and parks with a deadline rather than polling. The service posts its result back, authenticated with a token issued for that run, and a worker restart resumes the run rather than losing track of what is outstanding.

   What it uses: Callback steps with a deadline, and run state held in the database

7. 7

   Put the renewal on a schedule, not in a calendar

   A scheduled workflow reads contracts approaching their notice date and starts a review run. If that schedule stops firing you hear about it from a notification, at a point where the notice window is still open. The alternative is finding out because the contract already renewed.

   What it uses: Schedule triggers, with alerting on failure and stalled runs

8. 8

   Answer the question a year later

   The version history, the signatures and the run history are all attached to the contract. Which version was agreed, who approved the clause that deviated, and whether anything moved afterwards are read off the record rather than assembled from mailboxes.

   What it uses: Record history alongside per-step run history

Numbers used above, and where they come from

Every figure on this site is counted from the product itself. Nothing here is a performance or customer claim, because there is no measurement to cite for one.