Skip to main content
Defense TechGeopolitics & Defense

Military Software Must Operate Offline to Ensure Reliable Decision Support

Military officers study maps and use a laptop in a well-lit operations center.

Armed forces need greater robustness from the systems they are increasingly using to support combat decision‑making: if communications links go down, those systems must still keep satisfactorily advising officers on decisions, because those links must be expected to fail.

Why delegation to lower‑level commanders depends on reliable software

Delegation to lower‑level commanders improves combat effectiveness because action can continue even when higher officers lose the ability to direct. The article stresses that sometimes higher command, though still in contact, will want lower officers to take control because those officers "may have better and faster awareness of what is going on." Decision‑support software can amplify that benefit by offering expertise a local commander may lack and by easing cognitive load — for example, by recommending which of three dispersal sites for an air‑defence battery is best, deciding which casualty evacuation task should go first, or assessing which track of an unknown unit has met the threshold for reporting as hostile.

Property 1: local computation on the node

The first required property is simple and technical: the software must make the decision‑making computation locally, without relying on a remote server. "The model and the rules should sit on the node in front of the operator, where the recommendation should be produced." That design choice brings unavoidable limitations: "A system that fits on a vehicle or a field server is less capable than one running in a data centre, and it sees only what the local node can see." But it also means performance "will not fall off a cliff when the comms go down," even though moving enemy units and time‑sensitive data will age and be less reliable after a link fails.

Property 2: national control and the right to run

The second property is control: decision‑support software must be under national control so "no vendor and no foreign government can alter, withhold or revoke its behaviour mid‑crisis." The article notes that while systems will likely include imported components, the operating country "can and must have the legal right and technical ability to run it without ongoing permission." That legal and technical autonomy is presented as a safety requirement for delegation of decision authority.

Property 3: traceable reasoning and survivable records

Third, the software must produce a traceable reason for each recommendation rather than only a confidence score. Because "a person accepting legal responsibility for a decision must be able to state the grounds," the system needs to record what input data was used, what rules applied, and what thresholds were crossed. Those records must "survive a communications outage, because reconstruction happens afterwards." Traceable reasoning also underpins interoperability: when "two countries’ armed forces are operating side by side, each will need to understand why the other’s decision‑support software has made a recommendation."

Property 4: loud degradation and withholding of obsolete advice

The fourth property addresses honesty under failure: automatic decision‑support must degrade loudly. If it loses access to data, it must say so; it must indicate when it is relying on old information and, when the information is "just too old," it must withhold recommendations. The article warns of two failure modes: an operator may distrust isolated software and choose inaction just when action is needed, or, conversely, isolated software may "keep making seemingly confident recommendations using data that is now hours old and not acknowledge the shortcoming."

What this means for Australia, lower‑level commanders, and vendors

  • Australia: The article points to Australia's 2026 Defence Industry Development Strategy as an existing vehicle to implement improvements, noting the strategy "already prioritises national industrial capacity for the integration of battlespace management systems and their testing, evaluation and certification." It argues defence should define a certification standard for decision‑support software analogous to airworthiness and seaworthiness.
  • Lower‑level commanders: They need decision aids that remain usable and honest in isolation — systems that explain their recommendations and clearly flag stale inputs so commanders can accept legal responsibility with evidence for why they acted.
  • Vendors and suppliers: They must enable lawful, local operation and survivable logging; the article insists that no vendor or foreign government be able to "alter, withhold or revoke" behaviour mid‑crisis.

Communications links are "at risk to jamming, air and missile strikes, sabotage and the breaking of undersea cables," the piece reminds readers, and "bringing down the enemy’s comms is a basic objective in warfare." Given that reality, the four properties—local computation, national control, traceable reasoning, and loud degradation—are proposed as a serviceable first draft of certification criteria. Defence should define such a standard, the article concludes, because militaries already certify airworthiness and seaworthiness but have no equivalent standard for decision‑support software even though it is now in use across every warfighting domain.

Read the original article