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

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.

1. 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.

1. 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.

1. 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.

1. 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