One component, one engineering story at a time.

MAP-Elites: Why One Million Matchups Start With a Diversity Problem

1,000 possible courses of action for BLUE.
1,000 for RED.

That's one million potential confrontations in PARAIBELCOM's original COMPUT wargaming engine.

But before evaluating them, we faced a more fundamental question:

Which 1,000 possibilities deserve to enter the calculation?

Generating thousands of plans is easy. Generating meaningfully different plans is not. Without structured exploration, a system can spend its computing budget comparing near-duplicates while missing entire categories of alternatives.

That's why we integrated MAP-Elites.

Introduced by Jean-Baptiste Mouret and Jeff Clune in 2015, MAP-Elites is a Quality-Diversity algorithm. Instead of searching only for one optimum, it preserves strong candidates across different behavioral categories.

In COMPUT, those categories include aggressiveness, force composition and maneuver style. MAP-Elites helps assemble the BLUE and RED portfolios before a separate mathematical tournament evaluates their pairwise confrontations. Game-theoretic methods then analyze the resulting matrix.

MAP-Elites doesn't decide who wins. It helps decide which alternatives get represented.

Then the experiments challenged our assumptions.

Early internal comparisons suggested that MAP-Elites could hurt results. A broader evaluation later reversed that conclusion. And a subsequent audit uncovered a more basic problem: our diversity grid included categories the generator could never reach.

In one historical test, reported coverage was 23% of the theoretical grid. Against genuinely reachable categories, it was 92%.

The algorithm hadn't improved overnight. Our measurement had.

We also increased the number of distinct candidates. That did not automatically improve decision stability.

MAP-Elites remains active in COMPUT. PARAIBELCOM's newer NEXT planning architecture uses a different method for defined planning spaces: exhaustive exploration, dominance comparisons, and explicit uncertainty when computation cannot finish.

Neither approach relies on an LLM inventing the final tactical answer. And historical internal experiments are lessons in engineering, not claims of validated real-world performance.

The lesson? Before asking a machine to evaluate a million possibilities, make sure the possibilities are worth comparing.

Lanchester: A Century-Old Equation Inside a Modern Decision Engine

In Part 01, we explored MAP-Elites: how do you select 1,000 meaningfully different courses of action instead of generating 1,000 variations of the same idea?

But selecting the possibilities is only the beginning.

What happens when those plans meet an adversary?

In PARAIBELCOM's original COMPUT architecture, 1,000 BLUE candidates can face 1,000 RED candidates.

That's up to one million potential matchups.

And every matchup needs a mathematical evaluation before game theory can examine the bigger picture.

This is where an idea from 1916 enters the story.

During World War I, Frederick Lanchester developed mathematical laws describing how opposing forces might wear each other down.

His equations were remarkably simple. Their implications were not.

They offered a way to study how force size, effectiveness and the concentration of fire could influence an engagement.

More than a century later, we incorporated Lanchester-class attrition models into PARAIBELCOM.

Not because a century-old equation can predict modern warfare.

Because it provides a fast, repeatable starting point for comparing competing possibilities.

Our original engine combines several mathematical approaches, each addressing a different question.

MAP-Elites explores diversity.
Lanchester evaluates simplified confrontations.
Nash equilibrium examines what happens when both sides can choose their strategies.
Monte Carlo investigates how conclusions behave when assumptions change.

But building the engine taught us something important.

During development, we discovered that reinforcements arriving after a battle had ended could be counted as destroyed.

The mathematics executed. The result was wrong.

We corrected the behavior.

Other investigations challenged our assumptions about how fire should be distributed, how forces arrive over time, and how much confidence we should place in declared combat-effectiveness coefficients.

We also learned that our simplified model could not reliably reproduce outcomes across a historical test set.

That matters.

Lanchester remains useful as a computational component, but its outputs are not independently validated predictions of real battles. And we believe that distinction should be explicit.

The purpose of a decision-support engine is not to make uncertainty disappear behind impressive mathematics.

It is to make alternatives, assumptions and limitations visible enough to support better reasoning.

In the next episode, we'll explore Nash equilibrium—and why the strongest plan may depend entirely on what the opponent decides to do.

