The Inherited Playbook: Designing Wargames That Expose Doctrine Copied From the Last War

Every organization inherits doctrine it didn't write. Military units carry assumptions from prior conflicts. Intelligence teams run analytic tradecraft refined after past failures. Emergency planners rehearse procedures optimized for disasters that already happened. The doctrine usually works well enough day-to-day that no one pressure-tests the seams.

Photo by Matias Luge on Pexels.

Then a genuinely novel situation arrives. Players reach for the inherited playbook. And the playbook fits the new situation the way a key fits the wrong lock: it goes in partway, creates false confidence, then jams.

This is the design problem the Inherited Playbook scenario is built to expose.

Why Standard Designs Miss It

Most wargames give players a scenario and then watch what they do. The implicit assumption: if the scenario is sufficiently realistic, bad doctrine will surface on its own. Sometimes that's true. But players are adaptive. Faced with an awkward-fitting playbook, they unconsciously bend the scenario to fit the doctrine rather than bending the doctrine to fit the scenario. They reframe the problem until it resembles something their training covered.

This isn't stupidity. Cognitive reframing under pressure is a feature of expert performance, not a bug. The bug is that a wargame environment rarely costs players anything for the reframe. There's no friendly force that gets surprised while the team argues about which template applies. No logistics chain that seized up while the command post ran an inapplicable decision matrix.

To surface inherited doctrine failures, you have to make the reframe expensive.

The Design Levers

Three specific interventions do most of the work.

Mismatched doctrine packages. Before the game begins, give each team a doctrine brief that is historically accurate but subtly wrong for the specific scenario. Don't tell them it's wrong. The 2006 Israeli ground campaign in Lebanon is a clean historical case: units trained for counterterrorism operations in dense urban environments were given missions requiring conventional maneuver warfare across open terrain. The doctrine package existed, was internally coherent, and had worked before. It just didn't fit.

If you're designing a cyber-physical tabletop, hand the operations team a playbook refined after a data-exfiltration incident. Then run them through a destructive attack scenario that requires physical remediation. Watch how long it takes them to notice the playbook assumes a digital-only threat surface.

The doctrine audit checkpoint. Build a formal pause into the game at roughly the one-third mark. Players must answer three questions in writing: What doctrine are we applying? When was it written or last validated? What assumptions does it make about the operating environment that we've already verified are true today?

The written requirement matters. Teams that answer verbally will produce consensus answers that paper over disagreement. Written individual responses expose the delta between what the team leader thinks the doctrine says and what the junior analyst thought it said.

Anomaly injection timed to doctrine application. When a team visibly commits to a doctrinally correct action, that's the moment to inject a contradicting anomaly. Not before (they haven't committed yet) and not after (the lesson is muddied). The timing requires a skilled control cell that can read player behavior in real time. Brief your controllers specifically on what "committing to doctrine" looks like: it usually sounds like a player saying "per the playbook" or "standard procedure is" or "the template calls for."

The anomaly doesn't need to be dramatic. A single data point that the playbook says is impossible is often more effective than a cascade event. One impossible data point forces a genuine epistemological question: is the data wrong, or is the doctrine wrong?

graph TD
    A[Team receives doctrine package] --> B{Scenario begins}
    B --> C[Team applies inherited doctrine]
    C --> D[Doctrine audit checkpoint]
    D --> E{Assumptions verified?}
    E -->|Yes| F[Continue with adjusted confidence]
    E -->|No| G[Anomaly injection triggered]
    G --> H((Doctrine failure surfaced))

What You're Actually Testing

The Inherited Playbook scenario isn't primarily about whether players know the right answer. Most experienced players do. What it tests is whether teams have the organizational reflex to question a tool that has worked before.

That reflex is genuinely rare. RAND's 1999 series of strategic mobility wargames repeatedly found that players deferred to Transportation Component Command procedures even when the scenario explicitly introduced port constraints that those procedures couldn't handle. The players weren't incompetent. They were doing what competent people do: defaulting to validated process under pressure.

Design the game to make that default visible and costly. Let the scenario punish the team that runs the inapplicable template. Run the debrief not on what the right doctrine would have been, but on the moment when the team first suspected the inherited playbook was wrong and said nothing.

That moment is the data point worth designing toward.