CARL defines seven staged maturity levels (0–6). Levels 0–4 describe a codebase's agent-readiness as it exists today — from a manual repository up to one an agent can drive end-to-end. Levels 5–6 are deliberately aspirational, beyond today's AI, where the agent doesn't just work inside a codebase but creates and runs a business around it. A subject is assigned exactly one level; there are no partial level scores. The interpretation below is normative — the assigned level carries meaning across every CARL assessment, for every subject, at every point in time.
The seven levels
| Level | Name | Interpretation |
|---|---|---|
| L0Manual | Manual | No automation. Builds, tests, and releases are run by hand; the codebase has no machine-readable contract an agent could rely on. |
| L1Scripted | Scripted | Repeatable scripts exist (build, lint, deploy), but they are undocumented and assume a human in the driver seat. |
| L2Tested | Tested | A meaningful automated test suite gates changes, giving an agent a verifiable signal that an edit did not break behaviour. |
| L3Reviewed | Reviewed | Documented invariants, deterministic builds, and review gates let an agent propose changes a human can confidently approve. |
| L4Agent-driven | Agent-driven | An agent can take a scoped task and drive it end-to-end — read the contracts, change the code, prove it green, and ship — with a human supervising rather than steering. |
| L5Creates a business | Creates a business | Beyond today's AI. The agent goes from a goal to a launched product — standing up the codebase, the infrastructure, and the go-to-market — turning an idea into a live, revenue-capable business. |
| L6Runs a business | Runs a business | Beyond today's AI. The top of the ladder. The agent operates the business it created — adapting to the market, managing the books, and steering strategy as conditions drift, with humans setting intent. |
Per-level pages
Gated progression
To be assigned Level N, a subject MUST pass at least 80% of the criteria at Level N and all prior levels, applicability-adjusted. Criteria marked not applicable are excluded from both numerator and denominator. The gating is uniform and cumulative down the 0–6 chain — an L4 subject must satisfy the L4 rule and the L3, L2, L1, and L0 rules all simultaneously, just as an L3 subject must clear L3, L2, L1, and L0.
Why 80%, not 100%
Real codebases carry context that a fixed rubric cannot perfectly anticipate. Some criteria will be genuinely inapplicable; some will be arguably inapplicable; a minority may be tactically deferred. The 80% rule accepts that reality while still requiring a demonstrably strong posture at each level.
Why 80%, not 60%
A lower threshold would let too many subjects claim a level they cannot operationally support. Agents arriving at an L3 subject should be able to assume that at least 4 out of 5 L3-criteria are genuinely in place. The 80% floor makes that assumption safe enough to act on.
Scope
Levels are assigned at one of three scopes:
- Repository scope. Evaluated once across the entire subject. Example:
branch protection rules exist on
main. - Application scope. Evaluated per application. In a monorepo with multiple
applications, application-scope criteria are reported as
k/nwith per-application detail. Example: the linter runs cleanly for each application. - Organization scope. Evaluated across multiple repositories owned by the same organization. Example: secret scanning is enabled at the org level.
See /guides/monorepo-setup/ for how CARL
handles monorepos in practice.
Related sections
- Criteria catalog — the full list of criteria, grouped by pillar and level.
- Assessment methodology — assessor types, applicability marking, and reassessment cadence.
- vs. CMMI — where CARL's staged model maps to CMMI and where it differs.