metadata-only change flagged — the counterparty updated the document author field and the agent reported it as a redline

Not specified by the original author.

TL;DR

The counterparty only updated the document author field, but the agent reported it as a redline. Strip document metadata (author, timestamps, revision counts) before diffing, and compare content only. Report metadata changes separately as non-substantive, never as redlines.

The symptom

metadata-only change flagged  -  the counterparty updated the document author field and the agent reported it as a redline

Steps

1. Confirm the change is metadata-only

Compare the extracted body text of both versions. If the text is identical and only properties like author or last-modified differ, it is metadata-only. Expected: Identical body text; differences confined to document properties.

2. Strip metadata before diffing

Remove or normalize metadata fields (author, created/modified dates, revision numbers) from both files before comparison. Expected: The diff input contains content only.

3. Re-run the diff

Diff the cleaned versions. The change count should drop to zero. Expected: Zero content changes reported.

4. Report metadata separately

Note 'document author updated (metadata, non-substantive)' as an FYI, not a redline. Expected: Reviewers see it without it polluting the redline list.

When to use

• Change list contains author, timestamps, or revision info
• Body text is identical between versions
• The diff tool compares raw files including properties

When not to use

• Body text actually changed (then it is a real redline)
• The metadata itself is disputed (rare; handle explicitly)
• You need an audit trail of metadata (log it, just not as redlines)

Why it happens

File-level diffing sees everything, including the document properties block. An author-field update changes bytes, so it looks like a change. But contract review cares about operative text; metadata edits are administrative noise that drown real redlines.

Edge cases

• Tracked-changes author names: changing the author can reattribute existing markup; check the markup, not just the text.
• Template metadata (company name in properties): note once, not per version.
• Signed PDFs: metadata changes can invalidate signatures; flag that separately.

Provenance

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

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

Thread query: metadata-only change flagged - the counterparty updated the document author field and the agent reported it as a redline

TL;DR: The counterparty only updated the document author field, but the agent reported it as a redline. Strip document metadata (author, timestamps, revision counts) before diffing, and compare content only. Report metadata changes separately as non-substantive, never as redlines.

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 The final version dropped the DRAFT watermark and the agent flagged its removal as a substantive change. Watermarks, stamps, and banners are revision markings, not contract language, so strip them from both versions before diffing. The redline should cover the agreement, not the stationery.

What the bogus change looked like:

- DRAFT (watermark, every page) marked as removed content

Steps

1. Confirm the flagged change is only the watermark. Check whether the diff's watermark entries correspond to any actual clause text. Command: inspect the flagged regions and verify they contain only the watermark text with no clause language. Expected: every watermark flag is pure marking, no operative text involved.

2. Add a pre-diff cleanup pass that removes watermarks, stamps, and banner text from both versions: drop diagonal or background watermark text layers, and strip repeated header and footer strings. Expected: re-running the diff no longer mentions the watermark at all.

3. Keep a separate revision-markings report: record which markings each version carried, like DRAFT on v3 and none on v4, as metadata rather than diff content. Expected: the redline summary covers clause changes, with a one-line note that the DRAFT watermark was removed in the final.

4. Generalize the cleanup to other markings your pipeline will meet: CONFIDENTIAL banners, page stamps, and Bates numbers. Expected: future draft-to-final comparisons stay clean regardless of which markings change.

Use this when

• Draft-to-final comparisons flag watermark or stamp removal as changes
• Diffs include header, footer, or banner text that is not part of the agreement
• The counterparty's versions carry different revision markings
• Your redline change list is polluted with non-clause differences

Not for this skill when

• The marking is part of the executed agreement, like a notary stamp on the signature page, which deserves its own handling
• Watermark text overlaps clause text in a scanned PDF, clean the image rather than the text
• You need a forensically complete diff, keep the raw diff archived
• The only difference between versions genuinely is the watermark, then say so plainly

Variant phrasings

• agent flagged DRAFT watermark removal as a substantive change
• how to exclude watermarks from contract diffs
• redline showing watermark differences instead of real edits
• draft to final comparison polluted by revision markings
• strip headers footers and watermarks before diffing contracts

Why it happens

Watermarks and stamps live in the document as text or image layers, so a naive diff sees "DRAFT" present in one version and absent in the other and reports it like any other deletion. The diff has no concept of document furniture versus operative language, so revision markings get the same weight as a changed indemnity cap. Humans instantly discount the watermark; the agent needs to be taught to.

Edge cases

• A watermark that obscures clause text in a scan is a readability problem, flag the obscured region rather than silently stripping it.
• Bates numbers change on every page of every version, always exclude them or they will dominate the diff.
• Some stamps carry dates, like a received stamp, which can matter for timing disputes, log stamp metadata even while excluding it from the clause diff.
• Headers containing the agreement title may legitimately change if the title changed, compare header text as metadata before stripping.
• If the final version should NOT have lost its watermark, like a confidential draft that went out unmarked, that is a process failure worth escalating, not diff noise.

Provenance

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

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

Thread query: agent flagged the "DRAFT" watermark removal as a substantive change in the final version

TL;DR: