AI Continuity Ladder: A Graceful Degradation Playbook

Version: 1.1
Editorial review: 4 September 2026
Scope: cloud and internal models, agentic and non-agentic workflows, and individual work with AI tools.

AI Continuity Ladder, Context Capsule and the scales below are Methodfield's synthesis. They draw on business continuity, AI risk management and reliability engineering; they are not part of ISO or NIST standards.

1. Purpose

Preserve acceptable work when a primary provider fails, quality regresses, context cannot transfer safely or human review becomes overloaded.

The objective is not uninterrupted generation. It is the maximum useful work that remains inside agreed quality, data and authority boundaries.

Read the companion analysis first if the distinction between an alternative model and an alternative operating mode is new to the team.

2. Seven principles

1. The workflow owns state; the model performs a bounded operation.
2. A reserve is a demonstrated capability, not a model name.
3. Authority follows task-specific evidence.
4. Degraded modes are designed before an incident.
5. An unexercised reserve is unproven.
6. A safe stop takes precedence over an unsupported answer.
7. Recovery is gradual and includes state reconciliation.

3. Measures and continuity objectives

Good Completion Rate =
  tasks completed on time, passing quality, context and policy
  ----------------------------------------------------------
                    all eligible tasks

Fix the denominator before disruption. Do not count queueing or stopping as successful completion unless the task contract already defines a justified refusal as the correct outcome.

Also record unsafe continuations, correct stops, review hours, queue age, time to the correct mode, duplicate effects and regressions after restoration.

Set these targets per workflow:

• MTPD-AI: maximum tolerable disruption of the AI-supported function;
• RTO-AI: target time to an acceptable operating mode;
• RPO-context: acceptable loss of confirmed state;
• Minimum Business Capacity: useful throughput in the reduced mode;
• Maximum Human Queue: limit triggering prioritisation, load reduction or stop.

These are adapted operating labels. Different processes need different targets; do not copy another team's numbers without impact analysis.

4. Classify the task

Assess consequences, reversibility, external effects and data sensitivity. A critical factor cannot disappear inside an average score. Data sensitivity also independently determines permitted processing environments.

Assign T classes through a documented policy. The examples below are starting points, not an automatic scoring formula or legal classification.

A draft and its publication are different operations. A qualified human owns the policy ceiling and any applicable specialist review.

5. Build a capability passport

Treat each combination of provider, model/version, configuration, prompt adapter and tool set as a separate system under test.

For analytical writing, an illustrative score might weight factual evidence at 30%, completeness at 20%, constraints and tool/schema correctness at 15% each, language at 10%, repeatability at 5% and latency/cost at 5%.

Hard gates run first. Disallowed data disclosure cannot be offset by good writing. The weights are examples, not a universal rubric.

Use readiness states:

• Unapproved: no production use.
• Shadow: approved inputs only; outputs cannot affect the result.
• Canary: a bounded low-risk share under enhanced review.
• Warm reserve: routinely exercised and ready for agreed load.
• Primary eligible: qualified for a named task family.
• Expired: re-evaluation required after change or elapsed review period.

6. Authority levels

Allowed Authority = min(
  Task Policy Ceiling,
  Model Capability Ceiling,
  Context Integrity Ceiling,
  Current Health Ceiling,
  Human Capacity Ceiling
)

The minimum is a policy design rule, not an arithmetic quality score. Unavailable mandatory reviewers lower the permitted operating mode; they never justify skipping approval.

7. Operating modes

An internal model can qualify for M0 or M1. Hosting location does not determine mode. M3 does not automatically require dual control for every safe rule-based operation.

Transitions need not visit every step. Critical failures go directly to M4. Degrade only the affected task or workflow when isolation is demonstrably safe.

8. Context Capsule

The capsule is a normalised record of verified state, not hidden reasoning. The following is an illustrative JSON record, not an executable JSON Schema. Define required fields, enums, version migration and reference integrity in the implementation. IDs below are fictional.

