Working — nine-step control procedure, run once each in order.

**Step 1 — Specify the decision.**
Pick exactly ONE fix to implement first against a failure mode where a modest spike slows a few backend nodes, clients auto-retry, retries pile onto the struggling nodes, and the whole service saturates until operators manually shed traffic. Success requires BOTH: (i) a localized slowdown stays localized — no full saturation; AND (ii) normal traffic is not routinely degraded. Approach A = per-service circuit-breakers + backpressure + jittered/backoff retries (callers trip a breaker and stop hammering a slow node; retries spread out). Approach B = aggressive global front-gateway rate-limit capping total intake well below peak. Note a non-structural pressure: the new VP "tends to trust" global rate-limiting (a source-credibility/authority cue, not evidence about this failure mode).

**Step 2 — Identify operative primes (search_prime / search_by_facets / get_prime).**
Semantic + facet retrieval surfaced: `circular_causality` (the retry→overload→more-retry feedback loop), `system_archetypes` / `cascade` / `systemic_risk` (local degradation amplifying to total collapse — a "Fixes that Fail"/escalation signature), `containment` (hold the hazard inside a perimeter while protecting the exterior), plus contention/throttling/bottleneck (`interference_and_contention`, `load_balancing`) as the structure Approach B reaches for.

**Step 3 — Salience-rank.**
(1) `circular_causality` — the outage is *caused* by a positive feedback loop, not by raw arrival volume. Top salience. (2) `cascade`/`systemic_risk` — what makes a local slowdown become a total outage (the thing the success criterion forbids). (3) `containment` — keep the failing node's trouble local. (4) contention/rate-limit primes — relevant but describe B's blunt instrument, lower salience because they act on total load, not on the loop.

**Step 4 — Prune.**
Drop `temporal_decay`, `maintenance`, `stressor_induced_adaptation`, `antifragility` (off-target — slow degradation / adaptation, not acute feedback collapse). Keep the loop / cascade / containment trio. Also flag and quarantine the VP-preference cue as non-structural: it bears on organizational buy-in, not on which fix satisfies the failure conditions.

**Step 5 — Build a typed relational model.**
Nodes: {arriving requests R, per-node latency L_i, client retry rate Q, node saturation S}. Edges with polarity: R→L_i (+); L_i→Q (+, slow responses trigger retries); Q→L_i (+, retries add load) — this R-Q-L sub-loop is a REINFORCING loop with delay (retry timeout). S triggers cascade: as L_i crosses a threshold, callers fan retries across remaining nodes → systemic saturation. The loop is the generator; total volume is only the initial nudge.

**Step 6 — Domain-stripped meta-model.**
"A local perturbation degrades one element; downstream agents react with corrective effort that is itself load; that effort feeds back onto the degrading element, a reinforcing loop with delay drives the local fault to whole-system collapse. Goal: stop the next collapse without throttling normal activity. Choice between (A) breaking the loop at its regeneration point + isolating the failing element, vs (B) capping total system intake below peak."

**Step 7 — Query archetypes whose source primes match (find_archetypes_for_prime / get_archetype).**
`circular_causality` sources → `cycle_breaking`, `circular_causality_mapping`, `system_archetype_diagnosis`, `balancing_loop_stabilization`; related → `harmful_emergence_containment`, `leverage_point_intervention`, `feedback_loop_redirection`. Pulled two:
- **Cycle Breaking** — harmful recurrence = looped sequence + regeneration point + reinforcer + vulnerable window; intervention = map loop → intercept the regeneration point → supply a replacement pathway → verify non-recurrence. Decision rules: *intervene at regeneration, not manifestation*; *use the least-destructive interruption that prevents recurrence*; *do not remove a cycle without replacing its function*. Invariant: *beneficial cycles remain intact.* Its own cross-domain example names the case directly: "a retry storm or recurring outage can be stopped by changing the state that recreates the failure rather than repeatedly restarting services."
- **Harmful Emergence Containment** — many locally reasonable actions (each retry) combine into harmful macro-collapse; intervention = map the local drivers, add the *narrowest* guardrail / feedback damping that kills the harmful loop's gain, monitor the macro-outcome, and *preserve legitimate decentralized action*. Decision rules: *prefer interventions that change the local driver over ones that punish symptoms*; *use the narrowest containment boundary*; *avoid overcentralized clampdown*.

**Step 8 — Apply each candidate's logic to BOTH approaches and reconcile.**
- *Cycle Breaking on A:* circuit-breakers cut the L_i→Q→L_i edge exactly at the regeneration point (caller stops hammering the slow node); jittered backoff lowers the loop's gain; backpressure is the replacement pathway. The reinforcing loop fails to regenerate. Beneficial behavior (legitimate retries, full throughput for healthy nodes) stays intact. Direct hit on both decision rules and the invariant.
- *Cycle Breaking on B:* a global cap does NOT touch the L_i→Q edge — it suppresses R, a manifestation upstream of the loop, not the regeneration point. Inside the cap the retry loop can still saturate a slow node; below it, the cap throttles healthy normal traffic. This is the "symptom interruption / least-durable suppression" failure mode the archetype warns against, and it violates "do not remove function" (it removes legitimate throughput).
- *Harmful Emergence Containment on A:* breakers/backpressure are the narrow, bounded guardrail acting on the local driver per node, damping loop gain while preserving decentralized healthy traffic. Textbook fit.
- *Harmful Emergence Containment on B:* a global cap is the over-broad, overcentralized clampdown the archetype explicitly cautions against — it degrades the whole system's legitimate activity to contain a pattern generated locally.
Reconciliation: both candidate logics converge on A. They disagree with B for the *same* reason — B acts on aggregate volume (a manifestation) rather than on the reinforcing loop / local driver (the generator), so it cannot satisfy criterion (ii) without sacrificing criterion (i), and vice versa.

**Step 9 — Evaluate fit against the failure conditions / success criteria.**
Failure mode is feedback-driven, not volume-driven: a *modest* spike triggers it, so the binding problem is amplification, not arrival rate.
- Approach A: trips the breaker → localized slowdown stays localized (criterion i: PASS); only the impaired path is contained, healthy traffic flows at full rate, retries merely spread out (criterion ii: PASS). Both met.
- Approach B: to guarantee no saturation the cap must sit below the *spike* that already triggers collapse, which routinely rejects/queues normal traffic (criterion ii: FAIL); and even under the cap, retry pile-on can still locally saturate a slowed node, so containment isn't guaranteed (criterion i: at risk). The VP's preference is an authority cue, not evidence about this loop, and is set aside.
A satisfies both success criteria; B forces a trade-off that breaks at least one. Choose A.

===DECISION_BEGIN===
DECISIVE_FACTOR: The outages are driven by a self-reinforcing retry feedback loop, not by raw request volume, so the fix must break that loop at the failing node rather than throttle total intake.
CHOICE: A
JUSTIFICATION: The total outages come from a vicious circle — a slow node makes clients retry, and the retries make it slower — so the cure is to interrupt that circle right where it regenerates: when a node slows, callers back off, spread their retries, and stop piling on, which keeps the trouble confined to that node. Capping all incoming traffic at the gateway instead attacks total volume, which is not the real cause; to actually prevent saturation the cap has to sit so low that it routinely turns away or slows normal traffic, and even then a retry pile-up can still overwhelm a single struggling node. Only the first option keeps a local slowdown local while leaving healthy traffic running at full speed, satisfying both requirements. The VP's general fondness for global rate-limiting is a preference, not evidence about this specific failure, so it does not change the analysis.
===DECISION_END===
