Deciding where to put a guard post usually means asking four specialists four different questions, in four different programs. A terrain analyst maps the ground. An intelligence officer maps likely approach routes. An officer who plans strikes works from printed tables. A construction officer works in design software and a separate cost-estimating program. Each one answers their own question well. None of them can see the others' assumptions.
That gap shows up the moment a question touches more than one specialty. Raise the watchtower three meters and visibility improves, but nobody in the room can say, on the spot, how much the construction cost rises, how much more visible the post becomes to the other side, or how many minutes earlier an approaching group would be spotted.
The four specialties use different software, and they also change on different schedules. A post's line of sight, what a given point can actually see across the terrain, only changes when the post itself moves. Detection probability changes constantly, with every shift in weather. The slow part is visibility across the whole terrain, which only changes when the post moves. The fast part is weather, which changes constantly. Combining those into one live system means not recomputing the slow part every time the fast part changes.
Instead of rewriting four specialists' worth of expertise from scratch, we combined four existing, working programs into one system, leaving each unchanged: a 3D terrain and rehearsal program, a tactical decision program carrying military doctrine data (including ammunition tables and a detailed estimate of likely collateral damage), a site design and cost-estimating program, and a report-writing program. The code written specifically for ARGUS, about 22,490 lines, is limited to the connections between these programs and logic specific to this project. Our rule: copy the original files as they are and call them directly, because a rewritten copy eventually drifts from the original, and once it drifts, nobody can tell which version is right.
ARGUS is organized into eight tabs, each answering one question off the same shared terrain and the same current weather:
Two decisions anchor the system. First, the numbers always come from the calculation engine, never from the built-in assistant that helps with design chat; we instructed the assistant, directly in its setup, never to invent a coordinate or a building placement. Second, every fix goes all the way through: when the system flags a surveillance gap, a separate part of it computes an actual recommended location to close that gap, instead of stopping at the diagnosis.
The eight tabs cover a lot of ground; the results below highlight three of them, Placement, Surveillance, and Operations analysis.
In one test run, starting from an empty site, the placement engine designed four structures and laid out the full site in under three seconds. That raised joint sensor coverage from zero to 49 percent, at an estimated cost of $1.7 million.
Sweeping the same layout through six weather types and three intensities showed something a written spec sheet would miss: which sensor works best changes with the weather. On a clear day with radar on, every approach route is detected instantly. In night fog with radar off, detection slows by two to seven minutes and nearly half the coverage picture goes dark. At that point, the system recommends adding an acoustic sensor.
One evaluation flagged an approach route with a complete surveillance gap. ARGUS then computed a specific new observation position that would raise coverage on that route from 12 percent to 54 percent, closing about half the blind spots, while keeping the new position outside the range of the nearest identified threat.
Building this also surfaced ordinary, useful bugs: a cost field that silently showed a dash instead of an error when two missing values were added together, a click target too small to select on screen, a popup that swallowed a user's second click mid-drawing. Catching these took an unusual step: running the finished system through a real, automated mouse and keyboard instead of simulated computer commands, because the 3D map library doesn't respond to simulated ones.
The terrain, sightline, and sensor modeling are real, and the rest of the system depends on them. The construction side is not as far along: it currently uses a civilian building-cost model, so grading and retaining-wall costs are solid, but soil-hauling, drainage, and access roads are not yet modeled. Structural hardening is represented by a single placeholder number, not broken down into standoff distance or material grade. There is no schedule model at all, so ARGUS can say what something costs but not when it would be finished. The automated placement engine doesn't yet optimize for how visible a post would be to the other side; it tends toward good ridgelines because of how the terrain math works out, not because it's told to avoid exposure.
We're now working on scaling the same approach from one post to an entire line of them, viewed together.
A company that runs a promotional-products franchise network used to pay for a pricing tool it could never actually own. Rian rebuilt it from scratch, handed over every line of source code, and made it four times faster in the process.
A newsroom's international desk used to lose the first hour of every morning just figuring out what was new. Now a tool does that overnight, and flags which stories the desk is likely to run.
Ocean's Halo ran its packaging supply chain across spreadsheets owned by three companies, retyped by hand at every handoff. One dashboard now shows what needs attention, and the plants and the supplier enter their own numbers.
