How we measure

Measurements are grouped into lenses, each lens is made of dimensions, and every dimension states how confident it is entitled to be. The last part is the one that matters most.

A dimension is one thing we measure — a single, defined property of a codebase, scored from 0 to 10. Dimensions are the unit the whole system is built on: findings belong to a dimension, scores are computed per dimension, and improvements are visible per dimension.

The set of dimensions grows and changes as the system improves, which is why they are not listed here. The complete, current catalogue for any rubric version is published openly at codeassuranceindex.info/api/rubrics/<version>/catalog, including what each dimension measures and what a high or low score means.

Dimensions are grouped into lenses — broad areas of concern such as code health, architecture, maturity, production readiness, or security and compliance. A lens answers a question a person actually has ("is this maintainable?", "is this safe to run?") rather than a question a tool finds convenient to answer.

Some lenses apply to every codebase. Others are conditional: they are measured only when the codebase is the kind of thing they are about, and are otherwise left out rather than scored against criteria that do not apply.

"Nothing was found" is not one statement. It can mean two completely different things, and collapsing them is the most common way a code-quality score misleads its reader.

What we report — What it means

• Verified — The property was measured directly across the whole surface, and the measurement came out clean. A real result from a real measurement.
• Nothing flagged — We swept for a specific problem and found none — no exposed credentials, no banned patterns. Here, finding nothing is the measurement, bounded by how much was searched.
• Not established — The property requires positive evidence that something works — a restore that has actually been tested, a rollback that actually runs — and no such evidence was found. Absence of evidence is not evidence of a working control, so this does not become a perfect score.
• Sampled — The judgement was made by examining a sample rather than every case, and is reported as such.

Every dimension's score carries which of these it is. That is the difference between "we checked and it is fine" and "we found nothing, which may mean there was nothing to find, or may mean we could not look".

Why the distinction exists. The simpler design awards ten out of ten whenever nothing was found. That flatters a codebase with no disaster-recovery process at all — nothing was found because nothing exists. Collapsing the two states leaves a score unable to distinguish "safe" from "unexamined".

Most measurement is deterministic: the code is parsed and analysed by tools that produce the same answer every time. Some checks additionally run established open-source analysis tools. A smaller set of judgements — where the question is genuinely about meaning rather than structure — are made with the help of a language model running on our own infrastructure.

Where a judgement was model-assisted, the finding says so. A reader can therefore always tell how a given conclusion was reached, and weigh it accordingly.

Some dimensions are advisory: reported, explained, but deliberately excluded from the score. This is where a measurement is useful to know but not yet something we are prepared to charge against a result — typically a newer signal still being validated.

Advisory status is stated on the dimension. Nothing is quietly counted, and nothing is quietly ignored.

If a project does not build in our environment, the checks that depend on building cannot run. Those dimensions are excluded from the result rather than scored as failures — a project that compiles perfectly well elsewhere should not be marked down because our environment could not build it. The report says which measurements were affected and why.

• A finding is a work packet — covers what to do with a measurement once it is in hand.
• Security is not a CVE list — covers how the security lens differs from a vulnerability scanner.