Contract changes: when to customize a model to categorize them

A highlighted difference and its place in the review

A client sends a contract back after edits. The version for agreement says „Report delivered monthly”, and the version after comments says „Report delivered weekly”. Elsewhere only the line breaks of a paragraph changed. The comparison marks both places, and the coordinator has to decide whom to pass each of them to.

The model gives the first change the category of reporting obligations, and the second the category of formatting changes. The coordinator sees both passages side by side, checks the category and sends the substantive change to the right reviewer, without passing on the whole list. When the meaning of the new wording depends on a cross-reference to another clause, the category stays unresolved, and the view lets you go back to the documents.

What a simpler change gives, and what training adds

In this count, agreed category definitions give most of the effect for a fraction of the cost. Training makes sense at a larger scale or when the remaining errors are expensive. We keep the meaning of a category apart from the reviewer's name: a change of responsibilities in the team needs an updated assignment, with no retraining of the model.

The set of training examples has to be maintained: when the process, the naming or the base model changes, the evaluation is repeated on the same test set. We put that cost in the quote together with the training itself.

Start with text comparison

If the team mainly needs to find the changed places, start with the tool you have: Microsoft Word compares two documents and shows the differences in a third document. Contract management systems also compare clauses semantically, as the Conga documentation describes. Categorising is separate work, needed when there are many marked passages and the team sorts them by the same topics. Before adaptation, the company's experts agree what „an editorial change” means, because for one person it is the layout of the text, and for another also a new wording.

What to discuss before fine-tuning for contract changes

Fine-tuning needs changes between two versions with a category confirmed by an expert; an „accepted” comment from old negotiations does not explain the kind of change. We run the comparison on pairs of versions not used for adaptation. The scope of the contract workflow is described on the AI for contracts page. We adapt models as part of our private LLMs, and we build the app where an employee sees the result next to its source as part of our AI apps. For the free analysis, a few examples of an error that keeps coming back and a note of who corrects it today are enough.