Pillar — Delivery & Measurement

Prefix: DLM- Catalog: v1.1 deltas (additive to v1.0 Delivery & Measurement). What it measures: whether an agent can ship one slice of a product portfolio, prove the ship worked, and read DORA for the whole subject — without waiting on unrelated applications or reconstructing metrics from chat.

v1.0 already covers full CI gates, a documented promotion path, deploy previews, CI feedback time, DORA capture, product-analytics stubs, and self-improving gates. These v1.1 criteria close the gaps that appear once the scoring unit is a portfolio of applications that share a pipeline.

Criteria in this pillar

DLM-100 — Affected-slice CI required

Level: 3 · Scope: portfolio · Check: deterministic
A change under one application runs the full gate set for that application and MUST NOT require unrelated applications to rebuild as a condition of merge. Shared-library changes run the gate set for every documented dependent.
Rationale: DLM-010's "every gate on every PR" is correct for a single application and becomes a fleet-wide wait when the subject is a portfolio. Agents blocked on unrelated red jobs either skip the gate or wait hours.
Evidence expected: a path filter or affected-graph in CI; a single-application PR's required jobs are only that application plus shared packages it touches; absence of a required "all applications" job except for the documented dependents of a library change.

DLM-110 — Preview environments isolated per application

Level: 3 · Scope: application · Check: deterministic
Pull-request previews (DLM-030) serve only the changed application (plus its declared dependencies) against isolated data. A preview MUST NOT mutate a sibling application's store, queue, or production-like shared resource.
Rationale: a shared preview database is how a portfolio review of one slice silently corrupts another. Agents cannot treat a preview as evidence if it is coupled to a neighbour.
Evidence expected: preview config names the application and an isolated store; a documented prohibition on shared writable resources; a recent preview URL resolves only that application.

DLM-120 — Promotion fails closed on health

Level: 4 · Scope: application · Check: deterministic
Staging-to-production promotion (DLM-020) queries the application's health endpoint and current error-rate (or error-budget) signal. Promotion is blocked when health is failing or the error budget is already exhausted. Rollback is a documented, runnable path from the same pipeline.
Rationale: documenting a rollback path is not the same as refusing to ship into an already-burning service. Agents will promote on a green unit suite unless the pipeline itself stops them.
Evidence expected: promotion job calls health (OBS-040) before cutover; a failing health check fails the job; rollback command or workflow is invoked from the same pipeline definition.

DLM-130 — Deploy outcomes recorded

Level: 4 · Scope: application · Check: deterministic
Every production deploy writes a machine-readable outcome (success, failed, rolled_back) with start time, finish time, git SHA, and application identifier. Change-failure rate and lead time are computed from this log, not from a slide.
Rationale: DLM-050 asks that DORA metrics exist; without a deploy log they are reconstructed from chat. Agents cannot learn from "how often did this slice fail" unless the outcome is an artifact.
Evidence expected: deploy log or release records for the last 30 days; fields include SHA, application, outcome, timestamps; CFR and lead time queries documented against that log.

DLM-140 — Portfolio DORA published

Level: 4 · Scope: portfolio · Check: manual
The four DORA metrics are visible for the portfolio as k/n applications, not as a single blended number that hides a lagging slice. A newly added application is on the dashboard within one review cadence or is marked not_applicable with a one-line justification.
Rationale: portfolio scope is the scoring unit (CSPC-31). A green application next to a never-deployed one is not an agent-ready product.
Evidence expected: dashboard or report showing per-application DORA plus k/n; review cadence stated; not_applicable entries justified.

v1.0 Delivery & Measurement — the published DLM-010 through DLM-070 criteria.
v1.1 pillars — draft catalog, including these deltas and the six new pillar stubs.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 3 · Scope: portfolio · Check: deterministic

A change under one application runs the full gate set for that application and MUST NOT require unrelated applications to rebuild as a condition of merge. Shared-library changes run the gate set for every documented dependent.

Rationale: DLM-010's "every gate on every PR" is correct for a single application and becomes a fleet-wide wait when the subject is a portfolio. Agents blocked on unrelated red jobs either skip the gate or wait hours.

Evidence expected: a path filter or affected-graph in CI; a single-application PR's required jobs are only that application plus shared packages it touches; absence of a required "all applications" job except for the documented dependents of a library change.

Level: 3 · Scope: application · Check: deterministic

Pull-request previews (DLM-030) serve only the changed application (plus its declared dependencies) against isolated data. A preview MUST NOT mutate a sibling application's store, queue, or production-like shared resource.

Rationale: a shared preview database is how a portfolio review of one slice silently corrupts another. Agents cannot treat a preview as evidence if it is coupled to a neighbour.

Evidence expected: preview config names the application and an isolated store; a documented prohibition on shared writable resources; a recent preview URL resolves only that application.

Level: 4 · Scope: application · Check: deterministic

Staging-to-production promotion (DLM-020) queries the application's health endpoint and current error-rate (or error-budget) signal. Promotion is blocked when health is failing or the error budget is already exhausted. Rollback is a documented, runnable path from the same pipeline.

Rationale: documenting a rollback path is not the same as refusing to ship into an already-burning service. Agents will promote on a green unit suite unless the pipeline itself stops them.

Evidence expected: promotion job calls health (OBS-040) before cutover; a failing health check fails the job; rollback command or workflow is invoked from the same pipeline definition.

Level: 4 · Scope: application · Check: deterministic

Every production deploy writes a machine-readable outcome (success, failed, rolled_back) with start time, finish time, git SHA, and application identifier. Change-failure rate and lead time are computed from this log, not from a slide.

Rationale: DLM-050 asks that DORA metrics exist; without a deploy log they are reconstructed from chat. Agents cannot learn from "how often did this slice fail" unless the outcome is an artifact.

Evidence expected: deploy log or release records for the last 30 days; fields include SHA, application, outcome, timestamps; CFR and lead time queries documented against that log.

Level: 4 · Scope: portfolio · Check: manual

The four DORA metrics are visible for the portfolio as k/n applications, not as a single blended number that hides a lagging slice. A newly added application is on the dashboard within one review cadence or is marked not_applicable with a one-line justification.

Rationale: portfolio scope is the scoring unit (CSPC-31). A green application next to a never-deployed one is not an agent-ready product.

Evidence expected: dashboard or report showing per-application DORA plus k/n; review cadence stated; not_applicable entries justified.