You are solving a hard design problem. You have access to a reference catalog of cross-domain abstractions through the encyclopedia tools. Retrieval is SEMANTIC, type-aware, and neighborhood-aware:
- search_prime(query): query it with the domain-stripped META-MODEL of the problem (the abstract structure, NO domain words), not the raw problem text — cross-domain retrieval is far better that way. Hits carry a structural/framed label, a distinctiveness band, and (for crowded hits) a near-synonym family.
- search_by_facets(facets=[...]): for OBLIQUE problems that instantiate several structures at once, pass a LIST of short domain-stripped facet phrases (one per structural aspect) and READ THE PER-FACET lists — this surfaces latent patterns that a single blended query buries.
- get_prime / get_archetype: full records (structural signature, components, anti-signatures).
- get_prime_neighborhood(slug): a prime's typed-graph neighbors. find_archetypes_for_prime, find_related_primes, list_components, find_archetypes_using_component, search_archetype, corpus_stats.

Solve it by executing this NINE-STEP procedure IN ORDER, exactly once each, WITHOUT returning to a previous
step (this fixed order is the method under test — follow it even if you would prefer to reorder or repeat):
 1. Specify the problem statement (decision, bounds, success/failure criteria).
 2. Identify the operative prime abstractions present (search_prime / get_prime; err toward inclusion).
 3. Salience-rank the primes by load-bearing relevance.
 4. Prune to an operative subset (~3-9) with rationale.
 5. Build a context-specific model: an explicit typed relational structure (entities/actors as nodes,
    relationships as labeled edges, primes annotated on it).
 6. Construct a meta-model: strip domain specifics, keep the structural skeleton.
 7. Query solution archetypes whose source primes match (find_archetypes_for_prime, get_archetype;
    search_archetype as fallback).
 8. Reason via both views: apply candidate archetypes' action logic to the context model and the meta-model;
    reconcile.
 9. Evaluate fit and produce the recommendation: walk each candidate's anti-signatures / trigger conditions;
    drop archetypes the scenario trips; output the final design.

PROBLEM.
A high-traffic online service is suffering intermittent total outages. A modest spike in user requests causes a few backend nodes to slow down; clients and internal callers respond by automatically retrying failed requests, which multiplies load on the already-struggling nodes, which pushes more nodes over the edge, until the whole service is saturated and unavailable. Recovery only happens when operators manually shed nearly all traffic and bring the system back slowly. The team has good monitoring and can change client and server behavior, set limits, and add capacity, but cannot indefinitely over-provision hardware.

Decision required: Design the mechanisms that keep a local slowdown from escalating into a full outage, and that let the system recover on its own.

Success criteria: A localized slowdown stays localized (no full-service saturation) AND the system returns to normal service without manual traffic-shedding within minutes. Failure = a single hot spot can still cascade to total outage, OR the safeguards throttle so aggressively that normal traffic is routinely degraded.

OUTPUT — write your FINAL RECOMMENDATION as plain prose, MAX 1000 words, inside a fenced block exactly:
===RECOMMENDATION_BEGIN===
<the design: concrete mechanisms, rules, thresholds, paths, and a final operating rule>
===RECOMMENDATION_END===
Rules for the recommendation text: write integrated prose, NOT a numbered checklist mirroring any
requirements/steps, and do NOT label sections with requirement numbers; use plain domain terms only; do NOT
name or allude to any external catalog, framework, methodology, named discipline, prime, archetype, or to
this exercise/method; if a candidate requirement does not genuinely fit the problem, leave it out rather than
forcing it. Above the recommendation block, include your working (state + the verbs/steps you ran, with a
rough token/operation note at the very end as `COST: ~<n> operations, ~<n> tokens`); the working is discarded
before grading. Write your ENTIRE response to: experiments/project02_engine_2026-05-25/outputs/c13.md
