Tracked Changes and the Comment That Must Not Ship
A contract draft goes through three reviewers using tracked changes. Reviewer A deletes a liability clause and adds a replacement. Reviewer B accepts A's deletion but rejects the replacement, then adds a comment asking legal to confirm. Reviewer C replies to B's comment and inserts a new clause. You must produce two outputs: (1) a clean version for the client, and (2) a redline showing every change against the original. The client must not see internal comments.
1. Describe the correct sequence to produce the clean client version without losing the ability to make the redline.
Read the worked answer
Save a copy first, then work on the copy.
- Keep the original with all markup untouched as the source for the redline.
- On a copy, accept or reject each change deliberately - do not use "accept all" blindly, because B rejected A's replacement, so the correct clean text is the original clause deleted and no replacement. Accepting all would wrongly include the replacement.
- Delete all comments (including B's and C's thread) before export - comments are internal and must not reach the client.
- Turn off track changes so no further edits are recorded.
The trap is treating "clean" as "accept everything". Clean means the agreed state, which here includes a rejection.
2. How do you produce the redline against the original, given that the working copy now has all changes accepted?
Read the worked answer
Use the compare documents function: compare the clean client version against the untouched original, and have the tool generate the markup.
Reasoning: once you have accepted/rejected, the tracked-changes history is gone from the working copy. You cannot "un-accept" to get the redline back. Comparing the final clean text to the original reconstructs a redline showing exactly what changed between the two states - which is also the more honest redline, because it reflects the agreed outcome rather than the messy review history.
Note the redline will show the net effect: A's deletion and B's rejection of the replacement collapse into "clause deleted", which is correct for the client.
3. Reviewer C inserted a new clause after B's comment. What is the risk to the clean version if you delete comments before resolving the thread?
Read the worked answer
Deleting comments does not delete the clause C inserted, so the text risk is low - but the decision risk is real. B's comment asked legal to confirm; if you strip comments before that confirmation is recorded, the clean version ships a clause whose approval is undocumented, and the audit trail is lost.
The safe order is: resolve the substance first (confirm the clause with legal, record the outcome), then delete comments for the client copy. Keep the commented copy as the internal record. Deleting comments is a publication step, not a review step, and should be the last thing done on the client copy - after the redline source is secured.