CARL organises criteria into eight capability pillars. Each criterion belongs to exactly one pillar. Pillars are not weighted against each other; every pillar has criteria at every level, and a subject must make progress across all pillars to advance.

Pillars at a glance

The eight pillars

Why eight pillars

Earlier drafts explored a smaller set (five pillars) and a larger one (twelve). Eight was the smallest set that let every L1-through-L5 axis of common agent-era dysfunction show up somewhere without forcing several unrelated concerns into the same bucket. The pillars are stable and intended to remain stable across CARL minor versions; a rename or split would require a major version bump to the standard.

Pillar overviews

Documentation & Knowledge (DOC-)

The agent-readiness pillar that most often distinguishes a usable codebase from an unusable one. An agent spawned into a well-documented repository reads the README, the AGENTS.md, and the env reference, then proceeds with a correct mental model. An agent in an undocumented repository has to infer conventions from scattered files, which is slow, error-prone, and produces inconsistent results across sessions.

Representative criteria include DOC-010 (README substantive), DOC-030 (AGENTS.md or CLAUDE.md present), DOC-040 (environment variables documented), DOC-050 (ADR folder), and DOC-080 (changelog in Keep-a-Changelog format).

Code Quality & Validation (CQV-)

Automated checks that run before tests. Linters prevent whole classes of mistakes. Type checkers (TypeScript strict mode, mypy strict, Rust's borrow checker) catch bugs at author time. Formatters remove style debates from code review. Pre-commit hooks make all of the above automatic so nobody needs to remember.

Representative criteria include CQV-010 (linter configured and runnable), CQV-030 (strict-mode types), CQV-040 (pre-commit hooks enforce format and lint), and CQV-050 (no forbidden escape hatches like @ts-ignore without a tracked issue).

Testing (TST-)

The pillar agents rely on most directly to verify their own changes. Without tests, an agent either assumes its work is correct (it often isn't) or re-reads the diff forever. A fast, comprehensive, low-flake test suite is the single biggest leverage point for agent effectiveness at L2 and above.

Representative criteria include unit and integration coverage, E2E coverage of critical user journeys, documented coverage thresholds, and explicit flake-detection or quarantine mechanisms at higher levels.

Build & Environment (BLD-)

Can an agent reproduce the build? Can an agent bootstrap a fresh environment from main without a human walking it through the process? .nvmrc or .tool-versions, .env.example, a bootstrap script, a devcontainer or Nix definition, a deterministic package manager lockfile — each of these removes an avenue of environment drift.

Representative criteria cover pinned runtime versions, committed lockfiles, devcontainer or equivalent environment definition, and deterministic build output.

Observability (OBS-)

Agents that can't see what they changed can't learn from what they changed. A codebase with structured logging, distributed tracing, and error aggregation gives agents a feedback loop: change, deploy (or test), observe, learn. Without observability, agents degrade into open-loop systems — write code, ship, hope.

Representative criteria include structured logging (not raw console.log), a tracing instrumentation, an error reporter, and a health endpoint.

Security & Access Control (SEC-)

Protecting the codebase from accidents and from malice. Branch protection prevents force-pushes and direct merges to main. Secret scanning catches the occasional committed credential. Dependency scanning catches the occasional vulnerable package. CODEOWNERS routes PRs to the right reviewers. At L4 and above, SBOM and supply-chain provenance become expected.

Representative criteria include SEC-010 (branch protection on default branch), SEC-020 (secret scanning), SEC-030 (CODEOWNERS present and routes correctly), and SEC-040 (dependency scanning enabled).

Task Intake & Routing (TIR-)

How work enters the repository. Issue templates give agents a structured way to file bugs and feature requests. PR templates ensure every change carries the metadata reviewers (human or agent) need to evaluate it. Labels and triage conventions make the backlog navigable.

Representative criteria include issue templates per incident class, a PR template with a clear checklist, a labelling convention, and a stated triage SLA at higher levels.

Delivery & Measurement (DLM-)

How the codebase ships, and how it knows whether shipping worked. At L2, delivery is usually manual with CI as the gate. At L3, deployment is automated. At L4, the four DORA metrics — deployment frequency, lead time for changes, change failure rate, time to recovery — are instrumented and visible. At L5, the deployment pipeline itself can roll back automatically when signals degrade.

Representative criteria include a documented CI feedback time target, a rollback mechanism, DORA metric instrumentation at L4, and automated progressive-rollout capability at L5.

Related

• Criteria catalog — the full list of v1.0 criteria grouped by pillar.
• Report format — how pillar scores are encoded in conformance reports.