The DORA research program — originally at Google, now ongoing as the annual Accelerate State of DevOps Report — established four metrics as the industry's most reliable leading indicators of software delivery performance:
- Deployment frequency — how often you deploy to production.
- Lead time for changes — how long a commit takes to reach production.
- Change failure rate — what percentage of changes cause a production incident.
- Mean time to restore (MTTR) — how long it takes to recover from an incident.
CARL references DORA explicitly at Level 3 — Reviewed (DLM-050). The two
frameworks are complementary: DORA measures delivery outcomes; CARL measures
whether the engineering substrate is ready to produce good outcomes.
The short version
- DORA → outcome metrics. "How fast and safely is this team shipping?"
- CARL → substrate readiness. "Does this codebase have the scaffolding that supports good DORA outcomes?"
A team with strong DORA metrics almost certainly passes the CARL Delivery & Measurement criteria. A team with poor DORA metrics almost certainly fails one or more. The correlation is strong but not perfect — teams can have elaborate scaffolding and still deliver slowly, and teams can deliver fast without much scaffolding (until their first incident).
The direct reference
CARL Standard v1.0 includes DLM-050 (DORA metrics captured) at Level 3 —
Reviewed:
DLM-050: DORA metrics captured. The four DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) are measured and reviewed.
A subject cannot claim CARL L3 Reviewed without instrumenting DORA. The reference to DORA is normative in the catalog, not just illustrative.
What CARL's Delivery & Measurement pillar includes beyond DORA
DORA produces metrics; CARL's Delivery pillar requires the mechanisms that produce the metrics and the gates that act on them:
DLM-010— CI runs every gate on every PR.DLM-020— Deployment pipeline documented with rollback.DLM-030— Deploy previews on PRs.DLM-040— CI feedback time instrumented (target p50 < 10min).DLM-050— DORA metrics captured (the reference point).DLM-060— Product analytics stubbed (disabled by default, wired for flip-on).DLM-070— Self-improving gates (automated remediation PRs at L4 Agent-driven).
Using them together
A pragmatic adoption path:
- Implement the CARL L1 / L2 Delivery criteria first. You need CI, deploy previews, and a documented pipeline before DORA measurements are meaningful.
- Instrument DORA. Most modern CI / deployment platforms expose the events needed (deploys, incidents). Services like DevLake or LinearB aggregate them.
- Review the metrics on a cadence. Weekly or monthly is fine for most teams. The act of reviewing is the improvement lever; the exact numbers matter less than the trend.
- Re-assess CARL every 90 days. Your L3 Reviewed claim depends on DORA actually being captured and reviewed, not just on the tooling being installed.
DORA's Elite / High / Medium / Low tiers
DORA publishes performance tiers (Elite, High, Medium, Low) with numeric thresholds for each metric. These are outcome thresholds, not readiness thresholds. A CARL L3 Reviewed subject is the kind of codebase that can reach DORA Elite with sustained investment; it doesn't guarantee Elite metrics today.
Is CARL replacing DORA
No. DORA is an established, widely-cited metric set. A team shipping real software should measure DORA because the metrics correlate with commercial outcomes. CARL measures whether the codebase substrate is ready to support strong DORA metrics — a different question answered with different evidence.
If you only have capacity for one, measure DORA first on production systems and CARL first on new projects. The two together are strictly more informative than either alone.
Related
- The Delivery & Measurement pillar — the CARL pillar that cites DORA directly.
- Criteria catalog — full
DLM-criterion definitions, includingDLM-050. - vs. SLSA and OpenSSF Scorecard — another set of complementary frameworks CARL references and incorporates as evidence.