Threat Map — Comparison
LAYER 2Both maps update live with the settings below.
Scenario Library
SELECTClick a scenario to load it into the primary (left) map; set the right map with its own picker to compare.
Model Basis & Methodology
OBJ 1–5How each Phase I requirement is represented in the engine.
Each engagement zone is intended to be generated from weapon parameters — sensor/detection range, kinematic max-range and the inner no-escape zone — with aspect and altitude dependence, rather than authored shapes. Further work: replace illustrative ellipses with a fly-out/energy model and 3D engageable volume.
The score is intended to be computed as P(Survive) = 1 − Π(stage probabilities) along the detect→track→launch→intercept→hit→kill chain — not a drawn curve. This makes every score decomposable, which is what feeds the ranked-driver explanation. Further work: derive stage probabilities from the WEZ physics and engagement geometry.
The ± confidence interval shown across the console is intended to come from propagating input uncertainty — nav error, wind, sensor noise — through the model (Monte Carlo / error propagation), shading the band wider in contested airspace. Further work: wire real input distributions and calibrate coverage.
Ranked drivers are intended to be a model-derived sensitivity of P(Survive) to each input, not a fixed list — the basis for traceable, defensible attribution. Further work: compute local/global sensitivity from the real model.
Threat envelopes are a 3D volume with a ceiling; survivability depends on the route's vertical profile through it. Further work: full 3D geometry and altitude-dependent exposure.
Evasion respects airframe G-limits and minimum turn radius (r = v²/g√(n²−1)) — a nonholonomic constraint current path-planners often ignore. Further work: 3D nonholonomic maneuver model bounding feasible reroutes.
A modular, software-defined engine intended to ingest representative threat/platform/mission data and run at the edge (ARM/x86), integrating with C2 / mission-planning ecosystems. Further work: real ingestion adapters, edge runtime benchmarking, and integration interfaces.
Phase I defines a validation harness with explicit acceptance targets — monotonicity/sanity checks, confidence-interval calibration, runtime on representative hardware, and an automated scenario sweep. Values shown are targets, not measured results; they will be populated with validated runs against representative threat data.
Explainable Decision Support
LAYER 4—How this score is computed
P(Survive) is the modeled probability the own-ship survives the current threat picture, on a 0–1 scale.
- Each factor — engagement-zone overlap, adversary closure, wind disturbance, and sensor exposure — is scored live from the route geometry and conditions.
- Factors are ranked by contribution; each bar shows how much that factor is weighing on the assessment right now.
- The weighted factors reduce a baseline survivability to produce the P(Survive) score.
- Uncertainty in the inputs is carried through to a confidence interval (± CI), which widens in contested airspace.
Illustrative feasibility model for demonstration — not a validated probability-of-kill computation.
Own-ship remains clear of modeled engagement envelopes; survivability is driven primarily by ambient conditions. Confidence is high.
- Envelope overlap← threat geometry, own-ship position
- Adversary closure rate← adversary trajectory
- Hi-alt wind disturbance← environment inputs
- Sensor exposure← route, EW interference
Uncertainty widens inside contested airspace and narrows once the own-ship clears the engagement zone.