The suggested edit lands as clean text and the revision history is gone

The counterparty opens the document and sees a contract. Not a marked-up contract, and not a proposal — a contract, whose wording differs from the one they sent in ways they now have to find themselves. Nothing can be accepted, nothing can be rejected, and there is no record of who changed what. In a negotiation this is worse than sending nothing, because it reads as an attempt to slip language through.

This is almost always a document-handling defect rather than a drafting one. The proposed wording is often fine. The pipeline simply produced a new file instead of editing the one it was given, and the revision record was never created because there was never anything to record it against.

Open the returned package before you touch a prompt

The file carries the diagnosis. An Office Open XML document — the .docx family — is a ZIP package holding XML parts, so the check needs no special tooling and takes about 1 minute per file.

1. Copy the returned file, rename the copy to end in .zip, and open it. The main body part is 1 XML file inside the package, and a text editor is enough for every step below.
2. Search for the insertion and deletion elements. In WordprocessingML, published as ISO/IEC 29500, an inserted run is wrapped in a w:ins element and a deleted run in w:del. Zero matches means no change was tracked at all, whatever the document looks like on screen.
3. Check that each revision carries its attributes. Both wrappers take an author, a date and an identifier — w:author, w:date and w:id. A revision with an empty author is visible but unattributable, which most firms treat as unusable.
4. Look for deleted text specifically. Removed wording is preserved in a deletion-specific text element rather than the ordinary one, so if the previous language is nowhere in the file, the edit was destructive and cannot be rejected.
5. Count the comment anchors and compare against what you sent. Comments live in a separate part with start and end anchors into the body, so they are lost independently of the text and nobody notices until the thread is needed.
6. Compare the body against the original for things nobody edited. Reset numbering, lost headers, changed styles and reordered schedules all point at a rebuild rather than an edit, and they are the loudest signal in the file.

What a tracked change actually is inside the file

A tracked change is not a colour and not a formatting state. It is structure: the inserted content sits inside an insertion element, the removed content stays in the file inside a deletion element, and each carries the author and timestamp that make it attributable. Accepting a change means unwrapping the insertion and discarding the deletion; rejecting it means the reverse. Both operations are only possible because the old and new text are present at the same time.

That has 3 consequences worth designing around. A pipeline that emits final text has thrown away half the information the format requires. A pipeline that deletes text outright has removed the thing the other side would reject. And a pipeline that writes revisions without an author has produced changes that the receiving firm cannot audit, which matters if anyone later has to reconstruct who proposed what — the record set discussed in what a system must hold to reproduce an assisted output.

5 ways an edit arrives as ordinary prose

Match the row against what the package showed. The first 2 are architectural and are the reason a prompt change never helps; the last 3 are implementation details in the writing step and are usually a day of work each.

The conversion that quietly eats the comments

The intermediate-format route is popular because it makes the model's job easy: convert to plain text, edit the text, convert back. It is also the single most destructive thing you can do to a negotiated document. Comments, revisions from earlier rounds, cross-reference fields, numbering definitions and schedule ordering are 5 kinds of structure, and structure is exactly what a Markdown or HTML conversion is designed to discard.

The damage compounds on executed and heavily amended paper, where numbering is already fragile before anything automated touches it — the pathologies isolated in extraction that falls apart on the signed conformed copy. A round trip on a clean draft loses a comment thread. The same round trip on a conformed copy with 3 appended schedules can silently reorder them.

Accepting and rejecting a change is only possible because the old and new wording are both present. A pipeline that emits final text has already thrown away the half that makes it a negotiation.

An unattributed revision is one the other side will not act on

Where revisions are written correctly but carry a blank or machine-generated author, the file is technically valid and practically unusable. A reviewer on the receiving side works by author: accept everything from their own counsel, read everything from the counterparty, treat anything unattributed as suspect. A revision with no author defeats that entirely, and a document where all 40 changes carry the same timestamp to the second announces that they were not made by a person.

• Agree the external author name before the first document goes out. Most firms use the firm or the responsible lawyer, and changing it midway through a negotiation makes the earlier rounds look tampered with.
• Keep the timestamps honest rather than uniform. If every revision shares one instant, say so in the covering note instead of letting the file imply a human sat there.
• Never merge machine and human revisions under a single author. The lawyer's judgement and the system's suggestion are different objects and the receiving side is entitled to tell them apart.
• Preserve revisions from earlier rounds. Dropping the counterparty's own tracked changes while adding yours is the fastest way to lose the negotiation's memory.

Edit the file you were sent, or send a different artefact entirely

There are exactly 2 defensible architectures and the failure above is what happens when a team ends up between them. The first is in-place editing: the delivered package is opened, revisions are written into it, and it is returned as the same document with history intact. The second is not to send a document at all — produce a written list of positions instead, which is a legitimate output with different readers, weighed in a summary of deviations against a marked-up draft.

Generation from scratch is a third operation and it belongs to a different moment in the deal: producing a first draft from agreed heads of terms, where there is no counterparty document to preserve, is the workflow in from an agreed term sheet to a first draft. The mistake is using a generator where a document was sent to you, and then presenting the output as a markup.

Whichever route you take, make the check above part of the pipeline rather than part of someone's memory: assert on every returned file that revision elements exist, that each carries an author and a date, and that the comment count matches the input. That assertion is 20 lines of code, it fails loudly, and it is the difference between a document tool and a document risk. Building that kind of guarded pipeline is ordinary MVP and product engineering, and it sits with the rest of contract review, clause risk and redlining in the work we do with legal teams.

• redlining
• tracked changes
• document pipelines
• diagnosis