Skip to main content

Simulation

No sensors, no aircraft, no install. Author a raid, defend against it, and run the same fight again after changing one thing.

Simulation is where most people should start, and not only as a demonstration. The sensor models are the real ones, so what you learn transfers: a bearing-only sensor still cannot localise, contacts still firm up as they close, and a saturation raid still overwhelms a plan that was tuned for three contacts.

What that lets you do before buying hardware:

  • Decide what sensor mix you need. Lay out a site, run a raid, see whether the picture firms up early enough to matter. See Sensors.
  • Tune doctrine. Posture, rules and planning weights all behave the same way against simulated contacts as against real ones.
  • Train operators on a fight that is repeatable, rather than waiting for a real one.
  • Prove a decision. Run the same raid twice with one thing changed, and the difference in outcome came from your change.

Synthetic threat raids​

Real saturation attacks are rare, expensive to stage, and impossible to repeat on demand. DomeCommand generates them instead. You compose a raid from realistic threat types (long-range loitering munitions, cheap FPV swarms, reconnaissance drones, cruise missiles) and choose how many come, from which direction, and when. The result behaves like a real attack: contacts appear on your sensors, close on your assets, and force real decisions.

Because the generated raid is deterministic, the same raid plays out the same way every time you run it. That repeatability is what turns a simulation into a rehearsal: you can run the identical fight twice, change one thing in between, and trust that the difference in outcome came from your decision, not from luck.

Scenarios​

A scenario is a complete, saved fight you can load like a level. It bundles three things:

  • A theatre, where the engagement happens: a real geographic area, rendered over live satellite imagery, or anchored to specific buildings to protect.
  • A laydown, what you have to defend with: the placement of your sensors and effectors around the area.
  • A threat package, what's coming: the raid, its waves, and their timing.

On top of that, a scenario can include injects, things that go wrong mid-fight: a sensor blackout, a degraded radar, a comms loss, an effector going down, or a change in the rules of engagement. This is how you pressure-test the hard cases, not just the clean ones.

Author scenarios in plain English​

You don't have to assemble a scenario by hand. Describe the fight you want in ordinary language and DomeCommand builds it:

"A saturation swarm of 60 FPV drones from the north-west, with a two-minute radar blackout halfway through, defending the downtown district."

The C2 Copilot turns that into a runnable scenario, theatre, laydown, threat package and injects, ready to play. Tweak it in words, run it, and save it to your library.

Authoring a scenario in plain English
Authoring a scenario in plain English
Describe the fight in plain language; DomeCommand composes a runnable scenario from it.

Built-in drills​

DomeCommand ships with a set of ready-made stress tests you can drop in immediately:

  • Saturation surge, a sudden spike in the number of incoming threats.
  • Sensor blackout, a key sensor goes dark and the picture degrades.
  • Comms loss, a link drops and tasking is disrupted.
  • Effector down, one of your defences is taken out of the fight.
  • Rules-of-engagement shift, posture tightens or loosens mid-engagement.

Each is a clean way to see how the system, and you, respond when something breaks.

Replay and compare​

Every run is recorded: threats stopped, leakers that got through, cost spent, and how much of your protected assets survived. Because runs are repeatable, you can put two of them side by side, same fight, different decisions, and see which posture actually did better. That comparison loop is the real value of rehearsal: it turns a dramatic demo into evidence.

Where to go next​