Pillar — Delivery & Measurement

Prefix: DLM- What it measures: how the codebase ships, and how it knows whether shipping worked — CI gates on every PR, documented deployment pipeline, deploy previews, CI feedback time, DORA metrics, product-analytics stubbing, and self-improving orchestration at L5.

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.

Criteria in this pillar

DLM-010 — CI runs every gate on every PR

Level: 2 · Scope: repository · Check: deterministic
.github/workflows/ci.yml (or equivalent) runs lint, format:check, typecheck, test (with coverage), build, and audit on every PR.
Rationale: partial gates are a false sense of safety; agents rely on the gate set being complete to validate their output.
Evidence expected: workflow inspection; gates enumerated.

DLM-020 — Deployment pipeline documented

Level: 3 · Scope: application · Check: deterministic
A staging → production promotion is documented, with an explicit rollback path, in docs/runbook.md or the CI config.
Rationale: agents making risky changes need to know how to unwind them quickly.
Evidence expected: documentation; release workflow with environment promotion.

DLM-030 — Deploy previews on PRs

Level: 3 · Scope: application · Check: deterministic
Pull requests produce an isolated preview URL (Vercel, Cloudflare Pages, Netlify previews, or equivalent).
Rationale: reviewing a live preview is the difference between catching a regression and shipping one.
Evidence expected: preview URL comments on recent PRs.

DLM-040 — CI feedback time instrumented

Level: 4 · Scope: repository · Check: manual
Median CI duration is tracked and kept below 10 minutes for typical PRs.
Rationale: slow CI compounds: agents can run fewer iterations per day, and humans context-switch.
Evidence expected: metrics dashboard or CI timing data over the last 30 days.

DLM-050 — DORA metrics captured

Level: 4 · Scope: organization · Check: manual
The four DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) are measured and reviewed.
Rationale: DORA is the industry-standard leading indicator of delivery health; agents should have access to the same signals humans do.
Evidence expected: dashboard or report; cadence of review.

DLM-060 — Product analytics stubbed

Level: 3 · Scope: application · Check: deterministic
A product-analytics client is stubbed in (lib/telemetry/analytics.ts or equivalent) — disabled by default but wired so that enabling it is a config flip.
Rationale: agents cannot reason about user impact without behavioral data; retrofitting analytics is painful.
Evidence expected: analytics module present; feature flag controls it.

DLM-070 — Self-improving gates

Level: 5 · Scope: organization · Check: manual
Orchestration exists that can auto-propose remediations for failing CARL criteria (e.g., an agent that opens a PR to add an AGENTS.md when DOC-030 fails).
Rationale: Level 5 is the level at which the system measurably improves itself. Automation is both signal and mechanism.
Evidence expected: automation config; history of merged auto-remediation PRs.

The 8 pillars — sibling pillars in v1.0.
Criteria catalog — all criteria, one page.
Maturity levels — how criteria combine into a level.

Criteria in this pillar

Level: 2 · Scope: repository · Check: deterministic

.github/workflows/ci.yml (or equivalent) runs lint, format:check, typecheck, test (with coverage), build, and audit on every PR.

Rationale: partial gates are a false sense of safety; agents rely on the gate set being complete to validate their output.

Evidence expected: workflow inspection; gates enumerated.

Level: 3 · Scope: application · Check: deterministic

A staging → production promotion is documented, with an explicit rollback path, in docs/runbook.md or the CI config.

Rationale: agents making risky changes need to know how to unwind them quickly.

Evidence expected: documentation; release workflow with environment promotion.

Level: 3 · Scope: application · Check: deterministic

Pull requests produce an isolated preview URL (Vercel, Cloudflare Pages, Netlify previews, or equivalent).

Rationale: reviewing a live preview is the difference between catching a regression and shipping one.

Evidence expected: preview URL comments on recent PRs.

Level: 4 · Scope: repository · Check: manual

Median CI duration is tracked and kept below 10 minutes for typical PRs.

Rationale: slow CI compounds: agents can run fewer iterations per day, and humans context-switch.

Evidence expected: metrics dashboard or CI timing data over the last 30 days.

Level: 4 · Scope: organization · Check: manual

The four DORA metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore) are measured and reviewed.

Rationale: DORA is the industry-standard leading indicator of delivery health; agents should have access to the same signals humans do.

Evidence expected: dashboard or report; cadence of review.

Level: 3 · Scope: application · Check: deterministic

A product-analytics client is stubbed in (lib/telemetry/analytics.ts or equivalent) — disabled by default but wired so that enabling it is a config flip.

Rationale: agents cannot reason about user impact without behavioral data; retrofitting analytics is painful.

Evidence expected: analytics module present; feature flag controls it.

Level: 5 · Scope: organization · Check: manual

Orchestration exists that can auto-propose remediations for failing CARL criteria (e.g., an agent that opens a PR to add an AGENTS.md when DOC-030 fails).

Rationale: Level 5 is the level at which the system measurably improves itself. Automation is both signal and mechanism.

Evidence expected: automation config; history of merged auto-remediation PRs.