A source-traceable workflow for reviewing contract redlines

Pin the versions before comparing them

Start by naming the two files, the sender, the received time, and the version each side believes is current. Preserve the originals. A comparison is only useful when everyone can tell which document was the baseline and which document introduced the change.

This version record prevents a quiet but expensive failure: reviewing the right language in the wrong draft. It also gives later reviewers a reliable chain when negotiations move through several filenames and email threads.

• Keep immutable copies of both source files.
• Record the direction of comparison: baseline to proposed draft.
• Name the business owner and current reviewer.
• Do not infer version order from filenames alone.

Separate substantive change from document noise

Tracked changes can mix meaningful edits with numbering shifts, formatting corrections, moved text, and repeated changes to the same phrase. Group changes by the clause they affect, then distinguish edits that alter the apparent business position from edits that only change presentation.

This is triage, not a legal conclusion. The purpose is to give qualified reviewers a smaller and more coherent set of changes to inspect while keeping the full source available.

• Group related insertions and deletions into one clause-level change.
• Preserve the unchanged context around each edit.
• Mark moved language separately from newly introduced language.
• Keep uncertain changes in the review queue.

Re-run the playbook comparison on changed clauses

A clause that matched the playbook in the prior draft may no longer match after a small edit. Compare the resulting clause—not only the visible redline—to the approved playbook position. Then show the old language, the new language, the relevant playbook rule, and any earlier decision side by side.

This keeps the review from resetting with every draft. The team can distinguish a newly introduced issue from a previously accepted exception and can route the decision to the right owner.

• Recheck the full resulting sentence or section.
• Carry forward prior decisions with their scope and approver.
• Do not assume an accepted exception applies to a materially different revision.
• Keep approved fallback language linked to its source record.

Write questions around decisions, not edits

A redline note such as “changed termination” describes the document but does not tell counsel what the business needs. A better question identifies the new language, the operational scenario it affects, the playbook position, and the choice that remains open.

The same structure helps business owners. They can see whether an issue needs legal interpretation, commercial approval, operational confirmation, or a combination of the three.

• What changed in the source language?
• What business workflow or commitment does it touch?
• Which playbook expectation or prior decision is relevant?
• Who must make the next decision?

Make the next draft prove the decision was applied

Close each review cycle with a decision record and a next-draft check. The packet should show the prioritized changes, source excerpts from both versions, open questions, accepted exceptions, fallback language, and the owner of each follow-up.

CounselOS keeps source spans, clause extracts, playbook deviations, questions, and packet notes connected end to end. When the next draft arrives, the review can start from the decisions already made instead of rebuilding context from memory.