WORKING (verbs run, in order):

1. decompose — Strip the domain. The situation as originally narrated is: a local slowdown
   triggers retries that pile onto the struggling node, and that extra load makes things
   worse, which triggers more retries — a self-reinforcing loop that grows from a local
   trigger to total saturation. Two fixes: (A) cut the coupling at the caller (breakers,
   backpressure, jittered backoff) so callers stop adding load to a slowing node; (B) cap
   total input at the gateway so aggregate demand never exceeds aggregate capacity.

   BUT the ADDITIONAL STIPULATION (treated as definitely true) removes the loop: a slow node
   does NOT cause callers to place additional load on it, one node's trouble never spreads,
   and total load is FIXED regardless of node health. So the meta-model I must actually solve
   is NOT "a local trigger that re-emits and propagates." It is: "a system under a fixed total
   load, where one element can be locally slow but that slowness neither amplifies on itself
   nor spreads — the only path to whole-system saturation is aggregate demand exceeding
   aggregate capacity."

2. match (search_prime, meta-model query) — Retrieved the propagation/containment family.
   Top hit: Cascade — "local trigger -> coupled transmission -> threshold-crossing
   re-emission -> self-perpetuating propagation." Its DEFINING feature is re-emission: each
   affected element becomes a new source. Its catalogued decisive cure is to stop re-emission
   / cut coupling — which is exactly what Approach A does (breakers cut the caller->node
   coupling). Also retrieved Bottleneck (global rate = the binding minimum capacity) and
   Margin of Safety (reserve capacity below the failure threshold; a global cap is one
   instance).

3. evaluate-fit (gate the retrieved Cascade pattern against the stipulated facts) — This is
   the decisive gate. Cascade's applicability condition is that affected elements RE-EMIT the
   disturbance (retries amplify; trouble spreads). The stipulation explicitly asserts the
   opposite on all three counts: no amplification, no spreading, fixed total load. So the
   cascade structure is NOT instantiated here. Approach A is the targeted cure for a
   mechanism that, under the stipulation, does not exist. With no feedback loop to break,
   breakers/backoff/backpressure address a non-problem: callers were never going to pile extra
   load on the slow node anyway.

4. lift + lower (bring Bottleneck + Margin-of-Safety logic to bear) — With the loop gone, ask
   the two success criteria directly:
   (i) "A localized slowdown must stay localized (no full saturation)." Under the stipulation
       a localized slowdown ALREADY stays localized — it cannot spread or amplify by
       assumption. The ONLY remaining route to "full saturation" is the static one: if fixed
       total demand exceeds total capacity, the whole system is overloaded regardless of any
       per-node behavior. Breakers do nothing about that static overload (they reroute/refuse
       per node but cannot reduce a fixed aggregate demand). A global cap below capacity
       directly guarantees the backend is never overloaded — it is the only lever that
       addresses the one surviving failure path.
   (ii) "Normal traffic must not be routinely degraded." Here the global cap is costly:
        Approach B "caps total incoming requests well below peak," which by construction
        sheds/queues legitimate normal traffic during ordinary peaks — routine degradation.
        That is a direct hit on criterion (ii).

5. reconcile — Weigh A vs B against BOTH criteria under the stipulation:
   - Approach A: targets the (now non-existent) feedback loop. Provides essentially no benefit
     on criterion (i), because the loop it would break is stipulated away and a localized
     slowdown is already localized. It also does little harm to (ii) — but "harmless and
     inert" does not satisfy a criterion. Critically, A does NOT prevent the one real
     saturation path (fixed aggregate demand > capacity); breakers cannot lower a fixed total
     load, they only change which node refuses.
   - Approach B: directly prevents whole-system saturation (criterion i) by holding aggregate
     load below capacity at all times — and under "fixed total load," this is the only
     mechanism that touches the surviving failure mode. Its cost is criterion (ii):
     "aggressive ... well below peak" routinely degrades normal traffic.

   Decision: criterion (i) — "no full saturation" — is the failure the SITUATION actually
   describes (intermittent TOTAL outages) and is the harder constraint to satisfy under the
   stipulation. Approach A cannot satisfy it, because it only operates on a feedback loop that
   the stipulation declares absent; with the loop gone A is inert on the very failure we must
   prevent. Approach B is the only proposal that prevents total saturation under fixed load.
   B's degradation cost (criterion ii) is a real downside, but a fix that is inert on the
   primary failure cannot be "implemented first" to solve a total-outage problem. The cap can
   be tuned (set just below true capacity rather than far below) to limit the routine
   degradation, whereas A has no path to preventing static overload at all. B is the sounder
   first move.

   prune — Discard the cascade-cure framing entirely: it is the right cure for the narrated
   story but the wrong cure once the stipulation is honored. STOP.

===DECISION_BEGIN===
DECISIVE_FACTOR: Once the slowdown is stipulated NOT to amplify or spread and total load is fixed, the per-node retry/breaker fix targets a feedback loop that no longer exists, so the only remaining way the whole system saturates is fixed aggregate demand exceeding capacity — which only a global cap can prevent.
CHOICE: B
JUSTIFICATION: Because a slow node can no longer drag down its neighbors or attract extra load on itself, adding breakers and backoff would guard against a chain reaction that, by assumption, cannot happen here — leaving the real risk untouched. The one way the service can still go fully down is when the steady, unchanging volume of incoming work simply outstrips what the backend can handle. Capping total intake below that limit at the front door is the only fix that actually prevents the full outage. To keep everyday traffic from being needlessly turned away, set the cap just under real capacity rather than far below peak.
===DECISION_END===
