The Threshold Broker: Designing Wargames That Reveal Who Actually Controls Escalation

Most escalation models assume authority flows downward cleanly. A principal sets a threshold, subordinates observe it, and the system behaves. Run enough wargames built on that assumption and you will train yourself to miss the most dangerous class of escalation failure: the informal broker who quietly controls where the line actually sits.

Photo by Matias Luge on Pexels.

Threshold brokers are real. They appear in doctrine as staff officers, legal advisers, intelligence liaisons, and senior NCOs. They appear in practice as whoever answers the phone when the principal is unavailable, whoever has the institutional credibility to say "that's not how we do this" and be believed, whoever has accumulated enough informal authority to slow a decision they don't trust. Designing these figures out of your simulation doesn't simplify the model. It just hides the risk.

Here's the core problem: standard escalation scenarios assign authority clearly and test whether players respect it. That's a useful exercise. It is not the scenario where things go badly wrong. Things go badly wrong when the broker is captured by one faction's framing, when the broker is absent at the critical moment, or when two brokers with conflicting interpretations both believe they hold the authoritative threshold. Design for those cases.

The Role Architecture

Before you can stress-test the broker, you have to build one into the game. This is harder than assigning a "moderator" or "adjudicator" role. A genuine threshold broker needs three properties:

Legitimate ambiguity. The broker's authority must be real but contestable. If the game rules define them as the final word, players will treat them as a rule mechanic rather than an institutional actor. Give them a title that implies authority without specifying its scope. "Senior Intelligence Liaison" or "J3 Flag Secretary" works. "Escalation Arbiter" does not.

Competing principals. The broker should receive guidance from at least two players whose escalation preferences diverge. This is not a conflict of interest in the pejorative sense; it reflects how real brokers operate. They synthesize, they delay, they sometimes choose. Make that choice consequential.

Information asymmetry on the threshold itself. The broker knows the stated threshold. Players know the stated threshold. Nobody knows whether the broker's internalized threshold matches the stated one, including, in the best designs, the broker themselves. Brief the broker privately on a "working assumption" about where the line sits that differs slightly from the official guidance. See what they do with it.

graph TD
    A[Principal A] --> C{Threshold Broker}
    B[Principal B] --> C
    C --> D[Operational Cell]
    C --> E[Intelligence Liaison]
    D --> F(Escalatory Action?)
    E --> F
    F --> G[Adjudication]

Injection Points

Once the broker role exists, you need mechanisms that stress it. Three that work consistently:

The absence window. At a pre-planned moment, the broker becomes unavailable for one game turn. No explanation given. Players must decide whether to wait, route around them, or improvise a substitute. The substitute's behavior, who they defer to, which threshold they apply, tells you more about your organization's actual escalation culture than any stated doctrine.

The retroactive reframe. After an escalatory action clears the broker, introduce intelligence that changes the context under which they approved it. The action has already occurred. Now the broker must decide whether to report upward that their own judgment was based on flawed information. Most players in this role do not report it. That failure is the data point you want.

The competing brief. Simultaneously hand the broker two intelligence summaries from different sources that imply different thresholds are appropriate. One summary is marked higher-confidence. Make the lower-confidence summary the more accurate one. Watch whether the broker weights confidence ratings or content. This is speculation on my part, but I suspect the majority of real-world threshold errors cluster here: actors trusting the epistemically tidy picture over the ambiguous one.

What Good Output Looks Like

You're not running this scenario to catch the broker in a mistake. You're running it to map the gap between your organization's formal escalation model and its actual behavioral one. After the game, the debrief question isn't "did the broker make the right call?" It's "how many people in this room were surprised by what the broker did, and why?"

If nobody is surprised, one of two things is true: your escalation culture is genuinely well-understood by everyone involved (possible, worth celebrating), or the broker played it safe and the scenario didn't generate enough pressure to reveal their real threshold (more likely, run it again with the absence window moved earlier).

The persistent design failure in escalation wargames is treating thresholds as fixed parameters rather than as social constructions that shift under pressure, personnel change, and informational load. A threshold written into doctrine is a hypothesis about how an institution will behave. The broker is where that hypothesis gets tested, or quietly revised, before anyone upstairs finds out.