When you shoot down an attack drone — a Shahed — over a city, the problem doesn't end at the interception. The debris falls: the engine, the warhead, the panels. Somewhere below, there are people.

Existing counter-drone command software can detect and track a threat. Existing interceptors limit collateral damage by method — nets, parachutes. But nobody closes the loop: predict where the debris will land, cross it with a population map, and pick the safest interception point. That gap is exactly what Icarus fills.

It is neither a weapon nor an interceptor controller. It is a decision layer — a planning tool that answers a single question: where and when do we intercept so the falling debris lands in the least dangerous place possible?

A simulation coupled with a web visualization. The system predicts the attacking drone's trajectory, simulates where debris would fall for every feasible interception point, scores each outcome against a city danger map, and recommends the point that minimizes expected harm on the ground.

Three layers do the work:

1. The danger matrix. A georeferenced grid of the city, values from 0 (safe — river, field) to 10 (catastrophic — dense block), rendered server-side as a raster overlay on the map.
2. The engine. Radar detection, trajectory prediction, ballistic integration of the debris fall, and the optimizer that searches for the best interception point.
3. The front end. A React + MapLibre app consuming a live WebSocket stream: target, interceptors, predicted track, debris footprint and score, tick by tick.

Debris does not fall straight down under the interception point. Each piece keeps the drone's horizontal velocity and is pushed by wind as it falls:

landing_point ≈ intercept_point + (drone_horizontal_velocity + wind) × fall_time

To drop the lethal core — engine, warhead casing — into a safe cell (a river, a field), you have to intercept upstream of that cell, by the exact ballistic offset. Dense parts fall fast and land near the offset; light parts drift far downwind. The result isn't a point but an elongated footprint. That's the whole job of the optimizer.

The backend is Python — this is geospatial work, physics and optimization, the natural home of numpy / shapely / pyproj. All computation happens in meters in a local metric frame; we only convert to lat/lon at the I/O boundary. FastAPI serves the HTTP and WebSocket stream; Pillow renders the danger grid to PNG.

The backend splits into two independent tracks, so two people can work in parallel:

• risk/ builds the danger matrix and outputs a georeferenced DangerGrid.
• engine/ consumes that grid together with radars, attacker and interceptors, and returns the best decision.

The contract between them is a single type. The front end is display-only: it renders whatever the WebSocket stream sends it.

The optimizer runs continuously while the target is tracked, then locks the decision once the interceptor launches:

1. Predict the attacker's path (straight line at constant velocity for v1).
2. Enumerate the feasible interception points — those at least one defense drone can reach in time, given its speed, range, climb rate, launch delay and max altitude.
3. For each point, compute the debris footprint: for every component, integrate its fall in 3 degrees of freedom with drag + wind, from cruise altitude, starting at the drone's horizontal velocity.
4. Score the footprint against the danger grid — with a penalty for unexploded ordnance (UXO).
5. Choose the minimum-score point, and return the ranked list of alternatives.

The search is cheap: a 1-D scan along the predicted track, no heavy solver required.

Three days, non-stop. Friday evening the kickoff, Sunday noon the deadline — continuous build, the two of us, with Clément. It closed with a pitch in English, slides only, in front of close to a hundred people.

The project won't be deployed, and that isn't the point. What I keep: a prototype I'm genuinely proud of, physics we learned on the fly under time pressure, and above all the people. Profiles from everywhere, fields I'd never otherwise cross, Ukrainians for whom the problem is anything but abstract. One of the most enriching experiences I've had — as much for what we built as for the people we built it with.

The demo ran two live scenarios — Odesa and Dnipro: an inbound target, the interceptors, the predicted track and the scored debris footprint, all updating tick by tick.

What resonated most with the jury was the problem itself — how sharply real and unsolved it is. Relevance scored a 9 out of 10, several jurors giving a perfect mark. With one more week, the two things I'd ship first: real danger sources — population rasters like GHS-POP in place of the hand-built matrix — and a Monte-Carlo debris dispersion, turning the single-trajectory footprint into a probabilistic one.

Three days compress a lot of learning. Three things stuck.

Physics you can defend, not physics that's perfect. With a weekend on the clock you don't chase the exact ballistic truth — you build a model you can stand behind, explain, and know the edges of. Learning where "good enough" sits is half the skill.

Two tracks, one contract. Splitting the work into risk/ and engine/ around a single shared type let Clément and me move in parallel without colliding — the clean boundary is what made two people faster than one, not slower.

What I'd revisit. Ground the danger map in real population data and turn the deterministic footprint into a probabilistic one — the model deserves better inputs than a weekend allowed.

But the lesson I'd actually hang on the wall isn't in any of that. It's the people — the ones you meet, the moments you share, the values that surface when a room of strangers pulls toward the same thing for three days straight.