Review an AI writing assistant with an edit-decision ledger

Freeze the source and ask for bounded edits

Imagine a synthetic customer-operations team revising a service update. The approved source note says an outage affected one reporting export between 09:10 and 10:05, that queued jobs were replayed, and that the team is still checking whether every export completed. An assistant proposes: “All affected exports were restored, and no data was lost.” The second clause was never established. The first overstates an incomplete check. Both can slip through if the reviewer reads only for tone.

Save the approved source note and the starting draft as named versions. Tell the assistant the intended audience and editing task: improve clarity and structure while leaving unresolved results explicitly unresolved. Give it the specific non-sensitive materials it may use. Ask it to flag proposed factual additions rather than quietly insert them. The resulting text is a candidate revision, not an approved service statement. A human owner must decide whether each substantive change belongs in the final document.

Microsoft's current Copilot in Word guidance describes drafting, rewriting, and reviewing suggested edits, and warns users to verify facts, numbers, citations, names, and policy statements. Available behavior depends on license, organization settings, app version, and platform. Its Word tracked-changes guidance explains that reviewers can accept or reject individual edits; merely hiding markup does not remove it. These are examples of one product's documented controls, not a promise that another assistant captures the same edit trail or that a tenant has every feature enabled.

Sources: [1] [2]

Record the decision behind each meaningful revision

Use four ledger columns: proposed edit, reason, evidence check, and disposition. For the synthetic service update, one row reads: edit = “all exports restored”; reason = make the opening reassuring; check = replay log confirms 87 queued jobs retried, but completion reconciliation is still open; disposition = reject the absolute claim and write “queued jobs were replayed; we are checking completion.” A second row reads: edit = “no data was lost”; check = no data-integrity review is complete; disposition = remove the claim and add an owner and expected next update. A third row may be stylistic: replace a long passive sentence with a shorter active one without changing its meaning; disposition = accept after checking that the service owner remains correctly named.

This is an original operational ledger, not a built-in feature claimed for Word or any other product. It makes a difference between grammatical polish and an evidence-changing edit. The reviewer should pay special attention to shifts in certainty, scope, dates, responsible party, and promised next steps. When a draft draws from a file or meeting, identify exactly which version was used. If the assistant inserts a citation or link, open the original and confirm that it supports the sentence. A plausible source title is not a completed verification step.

Release a document whose history can be explained

Before sharing, compare the final text against the starting version and the ledger. Confirm that every changed number and status has a corresponding check, unresolved items still read as unresolved, and sensitive details were not added by accident. In an editor with tracked changes, accept or reject outstanding revisions deliberately; hiding the markup is not an approval workflow. Preserve the approved final version separately from prompts and exploratory drafts under the team's normal records practice. If the source status changes, reopen the rows that depended on it rather than rewriting the whole document from memory.

A concise release note can state who approved the text, which source versions were checked, and which claims remain open. That is more useful than a generic “AI reviewed” label. The ledger makes consequential edits inspectable and correctable, while accuracy still depends on the underlying evidence and human review. In a Two Prune assessment, a participant can demonstrate this task-bounded verification on synthetic material, with the resulting evidence interpreted by a person. Two Prune does not run the customer's writing system or make automated employment decisions.