# Code review as a fractal semantic graph: what changed in v1.2.0, sgit.ai > The changes to the article "Code review as a fractal semantic graph" in v1.2.0, paragraph by paragraph. *Source: · site v0.7.38 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [Code review as a fractal semantic graph](../../code-review-as-a-fractal-semantic-graph.md) / [Versions](../code-review-as-a-fractal-semantic-graph.md) / v1.2.0 # Code review as a fractal semantic graph: what changed in v1.2.0 From v1.1.0 (2026-10-03, `77644f732`) to v1.2.0 (2026-10-05, `4d6a7b929`), paragraph by paragraph. 0 paragraphs added, 0 removed, 7 changed in place, 83 unchanged. About 0 words added and 0 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [← v1.1.0](v1.1.0.md) · [all versions](../code-review-as-a-fractal-semantic-graph.md) · [v1.3.0 →](v1.3.0.md) 2 unchanged paragraphs !shot crg-ladder.webp | images/ | The altitudes of one Python repository, and where the vocabulary changes. Each runglayer is a graph of its own. The green marks are where you change universe: the words for architecture are not the words for types, and neither are the words for syntax. C4's four levels and Gherkin's top runglayer are beside it for comparison. Counts are from the worked example in the vault. 17 unchanged paragraphs, under In short, Source code is already the thing, What C4 saw, and what Gherkin got right Gherkin, the language under Cucumber, which Aslak Hellesøy created in 2008, got a different part right. It forced the top runglayer into a shape people could write and read: Given a context, When an event, Then an outcome. Teams that used it well produced user stories that were also executable, and that mattered. But the glue underneath was pattern matching. Cucumber's own documentation says it: "A step definition's expression can either be a Regular Expression or a Cucumber Expression." The step text was matched to code by a regex, and the documentation's own anti-patterns page warns that feature-coupled step definitions "may lead to an explosion of step definitions, code duplication, and high maintenance costs." I said on a podcast in 2024 that Gherkin was always a hack because of how hard it was wired to the back end, and I stand by that, with affection. It was the right top runglayer with no ladder beneath it. 14 unchanged paragraphs, under What changed, Review every layer, diff every layer !shot crg-delta-upwards.webp | images/ | One commit, read upwards. The text diff is 75 lines added and 7 removed in three files. The graph reads the same change at every altitude and climbs the call graph to the commands and stories that can reach it. The pattern across the rungslayers is the shape of a fix: bodies moved, shapes still, a test added. 11 unchanged paragraphs, under Method streams, again, The worked example !shot overview.webp | ../demos/vaults/code-review-graphs/images/ | The vault as it opens: the ladder of seven altitudes, with how many nodes at each one commit touched. Click a runglayer to open its layer. 9 unchanged paragraphs, under What makes it work is reality !shot crg-reality-loop.webp | images/ | The feedback loop. Derive what a parser can derive and let a model propose the rest, marked as proposed. Confront it with users, who confirm whether a story holds; with experts, who each read the runglayer they know; and with tests, which are mapped from imports and confirmed by execution. Keep every correction as a commit to the graph files, and re-derive only what changed. **Users confirm the top.** A user story either holds after a change or it does not. If the graph said a change could reach the story "publish a new vault for the first time" and a user cannot, the graph was right about the reach and the change was wrong. If the user can and the graph said it could not be reached, the graph has a missing edge, and that is a correction to commit. Either way, behaviour is the test of the top rung,layer, and it is the one test that does not depend on anybody's opinion. **Experts confirm their rung.**layer.** The architect reads the component graph and says whether it is the architecture. The security reviewer reads the flows and the forbidden shapes. The author reads the method stream. The designer reads the interface graph. Nobody has to read the whole thing, because the whole thing is not at any one altitude. This is also why the graph has to be files and not a tool's internal state: a reviewer corrects a file, and the correction is a commit with a name on it. 30 unchanged paragraphs, under What exists today, and what does not, For somebody to build, Threads woven here… [← v1.1.0](v1.1.0.md) · [all versions](../code-review-as-a-fractal-semantic-graph.md) · [v1.3.0 →](v1.3.0.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://sgit.ai/articles/versions/code-review-as-a-fractal-semantic-graph/v1.2.0.html)*