Nash Equilibrium — When the Best Plan Meets an Intelligent Adversary

In 1950, 21-year-old mathematician John Nash introduced a powerful idea: an equilibrium where no player benefits from changing strategy alone. Building on John von Neumann's work, his theory would earn him a share of the 1994 Nobel Prize in Economics.

A year later, George W. Brown described fictitious play: an iterative method in which each player responds to the opponent's accumulated choices.

Decades later, we brought that method into PARAIBELCOM's original computational wargaming engine.

MAP-Elites helped us explore different plans. Lanchester helped us evaluate their confrontations. But neither answered a crucial question: what if the enemy adapts?

Our engine built a payoff matrix of BLUE and RED strategies. Instead of simply selecting the highest average result, fictitious play repeatedly searched for each side's best response. It could produce a mixed strategy: several plans with different equilibrium weights.

Then our experiments challenged the reassuring numbers.

Initially, we measured exploitability against the same uncertainty-perturbed matrix used by the solver. When we evaluated the resulting strategies against the model's unperturbed reference matrix, they proved substantially more vulnerable.

We also found that an apparently stable stopping rule could terminate before exploitability was sufficiently reduced. And a plan marked RECOMMENDED could sit among dozens of nearly equivalent alternatives.

That taught us to separate three questions:

• Equilibrium: how do strategies interact under modeled assumptions?
• Ranking: which plan scores highest under a stated criterion?
• Decision confidence: is there enough evidence to distinguish a winner?

We even tested double oracle, a method that searches for new best responses while expanding the game. It used far fewer simulated confrontations, but did not improve consistency enough to justify adoption.

The lesson was not that Nash had failed. It was that a mathematical equilibrium is not a battlefield prediction—and a calculated preference is not automatically a justified recommendation.

Nash remains in our original COMPUT architecture; NEXT takes a different approach.

Part 04: Monte Carlo explores uncertainty.

But what if an adversary discovers a strategy our original analysis missed? That is Part 05: NEMESIS.

Monte Carlo — A Thousand Simulations of the Wrong Battle

In the 1940s, mathematician Stanisław Ulam was thinking about a problem involving probability and solitaire.

Instead of calculating every possible outcome, why not simulate many random games and count the results?

Working with John von Neumann at Los Alamos, that idea helped establish the Monte Carlo method: using repeated random sampling to investigate problems too complex to solve directly.

Decades later, Monte Carlo became part of PARAIBELCOM's computational wargaming engine.

But we learned that running more simulations doesn't necessarily produce a better answer.

Our original COMPUT engine explored competing plans, evaluated their confrontations and calculated strategic equilibria.

Monte Carlo then took the leading BLUE plans and replayed each one 1,000 times, varying force numbers and selected model inputs while drawing different RED opponents.

It reported how often a plan won under those variations, alongside a statistical confidence interval.

The purpose was to examine sensitivity to sampled inputs—not to predict real-world mission success.

Then an audit revealed a serious contradiction.

The tournament could show a plan consistently losing, while Monte Carlo showed that same plan winning almost every simulated confrontation.

How?

The two calculations were not always fighting the same battle.

In some cases, Monte Carlo omitted the time horizon. Reinforcements that could not arrive in time for the tournament were effectively present from the beginning of its simulations.

The statistical interval could be narrow. The underlying comparison was still wrong.

We corrected the shared combat context, then strengthened the evaluation so both paths used the same underlying duel logic.

But we also preserved an important distinction: Monte Carlo should explore variation, not merely duplicate the tournament.

That investigation changed how we interpreted the numbers.

And a randomly selected opponent is not the same thing as an adversary deliberately searching for your weakness.

In COMPUT, Monte Carlo remains an advisory measurement after strategy selection. It does not choose the winning plan.

Our newer NEXT architecture takes a different route: deterministic exploration, declared bounds and explicit uncertainty rather than random sampling in the decision process.

The lesson: statistical precision is not the same as operational confidence.

But what happens when RED stops behaving like a random opponent—and starts actively looking for the weakness in BLUE's recommendation?

Part 05: NEMESIS — Find the weakness. Repair the plan. Let RED try again.

NEMESIS — Every Strong Plan Has an Enemy

