Phase 1 of 6
Scoping & Training Objectives
Define the wargame purpose, training audience, classification envelope, and the constraints that govern what a red-force agent or synthetic environment is actually allowed to do.
0/10
Phase Progress
Required Recommended Optional Open-Source Proprietary Trinidy
Wargame Purpose & Training Audience
Identify the wargame / simulation class in scope
Why This Matters
The DoD Modeling and Simulation Coordination Office (M&SCO) distinguishes training, analysis, and acquisition M&S categories because each carries different validation burdens under DoDI 5000.61 and DoDI 5000.83. An AI red force that is "good enough" for an individual trainer is not automatically acceptable for JCIDS analytical wargaming, and a scenario generator suitable for campaign-level constructive play may be too abstracted for STE-class individual training. The most common failure is scoping an AI capability to one class and silently reusing it in another.
Note prompts — click to add
+ Which classes share enough fidelity requirements to justify a common AI stack, and which require dedicated models?+ Who is the accreditation authority for each class of simulation we intend to support?+ Have we reviewed M&SCO VV&A policy against the highest-fidelity class we will support?Select every class of simulation the AI will be deployed into — the fidelity and validation bar differ by class.
Select all that apply
Define the training audience and learning objectives
Why This Matters
CJCSI 3500.02 Joint Training Policy and CJCSM 3500.03 Joint Training Manual require that every training event tie to specific Joint Mission Essential Tasks with measurable performance standards. An AI-driven red force or synthetic environment that does not map cleanly to the audience's JMETs cannot contribute to formal training readiness reporting, no matter how technically impressive. Scoping the audience first is how you avoid building a scenario generator that no training command will accept.
Note prompts — click to add
+ What JMETs or service METs does this AI capability support, and are they already on the training command's CJCSM 3500.03 list?+ Who signs the training objective letter that this AI is meant to satisfy?+ Is the audience sophisticated enough to distinguish a high-fidelity AI red force from a scripted OPFOR, or will the delta be invisible to them?Specify which commands, staff elements, or individuals will train against this AI and what they must be able to do afterward.
Select all that apply
Select AI wargaming capability class
Check every AI capability this builder must deliver.
Select all that apply
Establish simulation-time and real-time performance targets
Why This Matters
DARPA's AlphaDogfight Trials (2020) ran AI pilots inside a simulation operating at tactical flight rates, and the Heron Systems agent that went 5–0 against a human F-16 pilot was operating at simulation timesteps that leave single-digit milliseconds of compute per decision. Analytical runs have the opposite constraint — RAND's publicly described "1,000 runs overnight" design only works if the AI can run far faster than real time, which requires a fundamentally different deployment pattern than a 60 Hz hard-real-time trainer.
Note prompts — click to add
+ What is our simulation tick rate today, and can our inference fabric hold it at the peak agent count we need?+ Do we need both real-time training and faster-than-real-time analytical modes from the same AI stack?+ What is our graceful-degradation behavior when the AI cannot hold tick rate — agents freeze, fall back to scripted, or the sim slows?Select the pacing the AI must hold inside the sim loop.
Single choice
Trinidy — Cloud-routed inference cannot meet tactical simulation tick rates at 1,000+ agents — the aggregate per-tick inference budget disappears in network round-trip alone. On-prem inference on the same classified training LAN as the simulation federate is the only architecture that holds pace without degrading resolution.
Declare the classification envelope up front
Why This Matters
A red-force AI trained on classified adversary doctrine inherits the classification of its training data — the model weights themselves become a classified artifact requiring classified storage, transmission, and disposal. Operating at multiple levels through a single model is not a configuration toggle; it is an architectural decision that must be made before any training data is touched. Scenarios tested against real operational concepts commonly run at SECRET or above and cannot be hosted on commercial cloud wargaming platforms.
Note prompts — click to add
+ Where will the trained red-force model be stored at rest, and is that enclave accredited for the classification of the training data?+ Who owns the original classification authority for adversary TTP data we plan to train on?+ Have we defined a lower-classification analog for unclassified exercises, or will every use require the classified enclave?Select every classification level the AI stack must operate within.
Select all that apply
Trinidy — Classified red-force models trained on adversary TTPs are themselves classified artifacts. Trinidy keeps training data, trained weights, and inference entirely inside the customer's classified enclave — no cloud transit, no vendor-side storage, no cross-domain handoff during the AI lifecycle.
Map ITAR and export-control obligations
Why This Matters
Military simulation environments and their AI components are routinely captured under ITAR USML Category XI (military electronics) or Category IX (training equipment). Export to partner nations requires either ITAR licensing or a specifically constructed releasable analog; building the same capability twice is cheaper than discovering an export violation after the fact. ITAR controls bite especially hard on cloud-hosted training data because the deemed-export rule can be triggered by foreign-national system administrators at the cloud provider.
Note prompts — click to add
+ Is the adversary TTP data we plan to train on ITAR-controlled, and under which USML category?+ Who is our empowered official or ITAR point of contact, and have they reviewed the training-data pipeline?+ If we anticipate coalition use, have we defined the releasable feature set before training begins?Adversary TTP models, tactical simulators, and AI components are frequently ITAR-controlled — confirm the export posture before the first line of training code runs.
✓ savedAlign with DoDI 5000.82 and DoDI 5000.83 acquisition posture
Why This Matters
DoDI 5000.82 establishes requirements for the acquisition of digital capabilities, and DoDI 5000.83 governs T&E for software — both apply to AI-enabled simulation components fielded as program of record capability. A wargaming AI that drifts out of prototype into operational use without the corresponding T&E master plan is a finding waiting to happen, and it blocks the transition from tech demo to sustained capability.
Note prompts — click to add
+ Is this capability chartered under the Software Acquisition Pathway, or is it a research/experimentation effort that will need a transition plan?+ Who is the T&E lead, and do they have a T&E Master Plan that treats AI behavior as a testable characteristic?+ How do we handle the DevSecOps release cadence for a model that retrains as new intelligence arrives?Confirm how this AI capability maps to the Software Acquisition Pathway and the T&E policy that governs it.
✓ savedConfirm distributed simulation interoperability standard
Why This Matters
Most joint and coalition exercises federate simulators using HLA (IEEE 1516) or DIS (IEEE 1278) — an AI red force that does not publish and subscribe on those buses is a standalone demo, not a federate. Getting the FOM or PDU set right early is how AI components become reusable across STE, AFSIM, OneSAF, VBS4, and whatever comes next. Retro-fitting HLA compliance onto an AI that was built for a single engine is expensive.
Note prompts — click to add
+ Which FOM / PDU set do the federations we care about currently run, and does our AI publish those object classes?+ Do we need a gateway to bridge between DIS legacy federates and an HLA-Evolved-only AI?+ Has the AI been tested inside a dry-run federation with actual federates before the exercise?Select the distributed-simulation protocol the AI must interoperate with.
Select all that apply
Define deployment topology for the AI compute fabric
Select the physical and network deployment target for model training and inference.
Single choice
Trinidy — For classified red-force agents and ITAR-controlled TTP models, a commercial cloud inference endpoint is physically and legally incompatible. Trinidy is the on-premises substrate — training farms and inference nodes deploy into the same classified training network that hosts the simulation federates.
Identify stakeholder / accreditation authority
Why This Matters
DoD M&SCO VV&A policy places the accreditation decision with the user of the simulation, not the builder — which means the builder must produce evidence tailored to the accreditor's intended use. Without naming that authority up front, teams build validation artifacts that answer the wrong question and have to redo the work.
Note prompts — click to add
+ Who will accredit this AI for its intended use — JFCOM J7, a service training command, a PEO, or a service lab?+ Have we engaged the accreditor before development starts, rather than at delivery?+ What prior VV&A precedents exist for AI-driven red forces that we can reuse as a template?Name the accreditation authority that will sign off on the AI being used in a formal training or analytical event.
✓ saved