AEGIS GIMS
detecting the one vehicle that matters
A geospatial command interface that turns a map of everything into a single answerable question: has the enemy entered my zone? I was handed this scenario as a design problem. My working hypothesis: filter the map down to the area that matters. Then I built it as a live system, to test whether that answer actually holds.
"We need a map. We need to see enemy vehicles on it."
That's roughly how the requirement arrives, from leadership, through a contract, with a lot left unsaid. From those words the obvious build almost designs itself: a map, a search box, every track rendered, click anything to see everything about it. It demos beautifully.
The catch is the conditions this thing actually runs in. They reshape every decision, so I wrote them down first.
Geofencing, alerting and inference all have to run locally, on the edge, with comms that drop.
A fix can mean someone flying to a classified site to install it. You design to get it right the first time.
Real operators sit in classified spaces, maybe thirty verbal minutes, no devices in the room. You reason your way to the answer.
A laptop in a vehicle in the desert, and a workstation at headquarters. The picture has to stay legible in both.
It shows everything. That's the problem.
Built literally, the map answers "where is everything?", friendly patrols, civilian traffic, maritime contacts, air tracks, sensors, all live at once. In a quiet office you can scan it. In a command vehicle on a bad link, mid-task, it's noise. The operator becomes a search engine for their own battlespace.
One operator owns one stretch of ground.
The story that reframed it, reconstructed from my notes: a single soldier is responsible for one segment of a route, between two points on a highway. Their job isn't to survey the whole theatre. It's to notice the moment something hostile crosses into their ground, and tell leadership, fast.
Put plainly, the brief said "show me vehicles on a map." The actual job was narrower and sharper:
When an enemy vehicle enters the ground I'm responsible for, alert me and help me report it up the chain, without making me hunt for it.
A search-everything map is the wrong shape for that job. The job has a place (a zone), an event (entry), and an action (report up). The interface should be built out of exactly those three things, and nothing else by default.
The hypothesis, then the working system.
Reading the problem, I didn't reach for a better map. I reached for a filter. Stop presenting the whole battlespace. Let the operator declare the area that matters, and let everything else fall to context. That was a hypothesis, not a finding. Confirming it's genuinely the right fit is a job for user testing, internally and then in the field, not my judgement alone. Two ways in, same result:
Sketch the zone straight onto the map, rectangle, circle, or triangle. The shape you draw becomes the live filter, and its handles stay draggable, resize a side, distort a corner, grow a circle, and the filter recomputes as you adjust.
Tasking often arrives as grid references. Enter a lat/long and a radius and the system places the zone for you. One mechanism, two honest entry points, identical result downstream.
A hostile track crossing the boundary fires the event, and carries the report up the chain.
How it works, up close.
The shape you draw is the filter.
Pick up the draw tool, sketch the segment of route the operator owns, release. Every track outside the shape dims to context in the same gesture. No settings panel, no query language, the act of defining the ground is the act of filtering. Drawn it slightly wrong? Drag a side to resize, a corner to distort, the rim to grow a circle, and the filter recomputes as you adjust.
When the grid reference is already known.
Tasking often arrives as coordinates, not a hand-drawn shape. So the same filter can be defined by typing a lat/long and a radius, the system places the zone for you. One mechanism, two honest entry points, identical result downstream.
Each zone carries a type, a priority, a classification, and trigger rules, enter, exit, dwell, so the boundary means exactly what the operator says it means.
Crossing the line is the event.
As the timeline runs, a hostile column moves up Route Crimson and crosses the boundary. The moment it does, the alert fires, and it isn't a dead notification: it carries the one-tap action the job actually needs, report up.
One click to the "so what."
Selecting a track opens its assessment, affiliation, kinematics, reporting, and an AI threat score with a recommended action in plain language. The model assists the judgement; it never makes the call, and it always shows its trail back to the raw artefact.
The same battlespace, before and after the filter.
Try it. The whole argument, live.
Draw a zone over the route, rectangle, circle, or triangle, then drag its handles to reshape it, or define it by coordinates. Toggle Everything ↔ Signal. Press play and watch the column enter. Click any track for its assessment.
No internet. No cloud. It still has to work.
This is the constraint that quietly governs everything. The platform runs in a vehicle in the desert, on a vessel, in a tent at a forward base, places with no public internet, often no reliable link at all. So the honest question for any feature is: does it still function when the network doesn't? For the zone filter, the answer has to be yes. Here's how each piece works when it's cut off from the world.
Mission-area map packs, elevation (DTED), imagery, and vector terrain are loaded onto the device before it ever leaves the wire, then cached locally. The map you see is reading from disk, not a tile server.
No internet required; the satellites are the network. In GPS-denied conditions it falls back to inertial dead-reckoning and a manually confirmed grid reference, so the picture never goes blind.
Positions arrive over tactical datalinks, radio, and on-board sensors, ingested directly on the device. When a link drops, the last known picture holds and ages visibly rather than vanishing.
"Is this track inside my zone?" is a geometry test the device does itself, every update, no round-trip. The threat-assessment model is an on-device build (here, aegis-geo-1.4). Both fire with the antenna unplugged.
"Report up" composes a structured contact report, grid, time, classification, track, and hands it to the existing datalink or radio bearer. If no bearer is live, it queues and sends the moment one is.
Software and fresh map packs are sideloaded physically at a secure site, the multi-month cycle that makes "get it right the first time" non-negotiable. Connectivity is a bonus, never a dependency.
On a laptop bolted into a moving Jeep, with gloves and a small screen, sketching a precise polygon is the wrong ask. But orders arrive as grid references, so the operator types the coordinates of the ground they've been assigned, the zone snaps into place, and the filter is live. Drawing is for the headquarters workstation; coordinates are for the field. Same mechanism, met where the operator actually is.
Building it validated the hypothesis.
I didn't reach for filters because they're tidy. I reached for them because, under this domain's constraints, a zone filter is the smallest mechanism that actually serves the job. Worth being precise about what a prototype proves, though, it shows the logic holds together, not that it fits the operator's real task. Confirming that is the next stage.
Place, event, action, zone, entry, report. Built from the job-to-be-done instead of a literal reading of "show vehicles on a map."
A drawn boundary is something an operator can trust and predict, critical when you ship to an air-gapped site and can't patch a surprising behaviour for months.
Geofence-and-evaluate is local logic. No cloud, no round-trip, it keeps working when the link drops, which is the normal case here.
Hostile entry escalates; civilian traffic is held for triage. The filter isn't just spatial, it respects affiliation, so the alert feed stays trustworthy.
A defined zone is a single object a commander can hand to the next watch or push to another operator, collaboration with no extra UI.
Filter-first wasn't a guess. Putting it on screen stress-tested the hypothesis, and the prototype is ready for user testing to find out if it is indeed a strong fit for the job.
Prove the fit with the people who'd carry it, not just the logic on screen.
Building the prototype stress-tested the reasoning; what it can't tell me is whether the concept fits the operator's real task. The honest way to find out is user testing, first internally, then out in the field. Internally, moderated sessions with analysts and operators against realistic scenarios, watching whether "draw the ground, entry is the alert" matches how they actually reason. In the field, trials on the real surfaces, the vehicle laptop and the HQ workstation, under load and on a degraded link. What I'd watch: time-to-detect entry, missed and false alerts, whether draw versus coordinate gets used as predicted, and whether operators trust the boundary enough to rely on it.
And the strongest version of that test isn't mine alone. I'd put this A/B against a competing concept from another designer, same scenarios, same operators, same measures, and let the results pick the direction. Zone-as-filter is one answer to the brief, not the only one; if a different model detects faster or earns more trust under load, that's the one that should ship. The point of testing is to beat attachment with evidence.