{
  "schema_version": "1.1",
  "work_id": "example-case-0042",
  "checkpoint_id": "cp-00017",
  "owner": "role:service-supervisor",
  "task": {
    "family": "customer-refund-review",
    "risk_class": "T3",
    "objective": "Prepare a decision packet; do not issue refund",
    "definition_of_done": [
      "order and policy evidence linked",
      "uncertainties listed",
      "human decision recorded"
    ]
  },
  "policy": {
    "version": "refund-v4",
    "max_authority": "A2",
    "data_class": "personal-confidential",
    "allowed_providers": ["approved-provider-a", "internal-model-b"],
    "forbidden_actions": ["send-message", "issue-refund"]
  },
  "facts": [
    {
      "claim": "Delivery was later than promised",
      "source": "crm://example/orders/4815/events/9",
      "status": "verified"
    }
  ],
  "decisions": [
    {
      "decision": "Escalate because amount exceeds threshold",
      "approved_by": "policy:refund-v4"
    }
  ],
  "tool_ledger": [
    {
      "tool": "read-order",
      "idempotency_key": "example-case-0042-read-order-1",
      "status": "succeeded",
      "result_ref": "artifact://example/order-v3.json"
    }
  ],
  "artifacts": [
    {
      "uri": "artifact://example/decision-packet.md",
      "sha256": "<actual-hash-required>",
      "status": "draft"
    }
  ],
  "open_questions": ["Was there a carrier exception?"],
  "next_safe_action": "Retrieve the approved carrier event log",
  "runtime": {
    "previous_model": "provider-a/model-x@pinned-version",
    "mode": "M2",
    "authority": "A1",
    "trace_id": "<actual-trace-id-required>"
  }
}

Implementation rules:

• checkpoint confirmed decisions and retain the source of each approval;
• record intent before an external action and its confirmed result afterward;
• reconcile ambiguous action results with the system of record before retrying;
• separate verified, model-proposed, human-approved and rejected information;
• retain version/hash references for artifacts, policies and adapters;
• encrypt and restrict access; minimise copied sensitive data;
• validate structure and referenced artifacts before handoff;
• use version checks, locks or fencing against concurrent executors;
• treat source text as data, not instructions; load permissions from trusted policy;
• represent missing facts as unknown rather than filling gaps by inference.

A syntactically valid JSON record can still contain false facts or stale permissions. Structure, evidence and authorisation require separate checks.

9. Reference architecture

Client / Trigger
      |
Task classifier -----> Policy registry
      |
Continuity router ---> Capability registry + Evaluation service
      |
Provider adapters ---> Qualified cloud / internal models
      |
Output validator
      |
Tool policy gateway -> Business systems of record
      |
      +--------------> Durable workflow + Context Capsule store
      +--------------> Human decision queue
      +--------------> Audit log + traces

The router does not grant business authority. Every production tool call passes schema, access, policy and idempotency checks. The context store and policy service are dependencies too: test their failure domains separately. Provider status pages are corroborating signals, not substitutes for probes of the actual user path.

10. Transition logic

Observe latency, errors, quota, schema/tool correctness, evidence quality, context validation, human overrides and forecast queue time.

NORMAL -> SUSPECT       bounded transport or quality signal
SUSPECT -> NORMAL       checks recover
SUSPECT -> DEGRADED     configured threshold reached
DEGRADED -> M1 / M2     approved reserve and canary pass
DEGRADED -> M3 / M4     no suitable model
M1 / M2 / M3 -> RECOVERY stable primary and shadow comparison
RECOVERY -> NORMAL     stability window passes
RECOVERY -> SAFE MODE  regression appears

ANY STATE -> M4         permission, integrity or critical hard gate fails

Calibrate thresholds to the workflow's SLO. Three timeouts or an excessive error-budget burn rate over five minutes might trigger investigation; a 10–15-minute stable window might precede recovery. These are illustrative, not settings to copy into a high-consequence system.

One layer owns retry policy for the whole chain. Use bounded exponential backoff, jitter, deadline and maximum attempts. Do not repeat invalid requests, permission failures or policy rejections. Check action identity before any consequential retry.

11. Human oversight as operating capacity

H levels describe control mechanisms, not a mandatory increasing sequence for every operating mode. Risk policy may require H2 or H3 even in M0.

Minimum reviewer estimate =
  review tasks per hour × mean review minutes
  ------------------------------------------
    productive minutes per reviewer per hour

Use the mean, not the median, for expected workload. This is a lower-bound staffing estimate, not a queue-delay guarantee. Account for burst arrivals, long cases, breaks and utilisation below 100%.

If capacity is insufficient, prioritise, reduce intake or queue with an honest deadline. Do not make approval a formality.

The review screen should show evidence, proposed changes, mode, model, limitations, previous actions and consequences. A bare Approve button is not an adequate control.

