Moving from ‘Decision Support Systems’ to Architectural Oversight

[Noah Sylvia is a Research Fellow for C4ISR and Emerging Tech at the Royal United Services Institute.]

As advanced digitalised systems have become ubiquitous in modern warfare, the policy community primarily engages with these technologies through discussion of Decision Support Systems (DSS). DSS (or sometimes AI-DSS) encompass the range of digital systems used in decision-making processes, especially those incorporating some type of AI. 

While serving a useful purpose at the time, continued focus on ‘DSS’ now inhibits the sector’s ability to move towards effective international governance on digitalised military systems, and should be discarded in favour of architectural frameworks of oversight. 

The Problem Set and DSS’s Progress

On the subject of military technology and IHL, opinions are varied on where priorities should lie, ranging from the sufficiency of existing IHL for the use of military AI, dehumanisation due to increasingly technical means of waging warfare from a distance, the dangers of automation or autonomy in targeting, to the dual use nature and potential targetability of digital technology infrastructure and contractors. While the specific focuses differ, I posit that our cohering problem set is essentially the increased use of complex digitalised systems to enable, support, and execute military operations in a manner that has the potential to undermine responsible and legally-compliant military conduct. Analysis using DSS as the framing terminology has permitted the policy community to progress significantly in their analysis and assessments of this problem set. 

DSS are typically defined along the lines of ‘tools that…collect and analyze data, provide information about the operational environment as well as actionable recommendations, with the aim of aiding military decision-makers in evaluating [relevant] factors’. Whether defined as ‘tools’ or ‘teammates’, DSS thus typologises digital systems based on a functionalist approach, defined by ‘decision-making functions’ like ‘ingest’, ‘generate’, ‘enable’, ‘automate’, ‘share’, and ‘interface’. Originating in many ways to contrast the focus on lethal autonomous weapons, DSS thus aided non-technical experts in grasping and discussing a conceptual layer of technology that is one step abstracted from physical platforms. Conversations could now begin to address some of the many tools, platforms, and applications comprising the modern battlefield digital architecture.

By moving away from weapons platforms to software systems, DSS terminology expanded how legal and policy experts could understand how military processes align with the digital systems enabling them. Several publications have mapped the components of combat processes like targeting, highlighting where DSS influence, shape, and even direct elements of the targeting process, as well as teasing out the frictions, legal vulnerabilities, and human-machine misalignments involved. 

Yet despite the progress made using DSS as a framework, the shortcomings of reliance upon the term begin to become apparent.

The Limitations of DSS

DSS views digital technologies at the ‘system’ level, framing these systems as discrete objects embedded into decision cycles that can be isolated from their context for assessment, regulation, and even potentially prohibition. The reality of digitalised warfare cannot be fully reflected in such a narrow focus, as there might be hundreds of systems involved in a single battlefield decision, each of which is interacting and integrating with each other while being constantly iterated and replaced. 

Many system-level analyses or legislative mechanisms would therefore fail to address the structures underpinning the countless systems in use, while also failing to encompass the sheer scale and diversity of digital systems in questions. The digital systems referenced when using ‘DSS’ comprise everything from an enterprise workflow orchestration tool, a compute module on an ISR drone providing basic data filtering, a data layer abstracting raw data for a software platform like the Maven Smart System, a specific fire-support application on tactical command and control (C2) platforms, or any of the medley of algorithms incorporated into the aforementioned systems. 

While one could use DSS to describe any and all of these systems, doing so inhibits the policy community from translating this framework into practical regulatory regimes. Any governance aimed at even certain ‘types’ of DSS would basically attempt to regulate all software involved in ‘decision-making’, another term so broad that it could apply to just about any and all human actions taken in a military context. Attempting to create a new typology of DSS from a policy lens would also fall short in detail and validity compared to existing architectural frameworks used by militaries in accounting for technical composition, function(s) within a given workflow, architectural location and system interactions, and how/if human interaction occurs at different levels. The ubiquity of open-source software further complicates this picture, solidifying the point that software systems of these types cannot be regulated in the same manner as weapons systems. 

