Dimensions & lenses
What gets measured, and where each measurement lands.
A lens is one broad view of a codebase, such as how the code reads or how it is secured. A dimension is a single measurement taken inside a lens. Ten lenses, each with its own dimensions, are everything the standard looks at.
Five lenses apply to every codebase. The other five apply only where the architecture calls for them, and where one does not apply, the share of the weight it would have carried moves to the lenses that do.
The ten lenses
Five always on. Five that light up with your architecture.
Always on
Code health
Complexity, duplication, code shape and naming. How maintainable the code itself is to whoever reads it next.
Always on
Architecture
Module boundaries, coupling, cohesion and the direction dependencies point. Whether the structure holds up as the repository grows.
Always on
Maturity
Documentation, recorded decisions, comments and the signals a project gives off about how it is run. How well it explains and governs itself.
Always on
Readiness
Tests, the gates a change has to pass, what can be observed once it is running, and how it recovers or rolls back. Readiness to run in production.
Always on
Security & Compliance
Secrets left in the code, publicly recorded vulnerabilities in the libraries it depends on, weaknesses found by scanning the source itself, and how licences and personal data are handled.
Conditional
Domain Modelling
Whether the code models the business it serves. The objects it is built around, the boundaries between them, and the rules that must always hold true.
Conditional
Event-Driven
How parts of the system talk to each other when they do not talk directly. Whether messages survive a failure, and how tightly the contracts between senders and receivers bind them together.
Conditional
Event Sourcing
Systems that keep every change as a permanent record rather than overwriting state. Whether those records stay immutable, replay the same way every time, and avoid trapping personal data somewhere it can never be removed.
Conditional
Accessibility
Whether the interface can be used by somebody who cannot see it or cannot use a mouse. Text alternatives, labels, keyboard navigation, and whether any of it is checked automatically rather than hoped for.
Conditional
Performance
Whether performance is measured at all rather than assumed, and whether the code is written with memory use and concurrency in mind.
Each dimension records how it was evaluated and under which rubric version. Most are scored by a deterministic tool, meaning one that follows fixed rules and returns the same result every time. A few carry an advisory read, which explains a finding in plain English and stays outside the arithmetic. A dimension that could not be measured is recorded as not measured, with the reason, and takes no part in the score. It is never quietly turned into a zero.
The catalogue
Read the catalogue for the rubric your survey names.
Every dimension the standard defines is listed below: its code, what it measures, the lens it belongs to, and how it was evaluated. Both kinds are here, the ones a finding cites by code and the ones that feed straight into a lens.
Behavioural & history dimensions
What the git history testifies to.
Four dimensions come from the repository's history rather than from the files as they stand today. A codebase tells you things over time that no single snapshot of it can.
Hotspots
How often a file changes, set against how complicated it is. A file that is edited constantly and hard to read is where the next defect is most likely to land, and neither measurement on its own would have found it.
Bus factor
How concentrated the knowledge is. Which modules rest on a single contributor, and whose leaving would orphan the most significant code in the repository.
Knowledge freshness
Code that everyone who understood it has stopped touching. The knowledge decays while the files themselves look exactly as they did.
Change coupling
Files that keep being changed together with no declared dependency between them. That is real structure, and the code does not admit to it anywhere a reader would look.
Hollow code
The five shapes it takes.
Code that looks finished but does nothing will satisfy a compiler, look complete to a reviewer, and give a line-by-line scanner nothing to report. The standard names these shapes as dimensions of their own, so an implementation measures them and they count towards the score like anything else.
- Stubs that look implemented (IC1). Confident names over a bare return, async methods that never wait for anything, skeleton types, branches nothing can reach.
- Tests that assert nothing (D10). Tests that pass because they check nothing at all, and skipped tests dressed up as coverage.
- Errors made invisible (X3). Empty catch blocks, and rethrows that lose the trail back to where the failure started.
- Untracked debt and dead code (D17). TODO, FIXME and HACK markers, blanket suppressions, commented-out code, symbols nothing refers to.
- Copy-paste, never parameterised (D4). Near-duplicate code repeated across the codebase, matched by structure rather than by text.
Each signature feeds a reading for the file it was found in, one that rises steeply over the first few instances and then levels off. One stub in a file and a hundred stubs in a file are not the same problem, and a flat rule counting occurrences cannot tell them apart.
What gets measured is the hollowness.
The standard makes no attempt to detect who or what wrote a piece of code, and refuses that claim where others make it. A rushed human and an eager model produce the same finding and the same fix, so what gets measured is whether the code does the work it appears to do, whoever typed it.
Defined here, measured elsewhere.
This catalogue is the standard's: what each dimension measures, which lens it folds into, and what a number under it means. The detectors that evaluate a dimension against actual code belong to the implementation that ran the survey, and each implementation builds its own. That split is what lets a score be read the same way whoever produced it.
The vocabulary is public. So is the way the parts combine.
Work a published score out again from its own evidence → check a score