Graceful Degradation Strategy Review Prompt

List of services, endpoints, or components in scope for degradation review

payment-api, user-profile-service, recommendation-engine, search-indexer

Must be a non-empty list of unique identifiers. Validate against service registry or CMDB. Reject if any identifier is unrecognized or ambiguous.

Directed mapping of which services depend on which other services, including external APIs

payment-api -> [fraud-detector, ledger-db]; recommendation-engine -> [user-profile-service, redis-cache, ml-model-api]

Must be a valid adjacency list or graph structure. Validate that every referenced dependency exists in [SERVICE_CATALOG]. Flag circular dependencies and missing nodes. Reject if graph is empty or disconnected without explanation.

Priority classification for each service or feature, typically P0 (critical) through P3 (non-critical)

payment-api: P0, recommendation-engine: P2, search-indexer: P1

Must assign a tier to every entry in [SERVICE_CATALOG]. Tiers must follow a defined ordinal scale. Validate that at least one P0 service exists. Reject if tier definitions are missing or inconsistent with business SLAs.

Latency, availability, and throughput targets per service or endpoint

payment-api: 99.99% availability, p99 < 200ms; recommendation-engine: 99.9% availability, p99 < 500ms

Must include availability percentage and at least one latency target per critical service. Validate numeric ranges are plausible (0-100 for availability, positive ms for latency). Flag targets that conflict with dependency SLAs.

Current or proposed fallback responses when a dependency is unavailable

recommendation-engine: serve cached top-10 list (stale up to 1h); payment-api: queue request for retry, show 'payment delayed' UI

Must map each service to at least one fallback. Validate that fallback does not call a degraded dependency. Flag fallbacks with no staleness or freshness constraint. Reject if P0 services lack a defined fallback.

Conditions that signal a dependency has recovered and normal operation can resume

fraud-detector: health check returns 200 for 3 consecutive intervals; ml-model-api: p99 latency drops below 300ms for 5 minutes

Must define a measurable condition per degraded dependency. Validate that triggers are observable (health check, metric threshold, synthetic test). Reject if trigger relies on the degraded service self-reporting without external verification.

Mapping of degradation scenarios to user-facing consequences and affected user segments

recommendation-engine down: all users see generic popular items; payment-api degraded: checkout users see delay notice, non-checkout users unaffected

Must describe impact per degradation scenario. Validate that every fallback in [FALLBACK_BEHAVIORS] has a corresponding user impact entry. Flag scenarios where impact description is missing or too vague to inform product decisions.

Maximum duration a service can operate in degraded mode before escalation or forced recovery

recommendation-engine: 4 hours max degraded; payment-api: 15 minutes max degraded before incident escalation

Must specify a duration per service that can degrade. Validate that timeouts are shorter for higher criticality tiers. Reject if any P0 service has a timeout exceeding 30 minutes without explicit justification.

Array of objects

Must be a non-empty array. If empty, retry with explicit instruction to enumerate at least one degradation path.

String

Must match a feature name from [FEATURE_CATALOG] if provided. Non-empty string. If no catalog provided, check for non-empty string.

String

Must reference a dependency listed in [DEPENDENCY_MAP]. Non-empty string. Validate against known dependency inventory.

String enum

Must be one of: 'unavailable', 'timeout', 'error_response', 'degraded_performance', 'partial_data'. Reject unknown values.

String

Must describe a concrete action (e.g., 'serve cached results', 'disable recommendations module'). Reject vague descriptions like 'handle gracefully'.

String enum

Must be one of: 'none', 'stale_data', 'reduced_functionality', 'manual_fallback', 'service_unavailable'. Reject unknown values.

String

Must specify a measurable condition (e.g., 'health check returns 200 for 3 consecutive intervals'). Reject if no metric or threshold is present.

Integer

Must be a positive integer. Lower numbers indicate higher priority. Validate no duplicate priority values exist across the plan.

Every feature listed in [FEATURE_CATALOG] appears in the degradation plan with an assigned priority tier.

A feature from the input catalog is missing from the output plan, or is mapped to a generic 'no impact' category without justification.

Parse the output JSON. Extract all feature names. Perform a set comparison against the input [FEATURE_CATALOG] list. Assert set equality.

Each degraded feature has a concrete, executable fallback action (e.g., 'serve stale cache', 'return static default', 'disable write path') rather than a vague description.

A fallback cell contains phrases like 'handle gracefully', 'inform user', or 'use fallback' without specifying the exact mechanism or data source.

For each entry in the output's 'degradation_plan' array, check if the 'fallback_behavior' field matches a predefined list of valid action types. Assert no null or generic string matches.

Every degradation rule includes a measurable recovery trigger (e.g., 'p99 latency < 200ms for 60s', 'health check 200 OK for 5 consecutive polls').

A recovery trigger is missing, is defined as 'manual only' without an alerting hook, or relies on a metric not present in [OBSERVABILITY_METRICS].

Validate that each 'recovery_trigger' field is non-null. For each trigger, check if the referenced metric exists in the provided [OBSERVABILITY_METRICS] schema. Assert all references resolve.

The plan explicitly identifies and mitigates cascading risks where degrading Feature A could increase load on Feature B, potentially causing its failure.

The output contains a dependency chain where a fallback action (e.g., 'retry on dependency X') would amplify load on a downstream service that is already degraded.

Simulate the degradation plan against a dependency graph provided in [SYSTEM_TOPOLOGY]. Assert that no fallback action increases calls to a dependency already marked as unhealthy.

Each degradation entry includes a clear, non-technical description of the user-facing impact, suitable for a status page update.

The 'user_impact' field contains internal jargon, is blank, or promises full functionality when the fallback behavior indicates data loss or feature unavailability.

Use an LLM-as-judge with a rubric checking for jargon and truthfulness. Assert that the 'user_impact' description does not contradict the technical 'fallback_behavior'.

Feature priority assignments (e.g., Tier 1 - Critical, Tier 2 - Degraded, Tier 3 - Off) are consistent with the business rules defined in [PRIORITY_POLICY].

A payment capture feature is assigned to Tier 3, or a non-critical reporting feature is assigned to Tier 1, contradicting the explicit policy document.

Cross-reference the output 'priority' field for each feature against the rules in [PRIORITY_POLICY]. Assert that all assignments match the policy's classification logic.

The generated output strictly conforms to the expected [OUTPUT_SCHEMA], including all required fields and correct data types.

The model returns a malformed JSON object, omits the required 'degradation_plan' array, or uses a string where an array of objects is expected.

Validate the raw output string against the [OUTPUT_SCHEMA] using a JSON schema validator. Assert validation passes with no errors.

The plan includes a safety gate ensuring that degradation actions are safe to execute multiple times without causing data corruption or duplicate side effects.

The plan suggests a fallback action like 'send email to customer' or 'create duplicate order' without an idempotency key or deduplication check.

Scan the 'fallback_behavior' descriptions for keywords (e.g., 'send', 'create', 'charge'). If present, assert that the corresponding 'safety_gate' field contains a non-null idempotency strategy.