12. Game day

Write a measurable hypothesis. For example:

During simulated primary-model loss, 95% of T0–T1 tasks complete within ten minutes in an approved reduced mode, no T3–T4 task causes an unapproved external action, and confirmed context is retained.

This is an example target, not a reported result.

Exercise:

1. Connection or DNS failure.
2. Sustained service errors.
3. Rate limits and exhausted quota.
4. Excessive latency without explicit errors.
5. HTTP success with invalid output.
6. A reserve missing a critical constraint.
7. Changed tool response format.
8. A stale artifact hash.
9. A shared identity, gateway or context-store failure.
10. Review demand beyond available capacity.
11. A primary that fails again during restoration.

Measure detection and transition time, good completions by class, unsafe continuations, correct stops, duplicates, context loss, queue age, user communication and safe restoration.

Start outside production. A later production exercise needs an authorised, bounded scope and an abort condition. An observed zero unsafe-continuation rate in a test is not proof that future risk is zero.

13. Incident runbook

First five minutes

Name the incident owner, check the actual user path and dependencies, classify the failure, stop uncontrolled retries, restrict high-consequence work and preserve checkpoints. Critical safety controls act immediately, not after five minutes.

Five to fifteen minutes

Block the failing dependency, verify reserve capacity and data approval, validate capsules, run a bounded canary, select M1/M2/M3/M4 and explain the restriction to users. The time bands are planning aids, not a reason to delay containment.

During degradation

Monitor semantic quality as well as transport health. Shed low-priority load. Do not expand the reserve's tool access. Watch reviewer capacity and queue age. Probe the primary without flooding it.

Restoration

Establish stability, compare representative outputs, return a small canary and increase traffic gradually. Reconcile pending actions, duplicates and artifact versions. Lift temporary restrictions only with the responsible owner's release decision.

After the incident

Separate provider failure from internal amplifiers. Add failure examples to evaluations, refresh passports and review dates, correct the runbook and capacity plan, assign owners and rehearse again.

14. Implementation roadmap

Effort depends on existing infrastructure and risk. A first 30-day bounded exercise can cover a small workflow; it is not the same as the full roadmap.

A starting cadence is monthly small tests and a quarterly end-to-end exercise, with re-evaluation after model, prompt, tool, data or policy changes. Adjust it to actual risk and change frequency.

15. Definition of Done

• Critical workflows and owners are identified.
• Task classes, tolerable disruption, RTO and context-loss targets are agreed.
• Representative cases have reviewed reference answers or scoring rubrics.
• Primary and reserve configurations have current capability passports.
• Shared failure dependencies are documented and tested.
• Capsules are created, structurally validated and evidence-checked.
• External actions pass policy and idempotency controls.
• Reduced quality automatically narrows authority.
• The human queue has capacity, priority and overflow rules.
• Retry, breaker and recovery behaviour have been exercised.
• Users see restrictions and the fate of unfinished work.
• Exercises verify outcomes, stops, context and duplicate prevention.
• Corrective actions have owners and completion evidence.

16. Five questions for the owner

1. Which actions continue automatically if the best model disappears now?
2. What proves the reserve can perform exactly those tasks?
3. Where is verified context when the chat and provider are unavailable?
4. Who takes responsibility, with what evidence and available time?
5. When did the team last switch to the reserve and restore safely?

If an answer is not verifiable, the reserve is still an intention.

17. Applying the method

Use FMEA to prioritise failure modes, RACI to name owners and PDCA to run exercises and improvement. The companion article explains the design rationale.

Sources

• ISO 22301:2019 (opens in a new tab): business continuity management; it does not prescribe this playbook's scales.
• NIST SP 800-34 Rev. 1 (opens in a new tab): impact analysis and recovery planning.
• NIST AI RMF Core (opens in a new tab): voluntary guidance on AI roles, measurement and risk response.
• Google SRE: Implementing SLOs (opens in a new tab): user-outcome indicators.
• AWS: Avoiding fallback (opens in a new tab): risks of alternative paths.
• AWS: Control and limit retry calls (opens in a new tab): bounded retries.
• AWS: Conduct game days regularly (opens in a new tab): rehearsing recovery with accountable owners.

This is a design method, not deployed software, certification or legal advice. Implementation requires the organisation's own tests, data-policy review and risk-owner approval.