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 Code Health lens. Show all 124 dimensions →

Code Health · 22 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`D1`	Cyclomatic Complexity	How tangled the control flow is — methods with many branches are hard to test and change.	When this is weak, the code is full of tangled, heavily branching methods that are hard to test and risky to change, so even small changes take longer and break things more often.	tool
`D2`	Cognitive Complexity	How hard the code is for a person to follow, beyond raw branching.	When this is weak, the code is hard for a developer to follow, so understanding it before changing it takes longer and mistakes are more likely.	tool
`D3`	God Classes	Over-large classes that try to do too much ("god classes").	When this is weak, oversized classes try to do too much at once, making them a bottleneck that several developers cannot safely work on in parallel.	tool
`D4`	Code Duplication	Copy-pasted code that should be shared instead.	When this is weak, the same logic is copy-pasted in several places, so a fix or change must be made repeatedly and it is easy to miss a copy and reintroduce a bug.	tool
`D17`	Explicit Debt	Acknowledged debt left in the code — TODOs, dead code, suppressed warnings.	When this is weak, the team has left acknowledged debt in the code — TODOs, dead code and suppressed warnings — that signals unfinished work you will eventually have to pay down.	tool
`D18`	Solution Shape	Whether the solution is laid out in a sensible, conventional structure.	When this is weak, the solution is not laid out in a conventional structure, so a new developer takes longer to find their way around and onboarding costs more.	tool
`D39`	IL Efficiency	IL Efficiency		tool
`GD1`	Unfinished & placeholder codemeta	Unreviewed-generation residue: shipped members still throwing NotImplementedException, and placeholder string literals left in non-test, non-generated code. Scored as a quality signature, never as a claim about authorship.	When this is weak, the code still contains shipped methods that throw "not implemented" and placeholder text left in place, meaning features look present but do not actually work.	tool
`IC1`	Incompleteness & stubsmeta	Unfinished work detected by code SHAPE, not keywords: members that only throw a "not implemented" exception, methods that take inputs and return a constant, async methods that never await, dead `if (false)` / `#if false` branches, and skeleton types most of whose members are holes. A real, objective slice of technical debt.	When this is weak, parts of the code are unfinished by their very shape — stubs, methods that ignore their input, async methods that never wait, dead branches — so the delivery is less complete than it appears.	tool
`R1`	Type Safetymeta	How much of the frontend is typed TypeScript vs untyped JavaScript.	When this is weak, much of the frontend is untyped JavaScript rather than typed TypeScript, so whole classes of mistakes slip through to runtime instead of being caught while coding.	tool
`R2`	Cyclomatic Complexitymeta	Per-function cyclomatic/cognitive complexity from the token-level function scanner (D-386) — real branching, not a regex heuristic.	When this is weak, individual frontend functions are heavily branching and tangled, so they are hard to test and risky to change.	tool
`R3`	Large Filesmeta	How many components/modules exceed the large-file threshold.	When this is weak, several frontend components or modules are oversized, making them harder to understand and a bottleneck for parallel work.	tool
`R7`	Dead Codemeta	Files unreachable from every application/tooling/test entry point, and exports nothing imports (module-graph reachability, D-386).	When this is weak, the frontend carries dead code — files and exports nothing else uses — that adds noise, inflates the build and slows down anyone reading the code.	tool
`R10`	Code Duplicationmeta	Copy-pasted token-identical blocks across the frontend (the D4 clone algorithm over JS/TS tokens, D-386).	When this is weak, identical blocks of frontend code are copy-pasted across the codebase, so the same change has to be made in many places and copies are easily missed.	tool
`X1`	Async correctnessmeta	Whether the code avoids sync-over-async (deadlock-prone blocking on tasks) and async void.	When this is weak, asynchronous code is written in deadlock-prone ways (blocking on tasks, async void), which can cause the application to hang or crash under load.	tool
`X2`	Cancellation propagationmeta	Whether async methods accept a CancellationToken so work can be cancelled (adoption curve).	When this is weak, long-running operations cannot be cancelled cleanly, so the system keeps doing work no one is waiting for and is harder to shut down responsively.	tool
`X3`	Exception handlingmeta	Whether exceptions are handled rather than silently swallowed or rethrown with lost stack traces.	When this is weak, errors are silently swallowed or rethrown with their origin lost, so real failures go unnoticed and are far harder to diagnose when they surface.	tool
`X4`	Structured loggingmeta	Whether log calls use message templates (queryable) rather than interpolated strings.	When this is weak, log messages are built as plain interpolated strings rather than structured templates, so production logs are hard to search and filter when you are trying to find a problem.	tool
`X5`	Nullable reference typesmeta	Whether nullable reference types are enabled and not undermined by heavy `!` suppression.	When this is weak, the compiler's null-safety checks are off or undermined by suppression, so null-related crashes that the language could have prevented reach production instead.	tool
`X6`	Hand-rolled structured-format parsingmeta	Whether JSON/XML is parsed with regex/string hacks while a real parser is already referenced in the same project — a classic source of silent data bugs.		tool
`X7`	Silent fallback defaultsmeta	Whether parse/lookup failure paths return hard-coded constants with no logging or throw — failures that convert data errors into silent behavior changes.		tool
`X8`	JS interop contractmeta	Whether string-named JS interop bindings resolve against the first-party JavaScript, and whether anything guards the boundary against renames.		tool