The Corrupted Source: Designing Wargames That Spread Bad Intelligence Upstream

Most wargames treat bad intelligence as a fog-of-war problem: players don't know enough, or what they know arrives late. That's a real problem, but there's a nastier one. Sometimes players know a great deal. They're confident. Their picture is coherent and detailed and completely, systematically wrong, because the source feeding that picture has been compromised.

Photo by Matias Luge on Pexels.

Designing for that scenario requires a different kind of cruelty.

Why Standard Intel-Failure Mechanics Don't Cover This

The conventional approach is noise: reduce certainty percentages, delay report arrival times, introduce contradictory signals. Players learn to tolerate ambiguity and ask for more collection. That's useful training. It does not train the decision-maker who receives high-confidence, internally consistent reporting that is fabricated, mistaken at the origin, or deliberately shaped by an adversary.

The Curveball case (the Iraqi defector whose WMD claims propagated through the DIA and into the 2003 NIE) is the canonical historical example. Single-source, uncorroborated, never directly accessed by the agencies citing him. Every downstream product read as solid because the sourcing chain looked clean on paper. Players in a wargame simulating that environment wouldn't experience ambiguity. They'd experience false clarity.

False clarity is harder to game-design for, because players have to feel confident before you pull the rug.

The Setup: Seeding a Corrupted Source

Here's the specific design move. Before the game begins, the control cell designates one intelligence stream as corrupted. This should be documented only in the control cell's master file. The stream itself is given a clean provenance: a fictional HUMINT asset with a track record, or a SIGINT collection node with high technical confidence ratings.

For the first third of the scenario, that stream delivers accurate reporting. Small things, verifiable against other sources. Players build trust. They start weighting it higher in their mental models.

Then, without announcement, control begins feeding that stream information that is plausible but wrong in one load-bearing way. Not obviously wrong. Wrong in the way that matters: enemy force disposition, timeline for action, identity of a key decision-maker. The corruption should be designed around a specific decision the blue team will have to make in turn three or four.

The goal is for players to make that decision confidently, having never questioned the stream.

graph TD
    A[/Corrupted Source Input/] --> B(Control Cell Filter)
    B --> C[Plausible Report Issued]
    C --> D{Player Trust Accumulates}
    D --> E[High-Confidence Assessment]
    E --> F[Decision Made on False Picture]
    F --> G((Consequence Injected))

The Adjudication Problem

This mechanic breaks if control overplays it. Two failure modes to avoid.

First, making the corruption too detectable early. If a single player asks a reasonable sourcing question in turn one and control has no good answer, the whole setup collapses. Before running the game, write a one-page backstory for the source: collection history, previous accuracy, reasons why corroboration wasn't sought. Umpires need to be able to answer questions without revealing the deception.

Second, making the corrupted decision irreversible in a way that feels punitive rather than instructive. The point isn't to watch players lose. It's to create a post-game moment where they can reconstruct exactly when they stopped asking questions. That reconstruction is the learning. Build in a turn where players could have caught it, if they'd run a sourcing audit or requested corroboration from a separate collection discipline. They usually won't. That's the finding.

Running the After-Action Review

The debrief on this scenario needs to do one specific thing: show players the exact moment their confidence exceeded their evidence.

Print the timeline of reports. Mark when the corrupted stream's information entered their assessment products. Ask them to identify, retroactively, what a corroboration check would have cost in time and resources versus what the unchecked assumption eventually cost. Don't let this become a blame session; redirect every 'we should have known' toward 'what process change would have caught this?'

Then ask the harder question. Were there signals that something was off? Usually there are. A report that arrived slightly faster than collection timelines should allow. A detail that was oddly specific. Players dismiss these under time pressure. Making that pattern visible is worth more than any lesson about intelligence tradecraft you could lecture.

Who Should Run This

This scenario is particularly well suited for organizations that aggregate intelligence from multiple streams and brief senior decision-makers, analytic shops that are confident in their sourcing hygiene, and planning teams that have never had a trusted source burned. Precisely those groups. Confidence in process is what makes the mechanic work.

Run it once. They'll ask different questions about their sources for a long time afterward.