Use case 02 / Counter-UAS
The last ten seconds.
Radar saw the drone minutes ago. The fight is now: which track matters, which effector, and who said yes.
One contact per object
Fused from every sensor
Ranked plans, every pass
Scored on leakers, cost, coverage
Deterministic replay
The same raid, run again
A five hundred dollar drone forces a defender to spend a missile that costs millions, and saturation raids put more tracks in the air than a fire-direction crew can hold. The sensors are not the bottleneck. The bottleneck is the decision: which of three hundred tracks matters, which effector kills it cheapest, and who authorised the shot, all inside the seconds an attritable threat allows.
The track that matters, with its evidence
Fusion resolves every sensor into one contact per object, scored for threat continuously: closest point of approach, time to impact, confidence, and the sensors behind each number. The one track that matters surfaces out of the three hundred that do not.
The cheapest effector that works
Each solver pass authors ranked plans under real limits: magazine depth, effectors per target, interceptor reach, commit timing. Every plan is scored on predicted leakers, cost and coverage, so a costly interceptor is not spent on a cheap drone. The operator compares and approves; under saturation, the posture can pre-approve.
The shot is answerable
Tasking goes out through the gate set for that effect, and every firing, clamp and approval is logged with its rule and its subject. After the raid, the run replays identically, so the decision can be inspected rather than remembered.
Rehearse before it happens
Saturation is rare and unrepeatable in the real world. In simulation it is neither: describe a raid in plain language, run it against your laydown, change one thing and run the identical fight again.
Where to go next
- Sensor fusion for where the track comes from.
- Solver configuration for the profiles and their weights.
- Simulation for authoring and replaying a raid.