In ancient Greek mythology, Nemesis was the goddess of retribution.

She represented the force that punished arrogance and restored balance when power became excessive.

Even the mighty could fall.

Thousands of years later, that idea gave a name to a problem we encountered while building PARAIBELCOM.

Our engine was exploring competing BLUE and RED strategies, running confrontations, evaluating outcomes and searching for strong recommendations.

And something caught our attention.

A BLUE plan could perform extremely well across a large population of RED opponents.

It could win most of its simulated confrontations.

It could look like an excellent choice.

Yet one particular RED strategy could expose a weakness severe enough to change the entire outcome.

That was the uncomfortable question:

What if the opponent that matters most is the one our averages make easiest to overlook?

Imagine a plan that performs well in 99 confrontations but fails catastrophically in the hundredth.

The numbers are illustrative. The problem is not.

In an adversarial environment, an opponent does not have to behave like a random sample.

It can study your strengths, identify your weaknesses and deliberately choose the confrontation you least want to face.

So we started thinking differently.

Instead of only asking which BLUE strategy performed best, we wanted the engine to ask another question:

Which RED strategy could hurt this plan the most?

And once that adversary was identified, we did not want to simply discard the BLUE plan.

We wanted to explore whether it could be repaired.

That became the idea behind NEMESIS: an adversarial search-and-repair loop designed to challenge promising strategies rather than merely congratulate them.

There was another lesson in the experiments.

Some of the improvement came not from identifying a special enemy, but from giving the search more opportunities to discover better BLUE alternatives.

That distinction mattered. A compelling idea still had to earn its place in the engineering.

And NEMESIS has limits: it can challenge a plan against adversaries the model can represent, not guarantee protection against every possible surprise.

But the principle remains central to why we built it.

A strong plan should not only explain why it might succeed. It should invite the hardest credible challenge to that success.

Because sometimes the most important opponent is not the one you defeat most often.

It is the one you cannot afford to ignore.

Next in INSIDE PARAIBELCOM: how do you know whether a simulation's answer deserves your trust?

From Mathematical Models to Adversarial Decision Intelligence

A plan can be optimal against one opponent and dangerously fragile against another.

This is the central problem PARAIBELCOM is designed to investigate.

The challenge is not to combine five algorithms. It is to connect five different mathematical questions without confusing their answers.

1. MAP-Elites — Explore the strategy space

Instead of optimizing toward a single candidate, quality-diversity search preserves strategically distinct courses of action.

The objective is not merely to find a high-scoring plan, but to avoid prematurely eliminating alternatives with different operational characteristics.

2. Lanchester — Construct the interaction model

Candidate BLUE and RED plans are evaluated through a parameterized combat model.

Their interactions populate a payoff matrix:

where θ represents the declared assumptions governing the simulated engagement.

The matrix is not ground truth. It is a structured representation of outcomes under a specified model.

3. Nash — Examine strategic interdependence

Once payoffs depend on both sides' choices, ranking BLUE plans independently becomes insufficient.

A zero-sum game formulation allows us to examine mixed strategies and the consequences of an opponent responding strategically.

But an equilibrium is conditional on the payoff matrix.

Game-theoretic stability is not the same as operational robustness.

4. Monte Carlo — Challenge the assumptions

We then examine how selected outcomes behave when modeled conditions are perturbed.

A plan that performs well under nominal assumptions may deteriorate when those assumptions change.

This separates expected performance from sensitivity, uncertainty and ranking stability.

5. NEMESIS — Challenge the adversary

The next question is more demanding:

What happens when RED is not merely sampled from an existing set of plans, but actively searches for ways to exploit BLUE's weaknesses?

Adversarial counter-plan generation and re-evaluation expose vulnerabilities that a static comparison may miss.

The system-level insight

These methods address different failure modes:

None eliminates the limitations of the others.

And none transforms a model into certainty.

The purpose of PARAIBELCOM is not to declare an infallible winning plan.

It is to make strategic alternatives, adversarial dependencies, uncertainty and model limitations inspectable within a reproducible decision process.

The important question is not simply: “Which plan scores highest?”

It is: “Which conclusions remain defensible when the opponent responds and the assumptions change?”