How to compare two versions of a regulation: a change map instead of a summary

Why the usual approaches fail

Take a real case. On 1 September 2026 new retail sale rules came into force in Russia. They were approved by Government Resolution No. 657 and replaced the rules of Resolution No. 2463. This is not an amendment but a new document: clauses were added at the start, so every clause after them was renumbered.

Each familiar way of comparing documents has its own weak spot here:

• A model’s summary. Every sentence is plausible. If the model mixed up a clause or invented a requirement, reading will not reveal it: checking turns into trusting.
• A line-by-line diff. It highlights everything. A sentence was reworded with the same meaning, and the whole section looks changed.
• Matching by clause number. Once the numbering has shifted, clause 5 of the old version is compared with something else entirely.

What you need is a result you can verify without rereading both documents in full and without taking a summary on faith.

The idea: changes are a graph, not prose

Every change is a link between clauses of the two versions: a clause was rewritten, split, merged, removed or added. Lay those links out by topic — one sheet for complaints, one for returns, one for product information — and you get a map where:

• every node points to specific clause numbers in the old and the new version, so it can be checked against the source;
• a new requirement with no link to an old clause stands out at once, and so does an old clause with no counterpart;
• a requirement that touches several topics stays one entity on several sheets, and the gold line shows where else it appears.

This is how it looks in the real map. Both versions are cut into clauses by a script, the clause text is verbatim, and every section is a sheet of its own. The model fills in the work sheets: “Changes”, “Requirements”, “System”, “Checks” and “Questions”. A change that touches both versions has links on both sides; something new or removed has a link on one side only. In the picture, the reservation about complaints “in any form” has no clause on the right, and the refund complaint has none on the left.

Step by step

1. Take both versions from an official source. In this example: the new rules (No. 657) and the previous rules (No. 2463) on the Russian Government website.
2. Split each version into clauses — without the model. A small script or manual markup: one clause, one numbered fragment. This keeps clause text on the map verbatim; the model cannot “improve” or invent it.
3. Take the map format from PlyLoom’s help. Under “Help → AI prompt” you will find the format description with an example. Copy it with “Copy prompt” and add the task: match clauses of the two versions, group the changes by topic — one sheet per topic — and give every change the clause numbers in both versions.
4. Give the model the format and the two files of clauses. The answer is one JSON file. Save it as .plyloom or .json.
5. Open the file in PlyLoom: “Project → Open .plyloom…”. Before replacing the project, PlyLoom checks the file’s structure and shows how many sheets, nodes and links will come in. You can undo the replacement until the page is reloaded, but save your own map first anyway. “Help → Check project” lists broken links, lone nodes and empty sheets.
6. Check the map — see the next section.

How to check the map by eye

Checking is the main part of the job, and the map makes it almost mechanical:

1. Open Contents or the Sheet overview to see every topic at once. The node count on each sheet card shows which topic looks empty or suspiciously large — start there.

2. Switch to Spread and put two or three sheets of one area side by side. Links to all the other sheets are shown on the frame around each sheet, and the gold line joins appearances of the same requirement.
3. For every node, check the clause numbers against the text: “+” unfolds the card in full, and the clauses themselves sit next to it, on the frame. Mark what you have checked with an attribute such as “Review status” and find the rest with the Filter. Save that filter as a smart sheet, and everything not yet checked, from every sheet, gathers on it by itself.

4. Review nodes without links separately: each one is either a genuinely new requirement or something the model missed. You need to know both. “Help → Check project” lists them for you.

What the map showed in the retail rules

In the section on customer complaints, the map showed that the requirements for the seller’s reply became more detailed: the address given in the complaint itself matters, as does a deadline counted from receipt, and one earlier reservation disappeared. A summary makes this easy to miss; on the map these are separate nodes with clause numbers.

For a shop this turns into concrete work: review the reply template and the way deadlines are counted, and separately decide and write down how to handle complaints that do not follow the form. The old rules had a reservation about this; now it is the shop’s own decision.

This illustrates the method; it is not legal advice. Check the text of the resolution before changing your processes.

What the method does not do

• The map does not understand what the changes mean. The model can match clauses wrongly or miss a link — which is exactly why nodes carry clause numbers.
• A person still does the checking. What changes is the kind of checking: instead of reading a summary and trying to catch a mistake, you compare specific nodes with specific clauses.
• Building the map takes minutes; most of your time should go into checking it. That is how it should be.

Where else it helps

The same approach works for versions of contracts, internal policies, standards, specifications and requirements between releases — anywhere the question is not “roughly what changed” but “which clause became which”.

An earlier Russian version of this article, with discussion, was published on Habr. Screenshots are from version 0.9.1.

Read next