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

Architecture · 20 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`D5`	Coupling	Whether volatile projects sit underneath others that depend on them (so their churn ripples upward), and whether project dependencies form cycles. A widely-depended-on but stable shared/kernel project is healthy, not penalised.	When this is weak, the parts of the system depend tightly on each other and form circular dependencies, so a change in one place forces changes in several others and the structure resists growth.	tool
`D6`	Cohesion (LCOM4)	Whether a class's methods are focused on a single responsibility.	When this is weak, individual classes mix several unrelated responsibilities, making them harder to understand, test and change in isolation.	tool
`D7`	Architectural Integrity	Whether the code respects its intended layering / architecture rules.	When this is weak, the code does not respect its own intended layering, so the structure on paper no longer matches reality and the design erodes over time.	tool
`D22`	Internal API Consistency	Whether the internal API surface is consistent and coherent.	When this is weak, the system's internal interfaces are inconsistent, so developers cannot rely on familiar patterns and each part has to be learned from scratch.	LLM · advisory
`D23`	Boundary Type-Coupling	Whether domain types (IDs, enums, value objects) leak across bounded-context boundaries.	When this is weak, domain types leak across module boundaries, so the parts of the system that should be independent become entangled and cannot evolve separately.	tool
`D26`	Project Cohesion	Whether each project is a focused, coherent unit rather than an oversized grab-bag.	When this is weak, individual projects have become oversized grab-bags rather than focused units, blurring responsibilities and making the codebase harder to reason about.	tool
`D27`	Navigability	How far you must trace to follow a call — low indirection and co-located slices read easier.	When this is weak, following a single call means tracing through many layers of indirection, so understanding even simple behaviour takes a developer much longer.	tool
`D35`	Change Coupling	Whether files that change together actually belong together — pairs that repeatedly co-change in git history despite having no explicit code dependency, surfacing the hidden/logical coupling (and boundaries in the wrong place) a static scan can't see.		tool
`AX1`	Captive dependenciesmeta	Whether any singleton service captures a scoped/transient dependency — a silent lifetime/threading bug.	When this is weak, long-lived services hold on to short-lived dependencies — a silent lifetime bug that can cause subtle, hard-to-reproduce errors under concurrent use.	tool
`AX2`	Stateful singletonsmeta	Whether singleton services avoid mutable shared instance state that concurrent callers would race on.	When this is weak, shared single-instance services keep mutable state that concurrent users can race on, leading to intermittent corruption that is very hard to track down.	tool
`AX3`	Project dependency cyclesmeta	Whether the project-reference graph is acyclic (cycles block independent build/deploy and signal eroding boundaries).	When this is weak, the projects depend on each other in cycles, so they cannot be built or deployed independently and the architectural boundaries are eroding.	tool
`AX4`	Dependency directionmeta	Whether dependencies point inward (Domain ← Application ← Infrastructure/Web) — the clean-architecture dependency rule, checked across the project graph.	When this is weak, dependencies point the wrong way through the layers, so the core business logic is tied to technical details and becomes harder to test and replace.	tool
`AX5`	Architecture & structuremeta	Whether the codebase has a recognisable, scale-appropriate structure (a named architectural style, or modular enough for its size) rather than being an ad-hoc ball of mud.	When this is weak, the codebase has no recognisable, scale-appropriate structure, so it reads as an ad-hoc tangle that is hard to navigate and grow.	tool
`AX6`	Interface segregationmeta	Whether interfaces stay focused rather than fat — the Interface-Segregation principle (SOLID 'I').	When this is weak, interfaces have grown fat with unrelated members, forcing callers to depend on methods they do not use and making the contracts harder to change.	tool
`AX7`	Slice cohesionmeta	Whether feature slices stay independent (no direct cross-slice references) — the discipline that makes vertical-slice architecture pay off.	When this is weak, feature slices reach directly into each other instead of staying independent, so a change to one feature can unexpectedly break another.	tool
`AX8`	Test isolationmeta	Whether production projects stay free of references to test projects — tests may depend on production, never the reverse.		tool
`AX9`	CQS / query puritymeta	Whether read (query) handlers stay side-effect-free — a query that writes persistent state or raises events breaks CQS and makes reads unsafe to retry, cache, or route to a read replica.		tool
`AX10`	Code compositionmeta	How the codebase splits by code ROLE — domain, application, infrastructure, test, generated. The significance map behind the knowledge/coupling weighting, and a DDD signal in its own right: a thin domain core under fat infrastructure is the anemic-domain smell, quantified.		tool
`R9`	Circular Importsmeta	Import cycles in the module graph (D-386) — files that can only be understood and changed together.	When this is weak, frontend files import each other in cycles, so they can only be understood and changed together — a tightly knotted area that resists refactoring.	tool
`R11`	Import Boundariesmeta	Conformance to the detected frontend architecture layout (feature-sliced / layered src) plus cross-package deep-import rules (D-386).	When this is weak, the frontend ignores its own intended layout and reaches across package boundaries with deep imports, so the structure decays and modules become entangled.	tool