Pillar — Resilience

Prefix: RES- Catalog: v1.1 (new pillar). What it measures: whether an unattended system can fail and recover — backup, restore, degradation paths, and documented failure handling an agent can follow without paging a human for every outage.

An agent that runs a business will cause and inherit failures. Resilience is how the business survives them. There is no v1.0 RES catalog; IDs in the RES-1xx band are the first published criteria for this dimension.

Criteria in this pillar

RES-100 — Backup scheduled and owned

Level: 2 · Scope: application · Check: deterministic
Each stateful store the application owns has a scheduled backup, a named owner, and a retention that meets the published recovery-point objective. Backups that have never been listed, or that exist only as a platform default with no owner, do not satisfy this criterion.
Rationale: an agent that writes state will eventually need yesterday's copy. A backup nobody can name, schedule, or retain to the recovery-point objective is not a backup an assessor — or the next incident — can use.
Evidence expected: backup config or job for each stateful store; owner and retention present; recovery-point objective stated; a recent successful backup listed.

RES-110 — Restore drill recorded

Level: 3 · Scope: application · Check: deterministic
A restore from backup has been run within the review cadence, with start time, finish time, outcome, and time-to-recover recorded. An untested backup does not satisfy this criterion. A tabletop discussion without a restore artifact is not a drill.
Rationale: RES-100 proves a copy exists; it does not prove the copy can come back. Agents cannot treat "we have backups" as recovery unless a drill has produced a time and an outcome.
Evidence expected: drill record for the last cadence; fields include store, timestamps, outcome, and time-to-recover; the restored artifact or a signed log that the restore was exercised.

RES-120 — Degradation path published

Level: 3 · Scope: application · Check: deterministic
When a named dependency is unavailable, the application has a documented degraded mode (queue, serve stale, read-only, or fail closed) an agent can follow without paging a human for the first hour. "Try again later" with no mode does not satisfy this criterion.
Rationale: unattended operators inherit brownouts. Without a published mode, the agent will retry, page, or write into a half-available store. The first hour of a dependency outage has to be a runbook, not a conversation.
Evidence expected: a committed degradation table mapping dependency to mode and owner; at least one mode other than "page immediately" for a non-critical dependency; a recent incident or game-day note that followed the table, or a test that asserts the mode.

RES-130 — Dependency failure is bounded

Level: 4 · Scope: application · Check: deterministic
Outbound calls have a bounded retry, a circuit or equivalent stop, and an error that surfaces on the application's health or error-rate signal. Unlimited retry, swallowed errors, or a hang until timeout-of-the-host does not satisfy this criterion.
Rationale: infinite retry is how one slow dependency takes down the slice. Agents copy the client that "just works" in the happy path. A bound and a visible failure are what keep a brownout from becoming a fleet outage.
Evidence expected: retry/circuit config or equivalent in the outbound client; a failing dependency trips the stop; health or error-rate (OBS) reflects the failure; a test or recent incident showing the bound fired.

RES-140 — Portfolio RTO and RPO published as k/n

Level: 4 · Scope: portfolio · Check: manual
Recovery-time and recovery-point objectives are visible per application as k/n applications meeting their published targets. A blended portfolio number that hides a slice with no objective does not satisfy this criterion. A newly added application is on the view within one review cadence or is marked not_applicable with a one-line justification.
Rationale: one recoverable application next to an unbacked neighbour is not an agent-ready product. Portfolio scope (CSPC-31) is the scoring unit.
Evidence expected: dashboard or report with per-application RTO, RPO, and k/n; cadence stated; not_applicable entries justified (stateless applications may use this mark when they own no store).

v1.1 pillars — draft catalog, including these RES-1xx criteria.
v1.1 Observability — health and error-rate signals RES-130 surfaces into.
v1.1 Delivery & Measurement — health-gated promotion and recorded deploy outcomes.
v1.0 specification — the published standard.

Criteria in this pillar

Level: 2 · Scope: application · Check: deterministic

Each stateful store the application owns has a scheduled backup, a named owner, and a retention that meets the published recovery-point objective. Backups that have never been listed, or that exist only as a platform default with no owner, do not satisfy this criterion.

Rationale: an agent that writes state will eventually need yesterday's copy. A backup nobody can name, schedule, or retain to the recovery-point objective is not a backup an assessor — or the next incident — can use.

Evidence expected: backup config or job for each stateful store; owner and retention present; recovery-point objective stated; a recent successful backup listed.

Level: 3 · Scope: application · Check: deterministic

A restore from backup has been run within the review cadence, with start time, finish time, outcome, and time-to-recover recorded. An untested backup does not satisfy this criterion. A tabletop discussion without a restore artifact is not a drill.

Rationale: RES-100 proves a copy exists; it does not prove the copy can come back. Agents cannot treat "we have backups" as recovery unless a drill has produced a time and an outcome.

Evidence expected: drill record for the last cadence; fields include store, timestamps, outcome, and time-to-recover; the restored artifact or a signed log that the restore was exercised.

Level: 3 · Scope: application · Check: deterministic

When a named dependency is unavailable, the application has a documented degraded mode (queue, serve stale, read-only, or fail closed) an agent can follow without paging a human for the first hour. "Try again later" with no mode does not satisfy this criterion.

Rationale: unattended operators inherit brownouts. Without a published mode, the agent will retry, page, or write into a half-available store. The first hour of a dependency outage has to be a runbook, not a conversation.

Evidence expected: a committed degradation table mapping dependency to mode and owner; at least one mode other than "page immediately" for a non-critical dependency; a recent incident or game-day note that followed the table, or a test that asserts the mode.

Level: 4 · Scope: application · Check: deterministic

Outbound calls have a bounded retry, a circuit or equivalent stop, and an error that surfaces on the application's health or error-rate signal. Unlimited retry, swallowed errors, or a hang until timeout-of-the-host does not satisfy this criterion.

Rationale: infinite retry is how one slow dependency takes down the slice. Agents copy the client that "just works" in the happy path. A bound and a visible failure are what keep a brownout from becoming a fleet outage.

Evidence expected: retry/circuit config or equivalent in the outbound client; a failing dependency trips the stop; health or error-rate (OBS) reflects the failure; a test or recent incident showing the bound fired.

Level: 4 · Scope: portfolio · Check: manual

Recovery-time and recovery-point objectives are visible per application as k/n applications meeting their published targets. A blended portfolio number that hides a slice with no objective does not satisfy this criterion. A newly added application is on the view within one review cadence or is marked not_applicable with a one-line justification.

Rationale: one recoverable application next to an unbacked neighbour is not an agent-ready product. Portfolio scope (CSPC-31) is the scoring unit.

Evidence expected: dashboard or report with per-application RTO, RPO, and k/n; cadence stated; not_applicable entries justified (stateless applications may use this mark when they own no store).