Even beyond regulatory efforts, analysis of military digital systems cannot be divorced from their technical and operational context. The focus on ‘DSS’ means that oversight and regulation is overwhelmingly aimed at individual ‘systems’ which are the cause of concern. In reality, any single application, platform, or algorithm is often irrelevant—military doctrine and technological concepts prioritise seamless integration, where layers of systems and data are fused to enable synchronised, convergent actions. Relying on DSS as the framework for understanding, assessing, and governing digitalised military action misses the forest for the trees. It would be neither productive nor feasible to assess one or even several individual systems in the context of a combat incident, as each system’s operation can only be seen and assessed in context of wider architectural structures and the countless systems and subsystems they comprise. Policy analysis and governance will struggle unless they move away from these attempts to isolate individual systems in favour of viewing components within their wider structural context. 

Finally, effective action in the sector of military technology requires engagement with policymakers, operators, and industry representatives, thereby necessitating a degree of commonality in the language used. DSS is not a term used outside of legal and policy communities, as militaries and the private sector have moved to typologies that more closely reflect the operational functions and technical realities of military systems. Military language should not be considered more legitimate by default, but one must at least be literate in the frameworks used by the military and technical experts to succeed in influencing their actions. 

For example, a discussion on ‘targeting DSS’ is too technically and conceptually inexact to permit productive engagement. One could engage with policymakers, commanders, and engineers on technical aspects, say orchestration logics enabling data fusion for situational awareness, or even technological-conceptual challenges, like ensuring commander’s intent when using semi-autonomous algorithms in an uncrewed system, as these examples situate technical systems within the context of their operational functions and conceptual placement within a given battlefield architecture. It is this architectural conception of battlefield systems that offers a framework for grasping context, allows conversations to delve into architectural subcomponents, and provides an opportunity for influencing the responsible use of digitalised military systems.

The Digital Architecture

As described, a key limitation of DSS as a term is that it inhibited analytical and regulatory conversations from progressing naturally. At the ‘system’ level, one could begin to artificially typologise, but there is a dearth of natural pathways for contextualising or adjusting the granularity or abstraction of analysis. The following section provides an alternative framework for understanding, analysing, and regulating military digital capabilities, grounded in an architectural perspective. 

Digital capabilities, including those in the military, are constructed and managed architecturally, where engineers view structures and systems together as one cohesive whole, aligned to the organisation, mission, and resources. Using this techno-conceptual digital structure—the digital architecture—one can see how systems fit together and interact to enable military action while retaining the ability to home in on constituent components and systems. By zooming out, one can then begin to see how operational workflows, decision-logics, system interactions, and data flows operate, and therefore where and how one could begin to ensure responsible military conduct.

Architects design this techno-conceptual framework as the blueprint for their digital capabilities, mapping out the many systems and subsystems, connections, standards, assurance requirements, and human interfaces for a given organisation. Architectures are comprised of largely the same components—hosting, platforms, applications, sensors, middleware, networks, data layers, security, etc.—but differ based on architectural design principles, operational and organisational requirements, and commercial relationships. 

Crucially, architectures are not ‘things’— there is not technical system that one can point to and call an architecture. The architecture of an organisation’s IT comprises their technical documentation, human interfaces and views, data and information models, and governance frameworks mapped onto their technologies. Given the size of militaries and the number of systems in operation, no person or organisation holds the authoritative documentation for a whole architecture, with the structures forming as a result of principles and guidance set out from authorities, which attempt to shape and adapt the technologies owned and operated at every level below. Even though these technologies and their interactions are themselves constantly iterating and changing due to operational needs and outdated systems, the architecture is the common framework tying systems together as well as to their relevant organisation and processes. 

 Moving to Architectural Oversight

While this approach may seem initially daunting in its technical complexity, understanding digital architectures is a prerequisite to effective governance of digitalised military operations. Similar to proposals prioritising lifecycle oversight of DSS, with legal and ethical assurance embedded as a continuous process, oversight mechanisms will need to be extended to monitor, assess, and regulate military digital architectures in a holistic manner.

