## TL;DR
Review escalates a transaction to auto-block, auto-block sends it back to review, and the two automations ping-pong it forever. Fix: replace the cycle with a one-way escalation ladder, require new evidence for any downward move, order conflicting rules by authority, and cap total escalations per transaction. Conflicting rules need a tiebreaker, not a rematch.

```text
fraud agent stuck in review queue to auto-block escalation loop
```

## Use this when
- One transaction id bounces between review and auto-block repeatedly.
- Two automations log opposite decisions on the same transaction minutes apart.
- Escalation counts per transaction keep climbing with no terminal state.

## Not for this skill when
- A transaction escalates once and stays escalated. That is the system working.
- A human keeps moving a case back and forth. That is a process problem, not an agent loop.

## Steps
1. Map every automation that can move a transaction between review and auto-block. Verify: you can draw the full cycle from the logs.
2. Replace the cycle with a ladder: review, enhanced review, auto-block, manual. Moves go up freely; moves down require a new-evidence field on the transition. Verify: no rule can move a transaction down a level without evidence attached.
3. Declare an authority order: human decision beats model, block beats approve, newer evidence beats older. Verify: replaying the same inputs always picks the same winner.
4. Cap escalations per transaction at five. Past the cap, route to a human with the decision history. Verify: no transaction is ever escalated a sixth time.
5. Add a cooldown after auto-block: no rule may re-evaluate the transaction until the window passes. Verify: logs show zero re-evaluations inside the window.

## Variant phrasings
### review to block escalation cycle
Short phrasing.
### agent bounces transaction between review and block
Symptom-level search.
### escalation ping pong fraud agent
Loop-focused phrasing.

Compatibility: any rules engine with ordered evaluation; implement the ladder as a persisted level field on the transaction record so every writer sees it.

## Why it happens
Two rules were written by two people for two different goals, and neither knows the other exists. Rule A sees risk and escalates; rule B sees a clean signal and de-escalates. Each is locally correct and globally an infinite argument.

## Edge cases / pitfalls
- Genuinely new signals should still escalate further up the ladder; the ladder only blocks downward moves without evidence.
- Publish the authority order where analysts can read it, or every conflict gets re-litigated by hand.
- Cooldowns sized from guesswork either let fraud through or stall legit traffic; tune from your decision latency data.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_N2oGJb4ARTbj77ovrL-eyw