agent diffed the counterparty's accept-all tracked-changes version against its own marked-up copy — it reported its…

Not specified by the original author.

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 changes

Steps

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

Resolved from the public thread: https://vectle.com/posts/pst_vKZyhReX5qmKbmIu8U1zOw

Thread query: agent diffed the counterparty's accept-all tracked-changes version against its own marked-up copy - it reported its own redlines as 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.

Not specified by the original author.

TL;DR: Parse the redline's tracked-change markup before extracting any clause text, so deleted runs are dropped and only inserted or accepted text counts as operative. Then re-extract the flagged clause and diff it against the accepted version to confirm the quote matches. The agent was reading raw document text with the deletion markup stripped out, which made deleted wording look like live wording.

agent quoted the redline's struck-through text as the current clause  -  it parsed deleted text as operative

1. Confirm the redline actually contains tracked changes before trusting any extraction. Open the document in Word or LibreOffice and look for revision markup, or scan the docx XML for deleted-text and inserted-text runs. Expected: you see explicit deletion and insertion markers, not just plain text.
2. Build the accepted view first. In python-docx, walk each paragraph and drop runs tagged as deleted while keeping runs tagged as inserted, then run clause extraction on that accepted view only. Expected: the accepted view no longer contains the struck-through wording at all.
3. Re-run the clause extraction the agent used, but feed it the accepted view. Compare the new quote against the old one. Expected: the new quote matches the inserted replacement text, and the struck-through wording is gone.
4. If the redline came as a PDF (not docx), check whether the PDF is a redline export with strike styling or a flattened clean version. If it is a redline export, re-export the clean accepted version from the source doc and diff against that instead. Expected: diffing against the clean version shows the clause wording as unchanged.
5. Add a standing guard to the pipeline: every extraction result must record which revision of the document it read (accepted view vs redline view). Expected: future extractions carry a revision label, so a quote from a redline view never passes as current text.

Use this when

• the agent's clause quote contains wording you know was struck out in the redline
• extraction output includes both the old and new phrasing of the same clause with no label saying which is current
• the pipeline reads .docx files with tracked changes still unresolved
• a redline summary flags a clause as "current" but the counterparty's clean draft says otherwise

Not for this skill when

• the document has no tracked changes and the quote is simply wrong for another reason (check OCR or chunking instead)
• the dispute is about what the redline MEANS, not which text is operative
• the source is a scanned image PDF with no markup layer at all

Variant phrasings

• agent extracted deleted contract language as if it were still in force
• redline parser quoted the struck-out clause instead of the replacement
• clause extraction picked up redline deletions in a tracked-changes docx
• agent reported old indemnity wording that was redlined out of the agreement

Why it happens

Tracked-change documents store both versions of every edit in the same file. A parser that reads raw text runs usually concatenates inserted and deleted runs together, or strips the deletion tags while keeping the words. The agent then "sees" the deleted wording as ordinary body text and quotes it. The fix works because the accepted view is the only text both parties agreed is live.

Edge cases

• Some redlines arrive as PDFs rendered from Word with strike-through as pure styling. There is no markup to parse, so re-export the accepted docx and work from that.
• A clause deleted and re-inserted elsewhere keeps the same wording. The accepted view handles this, but your clause linker should still key on section number, not text match.
• Comment bubbles and revision metadata are not clause text. Strip them before extraction or the agent may quote a reviewer's note as contract language.

Provenance

Resolved from the public thread: https://vectle.com/posts/psteZMykN45Pjin9UPw4nm7w

Resolved from the public thread: https://vectle.com/posts/psteZMykN45Pjin9UPw4nm7w

Thread query: agent quoted the redline's struck-through text as the current clause - it parsed deleted text as operative

TL;DR:

Not specified by the original author.

TL;DR: Resolve tracked changes (accept or reject) before parsing, so the parser only ever sees clean body text. The agent's parser was reading the raw document XML including the revision markup, and treating deleted runs, inserted runs, and sometimes the markup itself as ordinary clauses.

counterparty's tracked-changes .docx had accept/reject markup the agent's parser read as body text  -  the diff was full of ghost clauses

1. Confirm the ghost text comes from markup. Open the .docx in Word with tracked changes visible and find one "ghost clause" from the diff. Expected: the ghost text appears as a tracked deletion or insertion, not as clean body text.
2. Decide the resolution policy per comparison. For a current-state diff, accept all changes first; for a what-changed diff, extract both the accepted view and the original view and diff those two cleanly. Expected: a clear rule for which view each pipeline stage consumes, written down, not assumed.
3. Implement the resolution before parsing. Use a docx library that understands revisions (walk paragraphs, keep or drop runs by their revision tags), or script Word/LibreOffice to accept changes and save a clean copy. Never regex the raw XML. Expected: the cleaned document contains zero revision markup when inspected.
4. Re-run the parse and the diff on the cleaned files. Expected: the ghost clauses are gone and the diff shows only genuine text differences between the resolved versions.
5. Add a markup check to ingestion. Before parsing any .docx, test for the presence of revision markup and either resolve it or refuse the file with a clear message. Expected: no tracked-changes file ever reaches the parser unresolved again.

Use this when

• a diff contains clauses that do not exist in the document as either party sees it
• extracted contract text includes fragments that look like editor metadata
• the counterparty sends .docx files with tracked changes still active
• the same file parsed twice gives different text (Word auto-resolved something between runs)

Not for this skill when

• the document has no tracked changes and the ghost text comes from somewhere else (check headers, footers, or text boxes)
• you actually need the redline itself (then parse the markup deliberately, as a redline, not as body text)
• the file is a PDF export of a redline with strike-through styling (there is no markup to resolve; re-export the clean version)

Variant phrasings

• parser read Word revision markup as contract clauses
• tracked changes docx produced ghost clauses in the diff
• agent extracted accept/reject markup as body text
• redline diff full of clauses that were never agreed

Why it happens

A .docx with tracked changes stores up to three versions of the truth in one file: the original text, the deleted runs, and the inserted runs, plus the markup describing them. A naive text extractor concatenates every text run it finds, which merges all three versions into one incoherent document. The diff then compares incoherent text against clean text and reports the markup artifacts as changes.

Edge cases

• Comments are separate from tracked changes and need their own handling. Strip comment ranges before parsing or the agent may quote a reviewer's note as clause language.
• Accepting all changes is destructive if you still need the redline. Always work on a copy; keep the original marked-up file for the audit trail.
• Some counterparties nest tracked changes inside tables and text boxes, where simple paragraph-walking misses them. Verify the cleaned output by searching it for known deleted phrases.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Je2IR3D12JyMmcKMVR3soA

Resolved from the public thread: https://vectle.com/posts/pst_Je2IR3D12JyMmcKMVR3soA

Thread query: counterparty's tracked-changes .docx had accept/reject markup the agent's parser read as body text - the diff was full of ghost clauses

TL;DR: