Description
Most organisations install a coding assistant, hope for a step change, and then wonder why it keeps making confident statements about services it has never seen. The tool is not being stupid. It is being literal. It does not read your architecture diagram, it does not know your org chart, and it does not pick up the things everybody in the room already knows. It works on whatever files, contracts and signals are reachable, and your repository model is what decides which of those exist.
That is the whole of it. In one workspace the right context is at least available to be selected: services, shared libraries, migrations, tests, the decision records. Split across many repositories, the relevant piece may not be in scope at all, and unless somebody has built the retrieval plumbing to stitch them together, the model answers from partial truth with no way to tell that it is partial. Ask how authentication flows through the system and you get a clean end-to-end story in one case and a treasure hunt in the other.
None of which makes one repository right and many repositories wrong. Plenty of organisations run well on either. The question is not which model you chose. It is whether anything enforces the model you chose: scoped builds and real module boundaries in the one case, versioned and enforced contracts in the other, so that crossing a boundary fails rather than merely being noticed by whoever happens to read the change.
That is what this dimension scores. Not elegance, and not a preference. Whether the shape of your estate is a fact a machine can check, or an intention held in the heads of the people who have been here longest.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nobody chose the repository model. It accumulated. You cannot say how many repositories are in scope, which of them are still alive, or who owns each one, so there is no shape for anything to enforce. The estate has a structure in the sense that a scrapyard has a layout.
The tellPull the list of repositories in your scope and check how many carry a named current owner. If a real share of them come back with nobody, or with somebody who left, you are here.
- 2
Tacit
There is a model, and it lives in the heads of the people who have been here longest. Boundaries hold because those people read the pull requests. New services land in the right place when the right reviewer is paying attention, and in the wrong place when they are on holiday.
The tellAsk two engineers who joined this year where a new service goes and what it is allowed to call. Two confident, different answers is the tell.
- 3
Visible but inert
The structure is written down. There is a diagram, contracts exist as schema files, folder conventions sit on a wiki page, ownership is in a file. All of it is readable and none of it is wired to anything, so crossing a boundary costs nothing until a human notices. This is the level that feels safe. To an agent that never opens the wiki, it works exactly as if none of it had been written down.
The tellFind the last time someone crossed a boundary your own documentation forbids. It has happened. If what caught it was a reviewer noticing, rather than the build, you are here.
- 4
Acted on
Whichever model you run, the machine holds the shape. In a monorepo, builds are scoped and a module boundary fails the build when it is crossed. Across repositories, contracts are versioned and a consumer that breaks one goes red before it ships. An agent that drifts across a boundary is stopped by the pipeline rather than by whoever happened to be reviewing.
The tellFind the last accidental boundary crossing in your history and look at what caught it. Here the build caught it, and it went red before any person had read the change.
- 5
Durable
The enforcement maintains itself. A new module inherits the rules instead of depending on someone remembering to add it, exceptions carry a date and expire, and when a rule starts firing on things that are fine, somebody tunes it rather than switching it off. It survives a reorganisation, a change of build tooling, and the quarter when everyone is busy.
The tellOpen the exception or allowlist file and read the dates. Entries that expire, on a list that is shorter than last year, is what durable looks like. A list that has only ever grown is enforcement quietly rotting.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Luo et al., RepoCod: Can Language Models Replace Programmers? (ACL 2025)
Built repository-level tasks from real projects and found that half of them cannot be solved without code from other files, with model performance roughly doubling when that cross-file context is actually available.
Zhang et al., LLM Hallucinations in Practical Code Generation (ACM PACMSE 2025)
Classified what models actually get wrong in real repositories, and found a large share of it is project context: calling functions that do not exist here, and inventing dependencies across boundaries it could not see.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Repository structure →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.