An architectural oversight approach combines an analysis of technical systems and their interactions alongside their operational context and functions, human interfaces, procedural stages, and organisational/command structures. Using this framework, the policy community can then provide incisive analysis on operational conduct grounded in the military’s socio-technical realities, thereby enabling experts to provide best practices and policy guidance on architectural design, techno-procedural safeguards, and accountability tracing. 

Oversight and governance using an architectural framework does not mean abstracting away the responsibility and accountability of individual humans and systems. This approach grounds one’s analysis in the technical realities of militaries, enabling them to locate and trace the structures and decision trails involved in a given operation. One could determine where civilian protection mechanisms are built in technically, procedurally, and organisationally within a given architecture, identifying where and when failures occur, and how to mitigate them in future. Perhaps paradoxically, by taking the more holistic approach, one can be more targeted in their analysis and governance. 

Architectural Oversight and the Maven Smart System

To highlight the difference in approaches, take the Maven Smart System (MSS)’s use for targeting as an example. It is arguably the most discussed such system, especially after the US/Israeli attacks on Iran. When analysing an incident like the strikes on the Minab school, the reporting has described the failure as stemming largely from human failures to reverify old target profiles with current data. 

DSS-centric analyses can contextualise this finding by describing vulnerabilities within a technical system (data quality, model reliability and bias, algorithmic limitations), at the human-system interface (automation bias, quantification logics), and at the military-procedural level. While these are all crucial points, they fail to answer the question of what system could be regulated to prevent such strikes happening again? The DSS perspective falls short because a failure like Minab sits outside a single system or human-system interaction, but at the intersection and interaction of data processing layers, human processes, old and new datasets, documentation constraints, and governance failures. 

An architectural analysis of the MSS in the context of Minab allows one to start to grasp these structural dynamics with the goal of providing concrete pathways for mitigations and safeguards. 

Technically, the MSS is a data integration platform aggregating raw data from countless sensors and historical datasets. It has a layer (Palantir’s data ontology) for ‘tagging’ each piece of data with attributes, which are then sorted and associated with potentially-related pieces of data. It is these types of data integration layers—not AI—that are the core enablers of the changes in operational speed and scale seen in recent operations. Before any human analyst or machine-learning tool interacts with target data, the engineering decisions of these layers shape how data will be associated into potential targets profiles, what documentation exists on the interactions of systems and data feeds, what tools annotate the dating and relevance of data points, and what human auditing of technical processes is even possible. 

New questions arise beyond the human procedural error, only some of which have revealed answers:

• How much of the determination of combatant status occurs in the data layer prior to analysis and interrogation? How visible are the specific attribute and association tagging to the human analyst or lawyer in a targeting workflow? Does this layer remain opaque besides outputting the objects and their purported links? How auditable are the data aggregation and integration components of the platform for post-incident assessment?
• Given that objects can only be determined as military objects contemporaneously, if the attribute and association tagging comprises a significant portion of the military object determination and occurs well in advance of hostilities, can the full military object determination be considered legitimate?
• How well do identification/association certainties and doubts transfer across systems and processes? Does the system integrator, analyst, or commander bear responsibility for the technical or procedural misalignment of civilian protection datasets into targeting workflows?

From this analysis, oversight and safeguarding mechanisms can be proposed, focusing on developing continuous governance, rather than one-off legislative efforts. Governance should begin with architectural documentation sharing on combat processes, permitting policymakers and legal experts to share best practices in structural design principles for civilian protection. Specific efforts might focus on ensuring proper integration of technical civilian protection tools at appropriate procedural stages and technical layers, with contingency planning on data misalignment. Another step would be accountability tracing exercises at the national or multinational levels, testing how far oversight mechanisms can delve into the granular details of the raw data aggregation, while exposing policy, legal, and non-technical military personnel to the technical realities of warfare. 

From this framework of architectural oversight, governance efforts at the national or international levels can begin to more fully address the range of concerns with such architectures. Yet it is only by first making the complexity of these structures legible can we make progress in this era of digitalised warfare.  

Photo attribution: “Responsible AI in the Military Domain – REAIM 2023” by Ministerie van Buitenlandse Zaken is licensed under CC BY-SA 2.0