Capabilities

What a simulation can hold

The ranges a design can carry, and the design rules our testing made standard.

Actors

Hundreds of actors, each decomposed into the factions that make its decisions, so internal politics are played rather than assumed. Each faction is defined by what we decide defines it with your experts: positions, red lines, relationships, and sources.

Player map: actors, factions inside them, message traffic (schematic)THE PLAYER MAPHundreds of actors, factions inside them: who talks to whomGoverning coalitionSecurity establishmentCivil authorityArmed movementRival leadershipPopulation proxy APopulation proxy BExternal power AExternal power BExternal power CRegional actor ARegional actor BRegional actor CInternational bodyDonor blocActors (grouping units)Factions (decision units, one agent each)Message traffic (width = volume)Domestic actorExternal or regional actorMost-addressed factionsOut-degree is near-identical by design (mandatory quota), so messages received are read as attention, never as salience.Schematic. Actor and faction counts are set per engagement; names generalised; line placement illustrative.
Figure 1.Actors, factions, and the traffic between them. Schematic.

Options

As many policy options as the question needs, each a starting board of state settings and constraints on what each faction may do. A status-quo arm always runs in full, and every option runs on matched event draws, so a difference between options is attributable to the option.

Shocks

Hundreds of shocks and disruptive events, each with a base probability, conditional modifiers, and effects on the state. Organic events are sampled each quarter; scripted events are forced at a fixed quarter in a share of runs to test sensitivity; timed branching events carry known timing and a distribution over outcomes.

Scenarios and narratives

Tens of thousands of runs across options and event draws. The big narratives are read out of that population as frequencies and conditional probabilities, and the scenario tree shows where futures diverge.

Illustrative distribution of outcome classes per optionOUTPUT FORMATA distribution of futures per optionShare of runs per option in which each outcome class occurred (illustrative)Status quo34%31%22%13%Option A48%27%15%10%Option B22%36%28%14%Option C41%19%24%16%Outcome class 1Outcome class 2Outcome class 3Outcome class 4Outcome classes are the client's outcome questions, read from the record. Event-based questions arecomputed directly; judged questions are read by a reader with traceability to the decisions it read.Illustrative: options × runs set per engagement; production frequencies populate after the run.
Figure 2.Illustrative distribution of outcome classes per option.

The Monte Carlo layer

On top of the runs, a probability layer: outcome classes with their frequencies per option, conditional probabilities given an event sequence, tipping points, and a sensitivity ranking of the assumptions the findings depend on.

Six analytical lenses on one trajectory databaseANALYSISSix analytical lenses on one databaseTrajectorydatabaseone self-contained fileOutcome frequenciesper option, against the outcome questionsConditional probabilitiesof an outcome given an event sequenceScenario treehow futures diverge from a shared startTipping pointswhere small input differences drive large shiftsSensitivity rankingwhich assumptions the findings depend onTraceabilityfrom any claim to runs, decisions, sourcesAll six read the same record; a change of question or weighting is an analytical choice and needs no re-run.
Figure 3.Six lenses on one trajectory database.

Model experiments

Candidate models are compared on pre-registered metrics before the fleet is set, versions are pinned per batch, and contextual judgments are adjudicated by two or three vendor families.

Model selection: candidates, experiments on pre-registered metrics, selected fleet by tierMODEL SELECTIONModels tested before they are selectedCANDIDATE MODELSseveral vendor familiesVendor family AVendor family BVendor family CVendor family DVendor family EEXPERIMENTSsame design, fixed seedsPre-registered metricsPosture entropyRestraint shareText integritySchema validityInter-judge agreementEvery model runs the same battery.SELECTED FLEETby tier · versions pinned per batchTop tierprincipal decision nodesMid tiersub-factions, secondary actorsBase tierbackground, opinion proxiesPinned model, or a visible failure.testedselectedCross-vendor adjudication ensemblea diagnostic on contextual judgments: two or three vendor families judge the same case;disagreement is measured and routed to experts, not averaged awaySelection is experiment-based and repeated when a model version changes; the fleet in use is stated in the method note.
Figure 4.A multi-vendor fleet feeding three agent tiers.

What our testing taught us

  • A referee with inertia, decay, and bounds. A rule without them ratchets one way and produces a storyline that repeats under every option and looks like a finding.
  • Restraint written into every brief as a costed option. Telling a model not to escalate is itself framing that mentions escalation.
  • Content validation of free text. A decision can parse as valid output while carrying scaffold fragments in the text a reviewer reads.
  • A uniform-model test before adoption. Tier and role are confounded, and only a paired test on pre-registered metrics settles it.
  • Opinion proxies with fatigue. Population proxies carry a fatigue state, a hold base rate, and a cap on how far one proxy moves the state.

Read the method behind the capabilities.

The full walk from design pack to traceability, with the claim boundary stated.

How it worksTalk to us