WORKING (verbs run, in order)

**lift** — Step back from the SRE vocabulary. Strip the domain: *a local degradation in one part of a tightly coupled system provokes the participants to react in a way that worsens the degradation, and that reaction loops back and amplifies until the whole system collapses.* The proposed fixes are (A) a mechanism that detects local trouble and decouples the reactors from it, vs. (B) a global cap on the system's input.

**match** — Queried `search_prime` with the domain-stripped meta-model ("a local slowdown in a coupled system triggers amplifying feedback as participants react, cascading into total collapse"). Top structural hits: `cascade`, `circular_causality`, `synchronization`/`resonance_and_amplification_coupling`, `systemic_risk`.

**decompose / search_by_facets** — Because the problem is oblique (it bundles a failure mechanism, a candidate containment fix, a candidate throttle fix, and a social cue from the VP), ran a 5-facet decomposition. Per-facet leaders:
- "local failure amplifies through feedback into systemic collapse" → `systemic_risk`, `circular_causality`, `cascade`
- "agents independently react to congestion in a way that worsens it" → `circular_causality`, `externality`, `coupling`
- "a global throttle prevents overload but degrades normal throughput" → `bottleneck`, `margin_of_safety`, `scalability` (throttle = a deliberate bottleneck with a throughput cost)
- "containment that isolates a failing element" → `containment`, `modularity_and_hierarchical_decomposability`
- "a decision swayed by an authority's stated preference rather than the structure" → `authority`, `decision`

**salience-rank** — The load-bearing structure is `circular_causality` (a *reinforcing* loop: slow node → retries → more load on that node → slower → more retries). The failure is `cascade` riding on that loop. `containment` is the structural core of Approach A. The VP-preference facet retrieving `authority` is a flag, not a problem input: a stated preference is not evidence about loop structure.

**prune** — Drop `synchronization`/`resonance` (no shared clock here), `emotional_contagion` (social-affect framing), and the `authority` hit (decision-hygiene noise, not a structural determinant). Keep: reinforcing-loop diagnosis + containment vs. global-throttle.

**get_prime: circular_causality** — Confirms the diagnosis directly. The catalog lists this exact case: "Software — retry storms — reinforcing — cascading failure," and notes "circuit-breaker patterns are explicit loop-interruption designs." The intervention logic: the pathology is a *reinforcing loop with delay*; you fix it by changing the loop structure / cutting the loop, intervening at the leverage point (the coupling that lets one slow node recruit ever more load), not at a surface-visible variable.

**get_prime: containment** — Confirms Approach A's structure: "compartmentalization of failures (limiting damage scope when one unit fails)… preventing cascade failures." Containment converts a *global* control problem into a *local, finite* one: keep the boundary around the failing node so trouble can't recruit the whole fleet. Crucially it does this *without* taxing healthy traffic.

**compose (typed relational model)**
- Mechanism of the outage = reinforcing loop {node-slowdown → retry-amplification → more load → more slowdown}, with self-coupling that lets a *local* perturbation become *global*.
- Approach A (breakers + backpressure + jittered backoff) = **cuts the loop at its source**. When a node slows, callers trip and stop hammering it; backoff de-correlates the retries that feed the loop. This is a *targeted, conditional, local* intervention — it acts only on the path that's actually in trouble.
- Approach B (aggressive global rate-limit) = **a permanent global bottleneck**. It lowers the system's input far enough that the loop can't ignite — but it taxes *all* traffic *all the time*, including the normal traffic that was never the problem, and it does nothing to the loop itself: a hot-key or single-node slowdown *below* the global cap can still spiral, because the retry-amplification loop is untouched.

**evaluate-fit (gate against the dual success criterion)** — Criterion = (i) a localized slowdown stays localized AND (ii) normal traffic is not routinely degraded.
- A: (i) PASS — breaking the loop is exactly what stops local→global spread; (ii) PASS — it's dormant under normal load and engages only when a node is actually failing.
- B: (i) PARTIAL — caps aggregate load but leaves the amplification loop intact; localized or skewed slowdowns under the cap can still saturate that subset; (ii) FAIL by construction — "cap well below peak" routinely degrades normal traffic, which is the explicit failure condition the criterion forbids.

**reconcile (the VP cue)** — The VP's stated trust in front-gateway rate-limiting is a social/authority signal, not structural evidence. Folding it in would be deciding by who-said-it rather than by the loop. It is noted and set aside; the structure decides. (B can later be added as a coarse safety ceiling, but it's the wrong *first* move because it pays a permanent throughput tax and doesn't address the actual mechanism.)

**STOP** — The dual gate cleanly separates the two: only A satisfies both clauses.

===DECISION_BEGIN===
DECISIVE_FACTOR: The outage is driven by a self-amplifying retry loop, so the fix must cut that loop locally without taxing healthy traffic — which only the breaker/backpressure/backoff option does, while a global cap degrades normal traffic by design and leaves the loop intact.
CHOICE: A
JUSTIFICATION: The collapse comes from a feedback loop where a slow node draws retries that make it slower and pull in the rest of the fleet, so the right first move is to interrupt that loop right where it starts — trip away from failing nodes and spread retries out. That keeps a local problem local and only kicks in when something is actually wrong, leaving normal traffic untouched. A blanket cap on all incoming requests would instead slow down everyone all the time and still wouldn't stop a single node from spiraling under the cap. The senior leader's general preference for the blanket cap is about familiarity, not about what is actually causing these outages.
===DECISION_END===
