The whole command system fits on one board

The first question anyone asks about a counter-drone system is how fast it decides. The second question, which matters more and gets asked less, is where it decides.

If the answer is a datacentre, the first question is already moot.

Ten seconds is the whole budget

An attritable threat gives a defender something like ten seconds between "that track matters" and "it is too late to matter." That is the number the whole system is designed around.

Ten seconds sounds like a lot of network round trips, and it is. It is also the entire budget for fusing the picture, re-solving the engagement, putting it in front of a person, and waiting for that person to decide. The human part of that is not compressible. Everything else has to fit in what is left.

So the design rule fell out on its own: the time-critical work happens where the sensors are. Not as an optimisation, and not as an offline mode bolted on beside a cloud one. There is one place the loop runs, and it is the site.

What that actually costs in silicon

The reference node is an Orange Pi 5 Pro. Rockchip RK3588S, eight cores, 16 GB of memory, an NPU, no fan. It runs the server, the console, the simulator and the database together, and it fits in a cabinet.

People tend to assume this is a compromise, and I want to be precise about why it is not.

The work the server does is fusion, planning and the decision loop. All three are CPU-bound, and none of them want a discrete GPU. Association and Kalman filtering are small matrix operations run many times, not large ones run occasionally. A constraint solver assigning effectors to threats is branch-heavy integer work. The agents call out to a model; they are not the model.

What genuinely wants an accelerator is vision, and vision has never been the server's job. A camera doing on-device detection runs its detector on the NPU on the same board, or on a second board beside it. If you are running a lot of cameras, the answer is another node, not a bigger one.

That is the whole argument for the size. Nothing was made small. The workload was always this shape, and the board is what that shape costs.

The link is not a dependency

Here is the part I find most worth defending.

A system that runs at the site does not degrade when the uplink dies. It is not operating in a reduced mode, waiting to be restored. It is the same system it was a minute ago: still fusing, still planning, still holding every action at the line the commander set. What stops is the view from somewhere else.

The conditions under which you most want a counter-drone system working are exactly the conditions under which links are worst. Jamming is not an edge case in this domain. It is the domain.

There is a tempting alternative shape, where the picture is held centrally and pushed outward, with fallbacks for when that fails. The trouble is not that the fallbacks get complicated. It is that they end up load-bearing: the system's normal state is the one that needs the network, and everything else is an exception path you hope was tested. Put the loop at the site and the exception path disappears, because there is nothing to fall back from.

Joining several sites into one picture is then a separate feature rather than a dependency. Each site keeps its own loop, and the wide-area view is something built on top of sites that already work, not something they wait for.

What the board does not change

Being small buys nothing on its own, and a short list of things stay exactly as they are:

• Fusion still branches on what was measured, never on which vendor sent it. A new sensor class is a configuration change: declare its accuracy, reach and field of view.
• Corroboration still buys existence, never identity. Three sensors agreeing proves something is there. A track is never marked hostile from its kinematics alone.
• Every action still sits on the ladder. One level per action, the line saying what runs without asking, the ceiling saying what exists here at all, enforced in the engine rather than in a prompt. The agents propose. They have no tool that fires anything.

None of that gets cheaper because the computer got smaller. It is the same code, and the tests are the same tests.

Where this is going

The board runs the stack today and the loop closes on it. What I want next is the boring, unglamorous version of this claim: the same node in a cabinet at a real site, on sensors somebody else owns, in weather, for a week. Simulation tells you the loop is correct. It does not tell you what the emplacement is like, or what the operator actually does at 3am.

That is the next thing I will write up, once there is something to write.