agent diffed the counterparty's accept-all tracked-changes version against its own marked-up copy - it reported its...
Fixes the agent diffing the wrong pair of documents and reporting its own redlines as counterparty changes. Use when the change list contains edits your side made. Covers version provenance labeling, always diffing counterparty-new against the last agreed baseline, and a sanity check against the counterparty's change summary. Not for genuine counterparty changes.
TL;DR
The agent compared the counterparty's file against your own working copy, so your redlines showed up as their changes. Label every version with its provenance (ours vs theirs, which round), and always diff their latest against the last mutually agreed version, never against your working copy. Sanity-check the count against their change summary.
The symptom
agent diffed the counterparty's accept-all tracked-changes version against its own marked-up copy - it reported its own redlines as counterparty changesSteps
1. Label every version with provenance
For each file, record: whose version (us / counterparty), which round, and what it is based on. The accept-all file is counterparty round N; your marked-up copy is our working draft and must never be a diff baseline. Expected: Every file has an unambiguous provenance label.
2. Pick the right baseline
The baseline is the last version both sides agreed on (usually their previous round, or the clean execution draft). Diff counterparty-round-N against that baseline. Expected: The diff input pair is (agreed baseline, counterparty latest).
3. Run the diff on the correct pair
Re-run the comparison. Your own redlines should vanish from the change list because they are not in either side of the correct pair. Expected: Change list contains only counterparty edits.
4. Sanity-check against their change summary
Compare the diff count to the counterparty's stated changes ('we accepted all and changed clauses 3 and 8'). A large unexplained gap means the pair is still wrong. Expected: Diff count roughly matches their summary; big gaps trigger a recheck, not a report.
When to use
- The change list contains edits your own side made
- The counterparty's file was compared against your working copy
- Change counts far exceed what the counterparty said they changed
When not to use
- The changes are genuinely theirs (verify provenance before assuming)
- There is no agreed baseline yet (first round: diff against the original draft)
- Tracked changes were not accepted cleanly (fix the accept-all step first)
Why it happens
Diff tooling compares two files; it cannot know which pair is meaningful. When the agent grabs 'the latest file' for each side, your working copy (full of your redlines) becomes the baseline, and every one of your edits appears as a counterparty change. Provenance labeling makes the correct pair explicit.
Edge cases
- Accept-all artifacts: make sure 'accept all changes' actually produced a clean file; leftover markup pollutes the diff.
- Parallel redlines (both sides editing at once): diff each side against the common baseline separately.
- PDF vs docx round-trips: convert both sides to the same format before diffing.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_vKZyhReX5qmKbmIu8U1zOw