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

Readiness · 24 dimensions

ID	Dimension	What it measures	Why it matters	Evaluator
`D8`	Code Coverage	How much of the code is actually exercised by tests.	When this is weak, little of the code is actually exercised by tests, so most defects are found by your users in production rather than by the test suite.	tool
`D9`	Test Distribution	Whether the test suite has a healthy mix of unit / integration / end-to-end tests.	When this is weak, the test suite is lopsided — missing the right mix of unit, integration and end-to-end tests — so whole categories of failures go uncaught.	tool
`D10`	Test Quality	Whether the tests truly assert behaviour rather than just running the code.	When this is weak, the tests run the code but do not really check its behaviour, so they can pass while the software is in fact broken — giving false confidence.	tool
`D11`	Test Reliability	Whether the tests pass reliably, with no flakiness.	When this is weak, the tests do not pass reliably, so failures get ignored as "flaky" and a real regression can hide among the noise.	tool
`D12`	Dependency Hygiene	Whether dependencies are current, secure, and not bloated.	When this is weak, the dependencies are out of date, insecure or bloated, so the project carries avoidable risk and is harder to keep current.	tool
`D13`	Secret Scanning	Whether any secrets (keys, tokens, passwords) have leaked into the code.	When this is weak, secrets such as keys, tokens or passwords are present in the code, where anyone with access to it can read and misuse them.	tool
`D14`	License Compliance	Whether the licenses of third-party packages are compatible with your policy.	When this is weak, third-party package licenses have not been checked against your policy, so you may be using components on terms your organisation cannot accept.	tool
`ED5`	Idempotencymeta	Whether retry-prone mutations (command handlers + message/event consumers) are idempotent so an at-least-once redelivery or client retry doesn't double-apply the effect — heuristic at-risk detection confirmed by language model, advisory.		LLM · advisory
`P1`	CI/CD gatesmeta	Whether an automated pipeline builds and tests every change.	When this is weak, there is no automated pipeline building and testing every change, so broken code can reach the main branch and problems are caught late, if at all.	tool
`P2`	Observabilitymeta	Whether the code is diagnosable in production — structured logging, tracing/metrics, health checks.	When this is weak, the running system is hard to diagnose — no structured logging, tracing or health checks — so when something breaks in production you are flying blind.	tool
`P3`	Security & performance toolingmeta	Whether SAST, secret/dependency scanning and performance benchmarking are wired in (presence, not runtime).	When this is weak, security and performance tooling — SAST, secret/dependency scanning, benchmarks — is not wired in, so the project has no automated guard against these risks.	tool
`P4`	Deployment & Rollbackmeta	Whether releases are automated and safely reversible (probes, rolling updates, approval gates) — from manifests/pipeline files, not the live environment.	When this is weak, releases are not automated or safely reversible, so every deployment is a manual, error-prone event and rolling back a bad release is slow and risky.	tool
`P5`	DR & Backupmeta	Whether disaster recovery is planned and codified — backups, geo-recovery, RTO/RPO, persistence guarantees — from IaC + container manifests + docs, never the live cloud.	When this is weak, there is no planned, codified disaster recovery — no backups, no recovery targets — so a serious failure could mean prolonged downtime or permanent data loss.	tool
`P6`	Release Hygienemeta	Whether releases are traceable — a maintained changelog and explicit version stamping.	When this is weak, releases are not traceable — no maintained changelog or version stamping — so it is hard to tell which version is running or what changed between releases.	tool
`P7`	Outbound HTTP resiliencemeta	Whether outbound HTTP calls are wrapped in resilience (retry/timeout/circuit-breaker) so a failing dependency doesn't cascade.	When this is weak, outbound calls to other services have no retry, timeout or circuit-breaker, so a single slow or failing dependency can cascade and take the whole system down.	tool
`P8`	Schema migrationsmeta	Whether EF Core schema changes go through versioned migrations rather than the un-evolvable EnsureCreated().	When this is weak, database schema changes are not handled through versioned migrations, so updating an existing database safely becomes a manual, risky operation.	tool
`P9`	Domain vs controller coveragemeta	Whether test coverage concentrates on the domain (business rules) rather than the trivial web/controller layer — a focus check a generic tool can't make.	When this is weak, the tests focus on the trivial web layer instead of the business rules, so the parts that matter most to your operation are the least verified.	tool
`P10`	Library API & versioningmeta	For a library: a deliberate (small) public API surface and explicit semantic versioning so consumers can depend on it safely.	When this is weak, a library exposes a large, undisciplined public surface with no clear versioning, so consumers cannot depend on it without risking breakage on every update.	tool
`P11`	BDD / executable specsmeta	Whether behaviour is captured as executable Gherkin specifications (a plus for shared understanding) — only assessed when a BDD framework is present.	When this is weak, the project does not capture behaviour as executable specifications, so the shared, business-readable description of how the system should behave is missing.	tool
`P12`	CI test-gate honestymeta	Whether the CI gate executes the test inventory it appears to have: excluded suites, skipped tests, and coverage collected without a threshold.		tool
`R4`	Test Coveragemeta	Static test reachability (D-386): the share of production files reachable from any test via the import graph — measured without running anything.	When this is weak, large parts of the frontend are not reachable from any test, so changes there can break behaviour with nothing to catch it.	tool
`R5`	Dependency Freshnessmeta	How outdated the npm dependencies are (a maturity signal). JS/npm CVEs are scored separately in D33 (JS/npm Dependency Vulnerabilities).	When this is weak, the npm dependencies are well out of date, so the project drifts further from current, supported versions and upgrades grow harder over time.	tool
`R6`	Toolingmeta	Whether the project wires up test, lint and typecheck — detected from each package.json script's COMMAND (eslint / tsc / vitest / jest / playwright), not just its name, and corroborated against CI-workflow invocations so a tool run only in CI still counts.	When this is weak, the frontend has no wired-up test, lint and typecheck scripts, so quality checks are not part of the normal workflow and are easily skipped.	tool
`R8`	Dependency Hygienemeta	npm dependency truthfulness (D-386): unused dependencies, imports not declared anywhere, and type-/test-only packages shipped as production deps.	When this is weak, the npm dependencies are not truthful — unused packages, undeclared imports, dev-only packages shipped as production — so the dependency list cannot be trusted and builds are fragile.	tool