Writing native Word revisions from a web task pane without corrupting styles

A redline that is not a tracked change is a screenshot with extra steps. Lawyers negotiate in Word; the counterparty expects a document they can accept, reject and comment on clause by clause. Any product that delivers suggested edits as a web list has handed the retyping back to the associate.

So LexCore's redline download builds a native .docx where every change is pre-anchored as a standard Word tracked change. Getting there is where the engineering is.

Problem one: the anchor

A suggested edit is produced against text. A tracked change has to be applied to a position in a document model — a run, inside a paragraph, inside a body, with the surrounding formatting intact. The gap between those two is the whole problem, and it is the same gap CitationGate already solves for findings: an edit that cannot be located verbatim in the source cannot be anchored, and an edit that cannot be anchored is not offered.

This is why the grounding discipline is shared rather than bolted on. A redline suggestion inherits the same verification as a review finding, so an edit ties back to the clause it changes.

Problem two: runs do not respect sentences

Word splits a paragraph into runs on formatting boundaries, not on meaning. A single sentence can be four runs because someone bolded two words and the spell-checker touched a third. An edit that spans those runs has to be split across them, and each fragment has to carry the formatting of the run it lands in — otherwise the accepted result silently loses the bold, or worse, inherits it across the whole sentence.

Problem three: everything numbered

• Numbering and list definitions live outside the paragraph that uses them. Insert a paragraph without attaching it to the right numbering definition and clause 4.2 becomes clause 1.
• Cross-references are fields pointing at bookmarks. Delete text containing a bookmark and every reference to it resolves to an error on the next update.
• Style inheritance means a paragraph's appearance is mostly not in the paragraph. Copying formatting literally, rather than by style reference, produces a document that stops responding to the firm's template.

Why this belongs in a document engine, not in the model

None of the above is a reasoning problem. It is a file-format problem with a correct answer, and correct answers belong in deterministic code that can be tested against real documents. The model proposes the edit and the rationale; the document engine is responsible for the fact that the resulting file opens cleanly in Word and behaves like a document a colleague marked up.

The test that matters is not whether the .docx parses. It is whether a partner can open it, accept half the changes, and send it to the counterparty without opening the style pane.