How to develop and assess document comparison in AI-enabled work

Establish the comparison basis

GOV.UK's open standard for sharing and collaborating with government documents emphasizes version updates, the ability to compare versions, interoperability, and audit trails. The current UK Lawmaker release guidance describes a comparison flow that asks the user to select the original document and the revised version. Both point to a practical principle: a comparison is an evidence artifact with identifiable inputs, not an untraceable summary.

Before comparing documents, record:

If version identity is uncertain, stop and resolve it. A detailed comparison of the wrong pair can be accurate and still useless.

• the exact files, versions, dates, and approval states;
• whether the task is a redline, policy-impact review, requirement reconciliation, or completeness check;
• the baseline and comparison direction;
• sections that are in or out of scope;
• how moved text, renumbering, tables, annexes, and embedded objects will be handled;
• the significance rule used to decide which changes require attention;
• the intended user and action supported by the comparison.

Use a DELTA map

Create a DELTA map for every material difference:

| Element | Comparison question | Evidence artifact | | --- | --- | --- | | Documents | Which exact versions are being compared? | File identifiers, dates, hashes, and approval state | | Edit | What text, table, requirement, or attachment changed? | Before and after excerpts with locators | | Lens | Is the change substantive, structural, editorial, or uncertain? | Classification and rationale | | Task effect | What decision, obligation, workflow, or control could change? | Impact note and affected owner | | Action | What must be accepted, clarified, tested, or escalated? | Disposition, owner, and due point |

Run a mechanical diff to find candidate edits, but do not let it determine significance. A single changed word such as “may” to “must” can matter more than a rewritten page. A paragraph moved without alteration can produce a large diff while changing no requirement. Tables require cell-level comparison, and annexes may modify definitions used throughout the main text.

AI can cluster candidate changes, translate dense redlines into plain language, and propose impact questions. It should receive the version manifest and must cite both before and after locations. The worker should verify every material item against the original documents.

Worked example: a synthetic operating-procedure revision

Consider a synthetic operations lead comparing version 3.1 and version 4.0 of an incident-response procedure before a training update. This example is original and does not describe a Two Prune customer.

A word-processing comparison shows 146 edits. An AI summary says the new version “clarifies roles and modernizes terminology.” That description misses the operational changes. The lead creates a version manifest, confirms that version 4.0 is approved but not yet effective, and builds a DELTA map.

The map identifies four different change types:

The first item is structural and needs no training change. The second changes an obligation, time limit, and owner, so the training scenario and checklist must be updated. The third changes classification logic, so test cases need to be rerun. The fourth creates an internal contradiction that must be resolved before the procedure is released.

For the notification change, the DELTA entry retains both clauses, their section numbers, the approval status, the future effective date, and the affected training artifact. The action is not merely “update wording.” It names the procedure owner, training owner, checklist item, and effective-date gate.

The lead also performs a reverse comparison from version 4.0 back to 3.1. This exposes a deleted exception that the first AI summary had treated as formatting. The final artifact contains a concise change register, an unresolved-issue log, and an implementation checklist. It does not claim that version 4.0 is currently operative before its effective date.

The comparison is useful because it connects verified edits to actions while keeping non-substantive movement out of the decision path.

• a glossary is moved to an annex with no change in meaning;
• “incident coordinator may contact legal” becomes “must notify the duty counsel within 30 minutes”;
• the severity table changes the threshold for a level-two incident;
• an old escalation email is replaced with a service-desk queue, but the appendix still lists the old address.

Practice across formats

Give a learner two versions of a policy pack containing prose, a requirements table, and an appendix. Include:

Ask for a DELTA map and a one-page implementation note. Then reveal that one file was a draft and supply the approved version. The learner should invalidate the affected comparison, preserve the audit trail, and rerun only the relevant checks. They should not quietly overwrite the input identity.

Practice should cover both native tracked changes and documents that require text or table extraction. Optical character recognition may introduce apparent edits, so the learner should distinguish source changes from conversion artifacts.

• a paragraph moved without substantive change;
• a changed obligation hidden in a long sentence;
• a threshold changed in a table;
• a definition changed in an annex;
• one unresolved inconsistency introduced by the revision.

Assess observable comparison behavior

In an assessment, observe whether the participant:

Do not reward the number of detected edits. The relevant behavior is finding the changes that matter for the task, treating version identity correctly, and making the result reproducible. A participant may operate comparison software successfully while missing the one edit that changes an obligation.

• establishes the exact baseline and comparison versions;
• checks approval and effective dates rather than trusting filenames;
• defines the intended comparison question and significance rule;
• finds changes in prose, tables, definitions, and attachments;
• distinguishes moved or reformatted content from substantive edits;
• records before and after evidence with precise locators;
• explains the task effect without inventing legal or policy conclusions;
• verifies AI-generated change summaries against both originals;
• identifies contradictions or downstream artifacts affected by the revision;
• produces a clear action register rather than a list of textual differences.

Verify the comparison artifact

Use four checks.

First, confirm the version manifest independently. Open each source and verify its identifier, approval state, date, and direction of comparison.

Second, trace every high-significance DELTA entry to both original locations. Do not verify a summary against a generated redline alone.

Third, run bidirectional and structural checks. Reverse the comparison to expose deletions, and separately inspect tables, annexes, headers, footnotes, and embedded files that prose-oriented tools may miss.

Fourth, perform an impact-owner review. Ask the person responsible for the affected workflow whether the stated task effect and action are complete. This does not transfer evidence responsibility to that reviewer; it tests whether the comparison supports its intended use.

Document comparison skill is bounded by the supplied versions, tools, and purpose. It does not establish that either document is correct, lawful, or suitable for every setting. In a Two Prune assessment, the version manifest, DELTA map, tool use, AI interactions, verification checks, revisions, and final implementation note can contribute bounded evidence about Evidence Navigation, Verification & Risk Control, Judgment & Synthesis, and Communication & Delivery. They do not make an employment decision.

Sources

GOV.UK open standard for sharing or collaborating with government documents

• UK Lawmaker release guidance for document comparison

Sources: [1] [2]