The catalog

Every dimension the CAI measures.

The standard is composed of 124 dimensions across 10 lenses. Each is a definition — what it measures and how it's evaluated — pinned to a rubric version. This catalog is the standard's vocabulary; the spec documents how each folds into the score.

Showing only the Maturity lens. Show all 124 dimensions →

Maturity · 12 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`D15`	Churn × Complexity Hotspots	Files that change often and are also complex — the riskiest hotspots.	When this is weak, the riskiest files — those that are both complex and change often — are concentrated and unaddressed, so the same hotspots keep generating defects.	tool
`D16`	Bus Factor	Whether knowledge is concentrated in too few people (the "bus factor").	When this is weak, knowledge of the code is concentrated in too few people, so the project is exposed if a key person becomes unavailable (the "bus factor").	tool
`D19`	Documentation Quality	Whether the project's documentation is clear, complete, and useful.	When this is weak, the project's documentation is unclear or incomplete, so new people lean on the original authors instead of the documents to get up to speed.	LLM · advisory
`D20`	ADR Quality	Whether architecture decisions are recorded well (context, decision, consequences).	When this is weak, the reasons behind key architecture decisions are not recorded, so future maintainers cannot tell why the system was built the way it was.	LLM · advisory
`D21`	Naming Consistency	Whether names — types, methods, variables — are clear and consistent.	When this is weak, names for types, methods and variables are unclear or inconsistent, so the code is harder to read and small misunderstandings turn into bugs.	LLM · advisory
`D24`	Comment Value	Whether comments are worth it — explaining WHY (valuable) rather than WHAT (redundant).	When this is weak, comments mostly restate what the code already says instead of explaining why, so they add clutter without helping the next reader.	LLM · advisory
`D25`	ADR Conformance	Whether the code actually follows the decisions recorded in the project's ADRs.	When this is weak, the code does not actually follow the architecture decisions the project wrote down, so the documented design and the real system have drifted apart.	LLM · advisory
`D34`	Knowledge Freshness	Whether anyone still has living knowledge of each file, or it has been orphaned — last understood long ago by someone now gone quiet. The sibling of the bus factor: D16 asks who owns it, D34 asks whether anyone still knows it.		tool
`M1`	Documentation (README)meta	Whether the repo and its projects have a README, and whether it's substantive and current.	When this is weak, the repository lacks a substantive, current README, so anyone picking up the project has no reliable starting point and onboarding is slower.	tool
`M2`	Architecture documentationmeta	Whether key decisions (ADRs) and the high-level shape (C4/diagrams) are written down.	When this is weak, the key decisions and the high-level shape of the system are not written down, so its design lives only in people's heads and is lost when they leave.	tool
`M3`	Folder & project structuremeta	Whether the repo is organised deliberately — src/test separation and consistent project naming.	When this is weak, the repository is not organised deliberately — source and tests are not cleanly separated and project naming is inconsistent — so it is harder to find your way around.	tool
`M4`	Documentation accuracymeta	Whether the README actually describes the code that exists (LLM-judged, advisory).	When this is weak, the README no longer matches the code that actually exists, so the documentation actively misleads anyone who relies on it.	LLM · advisory