Home / Articles / If somebody built a company on code review / Versions / v1.1.0
If somebody built a company on code review: what changed in v1.1.0
From v1.0.0 (2026-10-05, 4fab15075) to v1.1.0 (2026-10-05, 4d6a7b929), paragraph by paragraph.
0 paragraphs added, 0 removed, 16 changed in place, 100 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.
1 unchanged paragraph
Summary: The code review article drew a careful reply from a reader, seven questions long, and a voice memo from me answering them. This is the written answer, framed the way the memo framed it: if somebody were building a company on code review, this is how I would do it. The questions were good ones. Could the graph be built from the user stories before the code exists, and the two ends married? Where were the commands and modules layers in the example? Are hand-written stories too high level, and should they be rules and examples instead? Is "a refactor leaves the class shapes still" wrong when an architecture migration keeps only the client interface? Where do deploys and infrastructure go? How do you stop the cost spiking when a repository is onboarded? What is the blast radius compared to, and how long should the report be? The answers turn on one distinction the first article did not make clearly enough. What is fractal in a fractal semantic graph is the grammar: nodes, edges, an ontology, a taxonomy and a way to the next altitude. Which layers exist, what they are called and where they stop is decided by each company, its culture, its languages and its stack, and a product that standardises them away loses the thing it was meant to review. From there: a projected graph built top down from stories, rules and examples, a derived graph built bottom up from the syntax tree, and the review as the join; a refactor as relative to the layer you hold still; the deploy as a rung;layer; who reads the code at each stage of evolution, after Wardley; reshaping a change rather than reviewing it as it arrived; a budget per altitude and the five whys as the loop that makes the next review cheaper; and open source as the only business model that fits, because the layers are the customer's and the loop has to run where the code is.
!shot cr2-fractal-or-not.webp | images/ | What is fractal and what is not. The constant across every codebase is the grammar: nodes, edges, an ontology, a taxonomy and a way to zoom in and out. Which layers exist, what they are called, which languages fill the bottom rungslayers and what the business counts as a change that matters are decided by the company you are in. The first article's seven altitudes were one Python repository's layers, not the layers.
7 unchanged paragraphs, under In short
• The deploy is a rung.layer.** Infrastructure, pipelines and environments are graphs with their own vocabulary, and a change's blast radius runs through them to what is running where. The non-functional requirements live at that altitude and above it, and they are reviewed the same way: by what the change can reach.
3 unchanged paragraphs
• Compare the blast radius to the intent, and report one line per runglayer that moved. Not to the old code. To the projected graph, the commit message, the documentation engineers already write, and the stories. Progress on a big feature is the count of projected nodes that now have a derived match, which is how small increments are measured before they move any needle.
3 unchanged paragraphs, under The grammar is fractal, the layers are yours
Notice what is in that list and what is not. The grammar is in it: nodes with a type and a name, edges with a verb and a named inverse, an ontology that says what the types and verbs mean at this altitude, a taxonomy that says how the nodes group, and the move in and out. The layers are not in it. Which layers exist, what they are called, which languages fill the bottom rungslayers and what counts as a change that matters are not properties of the graph. They are properties of the company you are in.
That is the answer to the reader's first instinct and to mine. The first article drew seven altitudes for one Python repository: stories, commands, packages, classes, methods and calls, syntax, and the machine below. Those were that repository's layers. A team of three with a Flask app and a bank with four hundred services in six languages do not have the same layers, and should not be made to. One calls them epics and stories, another calls them services and bounded contexts, a third has infrastructure as a layer that the first two do not have at all. The programming languages decide the bottom rungs,layers, and the languages people speak decide the top ones. The culture names them. The objectives decide which runglayer counts.
3 unchanged paragraphs, under Build the graph from the top, before the code exists
Yes, and this is how I would run a project from the start. The order I use for anything I build now is: brief, then plan, then architecture, then a review of the architecture, then a simulation of it with synthetic users, and the code last, when the shape has survived everything that can be thrown at it without code. Each of those steps produces a graph in the same grammar. The brief names objectives. The plan names stories, and each story names its rules and the examples that make the rules concrete. The architecture names features, flows, the commands and surfaces the stories will touch, and the components they will need, sketched as far down as design can honestly see and no further. Below that the projection stops, and it should say so, because everything under the lowest honest runglayer is wishful thinking until a parser can read it.
9 unchanged paragraphs, under The layers the example had and the text did not walk
The commit in the vault changed seven methods in two classes, which live in two modules, the command-line vault module and the automatic transport module, in two packages, the command-line package and the network package. Climbing the call graph from the changed methods reached nine of the seventy-two commands and six of the eleven stories. The delta figure shows every one of those rungslayers in red, including the commands and the modules. The text took the two ends, methods and stories, because the shape of a fix is clearest there, and left the middle rungslayers to the picture.
That is a writing fault and the vault is unchanged by it, but it also hides a point that a product would need. The middle rungslayers are where the review's audience changes. Methods are read by the author and whoever owns the file. Modules and packages are read by whoever owns the architecture, because that is the runglayer where a change can cross a boundary it should not. Commands and surfaces are read by whoever owns the users, because that is where behaviour becomes visible. A review that visits every runglayer is also a review that routes each runglayer to the person who can judge it, and the middle rungslayers are the ones with the fewest readers today, which is one reason architecture drifts.
3 unchanged paragraphs, under Stories as rules and examples
In the graph that is the top runglayer done properly. A story is a node whose children are rules, each rule a node whose children are examples, and each example a node with an edge to the test that exercises it or the recorded run that passed it. "Hand-written" then stops being a weakness, because what is written by hand is the smallest unit that can be checked. The question cards are the "derived, not projected" and "projected, not derived" findings before the code exists: things the conversation could not settle, held in the graph as questions rather than lost in a meeting.
10 unchanged paragraphs, under A refactor is relative to a layer, Down to the deploy
They are rungs.layers. A deployment pipeline, the environments it deploys to, the services running in each, the configuration they read and the secrets they hold are a graph with its own vocabulary, and the vocabulary changes at that altitude as sharply as it does between types and syntax. The nodes are things like a pipeline stage, an environment, a running service, a bucket, a role; the verbs are things like deploys-to, reads-from, assumes, exposes. A change's blast radius does not stop at the command that can reach it. It continues through the deploy graph to what is running where, and a change to a configuration file with no code in it can have a blast radius wider than any method.
The non-functional requirements live at that altitude and above it. Performance, availability, cost, security posture and recoverability are properties of the deployed system, not of the code alone, and the sibling site nfrs.sgit.ai is this site's attempt to hold its own non-functional requirements as measured claims rather than restated ones. The rule there is "LINK THE MEASUREMENT, NEVER RESTATE IT. GENERATE OR DATE EVERY NUMBER." A review that reads a change at the deploy runglayer asks which measured claims it can reach, and the Cartographer role in the Send team puts the standard for that runglayer in one sentence: "If a dependency, data flow, or security boundary exists but is not visible on a map, the Cartographer has failed."
10 unchanged paragraphs, under Who reads the code, Review is not saying no
With the graph a change can be split by reach, and each part gets the review it deserves. The part that provably reaches no behaviour, documentation, generated code, formatting, a rename whose every caller moved with it, is merged by a deterministic check, with no model in line and no human. Most of the volume lives here. The part that reaches behaviour through paths that have tests, or inside a layer whose contract is held still, gets the checks run and a model's one-line summary of what moved against what was intended, and a person glances. The part that reaches a mission-critical path, a story customers depend on, or a layer with no test holding it gets people, the right people, with the right context: the architect for the component rung,layer, the product owner for the story, the author for the method stream.
4 unchanged paragraphs, under Replicate reality first
The order of operations I would build the company on is to replicate reality before having an opinion about it. Derive from the code what a parser can derive, deterministically, with no model in line, so that every node has a file and a line and every number is checkable. This is the rule I set out in July 2025 for every model-driven solution, "use LLMs to figure out the solution, then use code to execute the solution thereafter", and in a graph the rules that matter are plain to execute. The 2025 piece on semantic knowledge graphs for source code analysis gave the example: "we check that every endpoint function node has an edge to an Auth check node; the ones that don't are instantly known." Let a model propose what a parser cannot see, the story a command serves, the intent behind a module, the edge a dynamic dispatch hides, and mark every proposal as proposed. Then confront the graph with the three things that can correct it: users, who confirm whether a story holds; experts, who each read the runglayer they know; and tests, mapped from imports and confirmed by execution. Every correction is a commit to the graph files. Only then is the conversation about the code a conversation about facts, and the memo put it as "replicate reality first, then have a fact-based conversation".
13 unchanged paragraphs, under Constraints keep it in control, the five whys make it cheaper, What to compare the blast radius to, and how long the report should be
The report is one line per runglayer that moved, saying whether the move matches the intent, and nothing for the rungslayers that did not. A tidy-a-method refactor reports two lines: methods moved, syntax moved, and the class shapes held as claimed. A fix reports the rungslayers it climbed to the story that now holds, and whether a test was added. A change that reached a runglayer its description did not mention reports that runglayer in a different colour. The intent is kept not by writing more but by having the projected graph to compare against, so that "matches the intent" is a computed statement rather than a reviewer's paraphrase.
8 unchanged paragraphs, under The company, What the first article got wrong, and what this one leaves open
What is open. The projected graph has not been built for a real project from a brief forward; this site's own briefs and reality files are the nearest thing and they are reconciled by hand. Rules and examples as the top rung,layer, matched to tests by execution, is on the vault's list and has moved up it. The deploy runglayer has not been derived for any repository here. And the thing the first article ended on is still true: the review itself, the thing that sits on a change and shows it at every altitude, does not exist yet. What exists is a vault with the layers, a reader's seven questions, and this answer to them.
26 unchanged paragraphs, under Threads woven here, Sources