How a machine can understand the command intent

1.1. The military intent

Decision-making is a prominent part of Command and Control processes. ² Within the Military Decision-Making Process (MDMP), it is important to have a clear understanding of the commander’s intent. The MDMP process consists of an image-forming phase, a judgment-forming phase, and decision-making phase. ³ The Commander’s intent is one of the required elements of the MDMP. ⁴ The intent is used throughout the MDMP on different back brief occasions with the commander to make sure that there is no miscommunication between the units.

The US Army in Field Manual 3-0, Operations, ⁵ defines Commander’s Intent as “A clear, concise statement of what the force must do and the conditions the force must meet to succeed with respect to the enemy, terrain, and the desired end state.”

The intent is the desired outcome of a military operation. Only when it is well understood, are subordinates empowered to show initiative that is in line with the desired outcome. ⁶ Once these subordinates can act in line with the intent, operations can be turned into great success stories that may not have been as great when predefined orders were followed. ⁷

Intents can be placed into two main categories: explicit and implicit. ⁸ An explicit intent is openly stated to all participants. This intent changes frequently between missions and it cannot be expected that participants can guess or know the intent without telling them. An implicit intent, however, is not publicly stated as the commander assumes that all participants regard this part of the intent as self-evident. A common education, history, and mindset may enlarge the set of intents that do not need to be mentioned. An example of an implicit intent is that taking casualties during a mission should be avoided. Differences in education and culture may cause differences in implicit intents between participants and may lead to undesired mission outcomes. Although the potential for error exists, implicit intents are a necessity for efficient exchange as unnecessary information is left out to place the focus on the intent that is mentioned explicitly.

The commander’s intent is usually divided into the three phases: (1) End state, (2) Key Tasks, and (3) Expanded purpose, ⁹ although divisions in up to eight phases are also known. ¹⁰ During mission planning, these phases support the commander in recognizing the entire situation and clearly communicating their intent to the participants without leaving out important points.

It is not only important to understand the intent of the immediate superior commander but also to act efficiently as a group one needs to know the intent of two levels above. Only then enough context is known so that a complete own intent can be formed, which in turn is transferred to the level below. The MDMP’s main focus is in understanding the commander’s intent and the current situation. Creating an own course of action (COA) and intent are performed toward the end of the process, once the situation is understood.

A common point of confusion lies between the concepts of intent and order. Conceptually speaking, the intent is what the commander tries to achieve, while an order is a command to perform an action, hopefully achieving the intent. However, when receiving an order with all its documentation during the planning process at the Dutch Ministry of Defense (MoD), it includes a description of the commander’s intent. Therefore, the order does include the intent, together with more detailed information.

Understanding the current situation, understanding the intent of higher levels, and formulating the own COA can be challenging, given the limited time available for preparations in complex and multi-domain operations. It is therefore desirable to receive support from technical systems. It should, however, be noted that the commander still needs to fully understand the intent and current situation to handle fittingly in the event of unforeseen circumstances.

1.2. Objectives

In this article, we address the problem of having a computer system analyze the command’s intent, in a manner that is convenient to the military commander, with the long-term goal of supporting the commander during mission planning. The system should back brief the intent to the commander to show its level of understanding. Many decision support applications can benefit from correctly analyzing the commander’s intent.^11,12 In the work by Reus et al., ¹³ e.g., algorithms are tested that learn behavior to achieve a desired result in an operation (COA generation). The desired result is, however, predefined and fixed in a coded goal function.

The research presented in this article is intended to lead a system in which the commander tells the system what the intent is in natural language, on which the system creates the computable goal function automatically. The goal function can then be used to develop a COA and provide support to the commander. In creating such a tool, special attention has to be given to (1) not restricting the commander in formulating their intent because of limitations of the machine; (2) recognizing implicit expectations that are usually not voiced between commanders; (3) understanding domain-specific language; (4) providing the opportunity to the commander to influence how the reward function is created; and (5) creating a reward function that is computable by simulators for optimization and machine learning tasks.

We structure our research into the following three objectives:

While each of these goals is a research area of its own right, we choose to address all three of them to create a working end-to-end prototype. This prototype enables us to experiment with working with the commander’s intent and results in requirements of best practices for future work. The subsequent chapters address each goal separately.

2.1. The written intent from a commander

A commander writes down his (for brevity, we use “he” and “his” when “he or she” and “his or her” are meant) intent in a natural language, e.g., English. The intent contains the objective of an order (“Expanded Purpose”), the method that is to be executed in order to achieve it (“Key Tasks”), and a description of the situation when the objective is achieved (“End State”). Although there are instructions on how to write down a commander’s intent, there is plenty of variation between written intents, both within and between commanders. This includes variations in sentence structure, word choice, and the use of abbreviations. Table 1 shows an example of a commander’s written intent.

OPEN IN VIEWER

Table 1.

A commander’s written intent.

BLUE Commander’s Intent is to secure the area SOUTH_OF_BRIDGE_ALPHA. In the event of incursion of enemy forces, we will counterattack. BLUE SQD1 and SQD2 will not allow their progress into SOUTH_OF_BRIDGE_ALPHA. The end state is achieved when there are no enemies inside SOUTH_OF_BRIDGE_ALPHA at TIME_POINT_2.

2.2. A formalized intent grammar

The formalized intent is described by a context-free grammar (CFG), which is small compared to the grammar describing the English language and not likely to change. This makes it easier for computers to extract the relevant information from the language resulting from it. Because of the structure in a CFG, the location of certain information in an expression (i.e., part of a sentence) is more predictable.

The grammar for the formal intent was taken from ¹⁵ and implemented in Python code. On the highest level, the grammar specifies that the intent is made up of arbitrarily many “Basic Reporting Expressions,” which can be either a “Task Report” (reporting about task operations), “Event Report” (reporting about events) or “Status Report” (reporting about status). In the current implementation, only “Task Report” is implemented and used, as it has the most generic structure. The rule describing the structure of a Task Report is shown in Table 2. * implies that an element may be repeated arbitrarily many times, elements between brackets are optional, and the horizontal bar implies a choice between different elements.

OPEN IN VIEWER

Table 2.

The structure of a task report.

Basic reportingexpression	Structure
Task Report	Verb Executer (Affected | Action) Where When (Why) Certainty Label (Mod)*

Elements are the building blocks of the language that is defined by the grammar. Each of the elements in the Task Report again has its own structure. For a more detailed description of the grammar, the reader is referred to Gustavsson et al. ¹⁵

2.3. Translating the written intent to a formal intent

By formulating a grammar for the formalized intent, essentially a language has been formulated. A translation module translates expressions from one language (English, the commander’s written intent) to another (the formalized intent language). The module uses different (natural language processing (NLP)) techniques:

To translate an expression from the commander’s written intent to an expression that fits the formalized intent grammar, first the root of the written intent expression is determined. The root of a sentence is the part that all other parts in the sentence have a direct or indirect grammatical dependency to (see Figure 1 for an example). Identifying the root of the sentence can be done with a syntactic parser. As syntactic parser, spaCy was used (https://spacy.io/). spaCy contains a Part-Of-Speech tagger and a dependency parser that allow for the labeling of word types (such as noun, verb, etc.) and the dependencies of one word to another. This terminology follows^16,17 for annotating natural language (e.g., PROPN, AUX, PART, VERB, NOUN) and grammatical dependencies (e.g., nsubj, xcomp, aux, dobj).

OPEN IN VIEWER

Figure 1.

The grammatical structure (punctuation and phrases merged together) of the Expanded Purpose of the commander’s written intent from Table 1.

Figure 1 features a so-called dependency tree, which shows the grammatical structure (punctuation and phrases merged together) of the Expanded Purpose of the commander’s written intent from Table 1. The arrows point from parent to child elements. BLUE Commander’s Intent has been identified as a PROPN or proper noun (name) and is the subject of the auxiliary verb (AUX) is. The auxiliary verb is the root of the sentence as it has no incoming arrows.

By applying the spaCy dependency parser to all sentences in the commander’s written intent, the sentence structure is resolved, which is used for determining which phrases are used in the translation to the formalized intent. To optimize the performance of the parser, underscores of the named objects were removed from the text (e.g., “SOUTH_OF_BRIDGE_ALPHA”→“SOUTH OF BRIDGE ALPHA”) and abbreviations were written out (e.g., “OBJ”→“objective”) before the text was parsed. For the abbreviations, a dictionary with common military abbreviations was used. The original sentence was kept to reuse the original content in the formalized intent.

The next step in the sentence analysis is to retrieve the “Verb Frame” for the sentence. This Verb Frame makes the expected elements in the translated sentence explicit. A list of verb frames (without the wildcard “Mod”) was provided. ¹⁸ The frames dictate the required elements to be present in the formalized intent. When no verb frame can be retrieved for the main verb in the sentence, the elements required by the grammar (see Table 2) guide which elements are sought in the written intent, but none are “required.” For the verb “secure,” the frame is shown in Table 3.

OPEN IN VIEWER

Table 3.

Verb frame for “secure.”

Verb frame	Structure
Secure	Tasker Taskee (Facility | Feature) At-Where Start-When (End-When) Why Label

Table 3 makes explicit that when the verb “secure” is encountered, these elements are expected: a Tasker (e.g., “BLUE”), Taskee (e.g., “squadron 1”), a Facility or Feature (e.g., “the bridge”), an At-Where (e.g., “Area 51”), a Start-When, and optionally an End-When (e.g., “at 09:00 h”), a Why (e.g., “to win this fight”), and a Label (e.g., “A1”).

For each of the frame elements, lookup rules are formulated to translate a relevant part of the commander’s written intent to a phrase fitting the formalized intent grammar. These rules use the sentence structure as determined by the spaCy dependency parser and regular expressions. The lookup rules mostly work with a “clean” version of the commander’s written intent (without underscores and no abbreviations) to optimize processing the expressions. The formulation of the lookup rules was based on the examples of written and formalized intents and evaluated by MoD personnel: the end users.

For this research, we chose the usage of lookup rules over Named Entity Recognition (NER) and relation extraction techniques. Such techniques, trained on large general language datasets, may perform poorly in domains that evolve their own specialized language. To make NER and relation extraction feasible, a large annotated dataset must be available that allows the training of specific models for, in this case, the military domain. As currently no such dataset exists, we have chosen for the usage of lookup rules.

We first describe the lookup rule that searches for the “Taskee” and provide an example that shows the underlying mechanism in the next paragraph. The “Tasker” and “Taskee” together are normally the subject of the (root) verb in the expression. The “Tasker” of the verb is determined as the element that has an “nsubj” relationship (nominal subject) to the root verb, and all its direct and indirect children, minus the part that is identified as the Taskee. The “Taskee” of an expression is determined as the part of the “nsubj” of the root verb that represents a unit, e.g., a squadron. Whether a unit is present in this part is determined with the help of a regular expression, which looks for character sequences patterns (e.g., “pel,”“cie,”“sqn”).

Figure 2 shows the element and all its (direct and indirect) children with an nsubj relationship to the root verb of the sentence that is shown in Figure 1 (i.e., the subject, a combination of the Tasker and Taskee). The goal of the lookup rule is to identify the Taskee. As no sequence of characters that matches a unit could be found with the regular expression, no Taskee could be identified in this expression. The algorithm concludes that the entire subject is the Tasker (it is possible to first look for the Tasker instead of the Taskee, correctly finding “Blue commander” as Tasker, but still not finding the Taskee).

OPEN IN VIEWER

Figure 2.

A more detailed view of the PROPN element in the parsed Expanded Purpose expression from Figure 1, which has an “nsubj” relationship to the root verb “is.”

Another example of a lookup rule is the logic that is implemented to determine the element “Where.” According to the grammar, the Element “Where” can be either a location (“At-Where”) or a route (“Route-Where”). The lookup rule for “At-Where” assumes that a word indicating a location is preceded by a preposition, specifically one that indicates a static position at a location (e.g., “inside,”“at,”“(south) of”). If a match is found, the location is returned including the preposition. When the preposition is the child or sibling of a word indicating a cardinal direction (north/east/south/west), the cardinal direction is returned as well.

Figure 3 shows the element with a pobj (prepositional object) relationship to a preposition (ADP—adposition, such as IN, TO, DURING; in this case “OF”): “ALPHA.”“ALPHA” has a compound relationship with “BRIDGE,” so together they are the prepositional object of “OF.” Because “OF” is the sibling of cardinal direction “SOUTH,” the algorithm concludes that the location is “SOUTH OF BRIDGE ALPHA” (SOUTH_OF_ BRIDGE_ALPHA, actually, as the underscores are replaced after the sentences have been parsed).

OPEN IN VIEWER

Figure 3.

A more detailed view of the NOUN element in the parsed Expanded Purpose expression from Figure 1. Notice that the underscores have been removed to improve the parsing.

When the translation module is applied to Table 1, it results in the formalized intent shown in Table 4. The formalized intent shows, per sentence, the six elements “When,”“Executer,”“Action,”“Affected,”“Where,” and “Why,” and the corresponding sentence part for each of these elements. Required elements of which the value could not be extracted are filled with a default placeholder (e.g., < T:0 > for When, < WHY> for Why.) Elements that were not “required” (based on a verb frame) were left empty (i.e., “None”). The placeholder serves as a warning for the commander that his written intent could not be parsed correctly. The shown categories correspond to the elements that the formalized grammar dictates for the Task Report (Table 2), where “Action” is “Verb,” and “Executer” is the combination of “Tasker” and “Taskee,” as described earlier in this paragraph. Depending on the underlying Verb Frame, “Affected” takes on the value of either the “Object,”“Affected,” or “Feature” of a verb. “Mod” and “Label” were not implemented.

OPEN IN VIEWER

Table 4.

The formalized intent resulting from the application of the translation module in Table 1.

EXPANDED PURPOSE: ’when’: ’< T:0 >’ ’executer’: ’BLUE Commander’s Intent < TASKEE >’ ’action’: ’is to secure SOUTH’ ’affected’: ’the area’ ’where’: ’SOUTH_OF_BRIDGE_ALPHA’ ’why’: ’< WHY >’ KEY TASKS: ’when’: ’None’ ’executer’: ’we’ ’action’: ’In counterattack’ ’affected’: ’the event of incursion of enemy forces’ ’where’: ’None’ ’why’: ’None’ ’when’: ’< T:0 >’ ’executer’: ‘and BLUE SQD1 and SQD2’ ’action’: ’not allow’ ’affected’: ’their progress’ ’where’: ’SOUTH_OF_BRIDGE_ALPHA’ ’why’: ’< WHY >’ END STATE: ’when’: ‘None’ ’executer’: ’None’ ’action’: ’achieved’ ’affected’: ’None’ ’where’: ’inside SOUTH_OF_BRIDGE_ALPHA’ ’why’: ’None’

Both a qualitative and quantitative evaluation were performed to test the presented approach. Together, they were used as a proxy to evaluate the quality of the translation module and the applicability of this approach as a whole.

2.4. Qualitative evaluation

Two platoon commanders evaluated the translation of the commander’s written intent to the formalized intent. Their evaluation reflects a commander’s acceptance of the generated formalized intent.

The approach is particularly able to translate sentences which are built around a verb, even more if this concerns a verb of which the frame can be determined. The subject of this verb should be the Executer of the verb (i.e., Tasker + Taskee), and the object of this verb should be the target (this can be multiple element types). Either at the beginning or end of the sentence, a phrase starting with “in order to” should be used to indicate Why. And ideally, location names are preceded by a location-indicating preposition (e.g., “into”).

The platoon commanders noted one shortcoming in the current prototype. Relative time references cannot be interpreted. For example, “subsequently” may indicate that “after the last-mentioned action, this new action happens.” In the prototype, no logic has been implemented to explicitly relate such events. We regard it possible to add such functionality by extending the system with a memory of earlier sentences. Currently, the translator is applied per sentence.

As the translation module is at its core, a rule-based system extending the module to new intent variations is possible, but may require some manual fine-tuning.

2.5. Quantitative evaluation

As formalizing a commander’s written intent is pioneers work, there currently exists no standard method to evaluate the used approach. We therefore introduce an evaluation method named IntentEval which was inspired by the SemEval approach for the evaluation of NER algorithms. ¹⁹ IntentEval includes three measures that each address a specific aspect. When all three measures are regarded together, the observer gains insight on how well the approach works in general and what aspects can be improved.

We call the first measure Formalization Recall. It assigns a metric based on whether or not certain information has been found, and if so, if it has been labeled correctly. A term may be correctly identified as important, but it may be mislabeled into an incorrect element. Even in that case, the tested formalization method should not be penalized too harshly. To achieve this, the measure translates the generated formalized intent to a string representation and compares the generated string to the expected string. The two texts were compared using the Python package “difflib,” which applies “gestalt pattern matching” to text sequences. According to their documentation (https://docs.python.org/3/library/difflib.html), “[t]he idea is to find the longest contiguous matching subsequence. […] Th[is] idea is then applied recursively to the pieces of the sequences to the left and to the right of the matching subsequence.” Using this string-matching approach, even text that is placed in wrong categories can increase the score. Drawbacks are that this measure can be sensitive on how the string is generated (i.e., the ordering of the elements) and that longer phrases have more influence on the score as characters are counted (e.g., squadron versus sqn). One may regard this measure similar to the recall.

We call the second measure Entropy Handling. It determines whether all expected elements are present and contain content in the generated formalized intent. Whether the content is correct is not relevant, just that it is filled with a value. This measure detects that the formalization method is indeed subdividing the original intent into the expected elements. Optional weights can be added to make some elements more important than others. When the original intent does not contain information for a category, this is not counted in the scoring. This measure therefore requires a labeling of which categories are present in the written intent. It can be computed by the (weighted) ratio of the correctly present and correctly absent elements in the formalized intent.

We call the third measure Formalization Precision. It concerns the aspect that the correct information is placed in an element. Each generated element is individually inspected and compared to the expected content of the element. Similar to the first measure, “gestalt pattern matching” was used to determine a score per element. These scores are then averaged for all the elements. Optional weights can be added to make some elements more important than others. This measure is only applied for elements in which the formalization method generated an output. For example, a score of 1 is obtained when only one element is filled, and it is correct. This measure also requires a labeled dataset. In short, this score can be computed by the (weighted) ratio of the gestalt pattern matching scores for all present elements in the formalized intent.

A relevant point to discuss is the labeling strategy, which has a large impact on the scores for Entropy Handling and Formalization Precision. To indicate the importance of this strategy, we want to point out two issues with the intent of Table 5. The first issue is in the expanded purpose. When securing an area, is that area the affected object, as it is being secured, or is it the location where an activity takes place? The second issue is in the key tasks. Is “we” an appropriate executor as it does not explicitly name who is executing an action. Should it be replaced with BLUE, or left empty? Or should be inferred which unit indication “we” represents? The labeling strategy as shown in Table 5 was chosen for this study, but a more in-depth study of many intents is required to formulate a universally accepted labeling strategy.

OPEN IN VIEWER

Table 5.

The expected formalized intent belonging to Table 1.

EXPANDED PURPOSE: ’when’: ” ’executer’: ’BLUE Commander’ ’action’: ’ secure’ ’affected’: ’the area SOUTH_OF_BRIDGE_ALPHA’ ’where’: ’the area SOUTH_OF_BRIDGE_ALPHA’ ’why’: ” KEY TASKS: ’when’: ’In the event of incursion of enemy forces’ ’executer’: ’we’ ’action’: ’In counterattack’ ’affected’: ” ’where’: ” ’why’: ” ’when’: ’< T:0 >’ ’executer’: ‘BLUE SQD1 and SQD2’ ’action’: ’not allow’ ’affected’: ’their progress into SOUTH_OF_BRIDGE_ALPHA’ ’where’: ’into SOUTH_OF_BRIDGE_ALPHA’ ’why’: ” END STATE: ’when’: ’at TIME_POINT_2’ ’executer’: ’we’ ’action’: ’achieve’ ’affected’: ’no enemies’ ’where’: ’inside SOUTH_OF_BRIDGE_ALPHA’ ’why’: ”

We now provide an example of how these measures work. For Table 1, the expected formalized intent is shown in Table 5. Both the text representation of the formalization of Table 1 and the expected text representation of Table 6 are needed for the Formalization Recall. The results of the IntentEval method are shown in Table 7.

OPEN IN VIEWER

Table 6.

(Left) The text representation of the formalized intent shown in Table 4. (Right) The expected text representation.

EXPANDED PURPOSE: ‘BLUE Commander’s Intent is to secure SOUTH thearea SOUTH_OF_BRIDGE_ALPHA’	EXPANDED PURPOSE: ‘Blue Commander secure the area SOUTH_OF_BRIDGE_ALPHA’
KEY TASKS: ‘we In counterattack the event of incursion of enemy forces	KEY TASKS: ‘In the event of incursion of enemy forces we counterattack’
and BLUE SQD1 and SQD2 ‘not allow’’theirprogress’‘SOUTH_OF_BRIDGE_ALPHA’	‘BLUE SQD1 and SQD2 will not allow their progress into SOUTH_OF_BRIDGE_ALPHA’
END STATE: ‘achieved inside SOUTH_OF_BRIDGE_ALPHA’	END STATE: ‘at TIME_POINT_2 we achieve no enemies inside SOUTH_OF_BRIDGE_ALPHA’

OPEN IN VIEWER

Table 7.

IntentEval measure for the formalization of Table 1.

IntentEval measure	Expanded Purpose	Key Tasks	End State	Mean
Formalization Recall	0.790	0.824	0.699	0.771
Entropy Handling	1.000	0.857	0.400	0.752
Formalization Precision	0.747	0.832	0.560	0.713

We see that the Formalization Recall scores highest of all three measures (0.771). This reflects a high “recall” of the extracted information. Given that the other measures are lower, this could mean that the right information was extracted, but ascribed to the wrong category. Still fairly accurate is the score for Entropy Handling (0.752). This means that about 75% of all expected elements was given any value at all. Finally, the score for Formalization Precision is not only lowest but also still fairly accurate (0.713). This reflects that on average, the returned value for each of the required elements could be matched with a ratio of 0.713. Furthermore, the same measure can differ greatly between the parts (Expanded Purpose, Key Tasks, and End State): All measures score lowest on the end state. This can be explained by the formulation of the End State. Often, the end state is formulated with passive sentences, which were observed to be more difficult for the syntactic parser to parse correctly. This in turn influences the applicability of the lookup rules, and hence the performance.

The qualitative evaluation was performed on a total of four different written intents, provided by the Dutch MoD. The results are shown in Table 8. We see that on average, the Entropy Handling scores highest of all three measures (0.705). This reflects that most expected elements are present. Formalization Recall and Formalization Precision both score lower on average (0.558 and 0.578, respectively).

OPEN IN VIEWER

Table 8.

Qualitative evaluation results for four different intents.

IntentEval measure	Intent	Expanded Purpose	Key Tasks	EndState	Mean
FormalizationRecall	1	0.790	0.824	0.699	0.771
	2	0.457	0.197	0.391	0.348
	3	0.503	0.359	0.514	0.459
	4	0.948	0.468	0.575	0.663
	Mean	0.675	0.462	0.537	0.558
EntropyHandling	1	1.000	0.857	0.400	0.752
	2	0.750	0.667	0.556	0.657
	3	0.636	0.571	0.667	0.625
	4	0.900	0.786	0.667	0.784
	Mean	0.822	0.720	0.573	0.705
FormalizationPrecision	1	0.747	0.832	0.560	0.713
	2	0.529	0.452	0.490	0.490
	3	0.224	0.386	0.585	0.398
	4	0.784	0.571	0.507	0.621
	Mean	0.571	0.560	0.604	0.578

The bold values represent the current overall scores for Formalization Recall, Entropy Handling and Formalization Precision.

2.6. Discussion

We showed that a computer system can understand parts of a commander’s intent that has been communicated using written natural language. A translation module was developed that translates a commander’s written intent to a formalized intent. The approach was qualitatively evaluated with two platoon commanders who were impressed by the current capabilities. Not only are many information elements successfully found in the commander’s intent but the system is also able to indicate the missing elements, which might mean that they were not present in the commander’s written intent. This is made possible because of the use of a grammar and verb frames that dictate the structure of the formalized intent and may save a commander’s loss of face with their fellow officers. However, even with the promising first results, several points of improvement can be made.

We showed that this approach is a solid basis for understanding the commander’s intent. The question however remains open whether the approach will be able to comprehend all the possible variations in which commanders communicate their intent. An example of this is already present in the current version of the translation engine. The Tasker from the Expanded Purpose in Table 1 was extracted as “BLUE commander’s intent” (see Table 4) but should intuitively have been “BLUE commander.” The failure can be assigned to the lookup rule for the Tasker in the Expanded Purpose. The rule states that the Tasker is the subject of the root verb, but in this example sentence, this rule does not hold. We believe that the chosen approach with its composable verb frames and lookup rules will be able to handle the many of intent variants, but a more comprehensive study is required to more closely determine the coverage that the approach can generate.

The grammar that describes the structure of the formalized intent is language-agnostic. However, the translation module is not. We chose to develop the translation module for the English language because the quality of available NLP methods for Dutch, and in particular the syntactic parser, is much lower than the quality of their English counterparts. (Generally speaking, NLP methods work better for widely spoken languages as there is more annotated training data available and motivation to create well-performing models.) The MoD personnel indicated that they would prefer to write intents in their own language (Dutch). It is possible to adapt the translation module to Dutch, but it requires manual fine-tuning due to its rule-based implementation.

The rule-based implementation of the translation module also makes it likely that the current implementation of the module will need to be maintained regularly. Changes to the writing style of commanders’ intents will likely introduce new sentence structures and abbreviations, which could cause the translation module to fail.

Many NLP techniques rely on large (annotated) datasets. If such a dataset of many commander’s intents would become available, then a machine learning model using NER and Relation Extraction could be taught to predict the formalized intent, based on the written intent. Such a model may exceed the accuracy that the current rule-based approach achieves. In the future, such datasets may be created during exercises, especially when data collection, cleaning, and annotation become deeply rooted in the way of working.

In the current version of the formalized intent, elements (such as “Why” and “Taskee”) that could not be extracted from the commander’s written intent are indicated as missing. This is possible due to the use of a grammar and verb frames that dictate the structure of the formalized intent. Indicating which elements could not be extracted from the written intent (e.g., because they were not written down) will save a commander’s loss of face with their non-commissioned officers.

3.1. Clarifying information completeness

The first step for addressing information completeness is to validate whether the terminology used by the commander is known to the system. Each operation contains an ORder of BATtle (ORBAT), and any unit indication found in the intent and in the ORBAT can be cross-referenced. We furthermore cross-reference named areas of interest, such as BRIDGE ALPHA, as these are known within the command-and-control system. Relevant time points are also cross-referenced (in the proof-of-concept, we substituted the connection with the C2 system with a lookup in a local glossary). Finally, all verbs are cross-referenced with “military action” verbs. ²⁰

Any known term is directly highlighted to indicate that is has been understood (e.g., units, areas of interest). This provides a visual que to the commander of known terminology, e.g., when a unit reference is unknown in the order of battle. On a mismatch, the commander either changes the description or investigates the relevant source data for errors.

An example of the terminology validation is shown in Figure 4. Unit indications are highlighted in dark blue, named areas of interest are in light blue, named time indications are red, military actions are brown, and the general indications for Blue and Red are made purple. (Colors are currently randomly assigned for each category. In the future, colors should be chosen that are intuitive for commanders.)

OPEN IN VIEWER

Figure 4.

Validating terminology with the commander. Any highlighted text has been cross-referenced.

The second step for addressing information completeness is to validate that the sentence structure has been understood and that information is not missing in its entirety. The written commander’s intent is formalized by the techniques described earlier and the result of this briefed back to the commander as shown in Figure 5.

OPEN IN VIEWER

Figure 5.

Brief back to the commander on information completeness.

Each sentence is broken up into the categories When, Executer, Action, Affected, Where, and Why. ¹⁰ Now it becomes straightforward for the commander to validate whether all information has been placed in the correct category. Missing information is indicated by the system with “<>” and shows the commander that the written intent may be improved by adding this information.

3.2. Clarifying contextual information correctness

The intent of the commander mentions many units, locations, actions, and time indications. It is only human that sometimes a mistake is made. For example, was it squadron 1 or 2? When both units are defined in the ORBAT, the brief back as presented in Figure 5 cannot detect this human error.

There is no external source to check the contextual correctness, and we therefore use the commander to validate the intent. We do this by presenting the provided intent visually on a map. Military commanders are used to this presentation as they generally create these themselves as supplement in the order. ³ Such a visualization is called a map overlay, ²¹ and it displays the relevant units, areas, and actions phase lines among others at the relevant locations. A military commander can follow the “storyline” of an operation by looking at the map overlay. We therefore believe that it is highly valuable to be able to generate the map overlay automatically based on the commander’s intent, as this not only can serve as a check for correctness but also for including these in the order. When generating this automatically, manual labor is reduced and the MDMP process is accelerated.

The developed prototype is able to display military units and actions based on the NATO standard MIL-STD-2525 ²² and locations by either indicating the exact point (in case that it is a point target), or as a circle (in case that an area is concerned). Figure 6 shows an example of the map overlay visualization. In this example, two units apply a counterattack on a target area. The area is indicated by a red circle, with a cross in its center.

OPEN IN VIEWER

Figure 6.

Map overlay visualization of the commander’s intent on a map.

In the future, the prototype may be extended by adding more concepts, such as phase lines. Also area indications may be made detailed using polygons. We furthermore envision a time-based visualization, that can simulate the operation on a high abstraction level, to help the commander to gain insight into timing aspects.

3.3. Discussion

This section showed that a system can validate the commander’s intent in the form of a back brief from system to commander. Currently, it can take up to 80 h of planning to define an order. The main value of the system is to assist in this procedure and increase the quality or speed. To test whether the proof-of-concept is efficient in performing a back brief of an intent with the commander, two platoon commanders tested the system. These commanders entered several intents and inspected the back brief.

The commanders indicated that such a tool can be helpful during the planning of large operations. They are positively surprised by how well the system is able to pinpoint what information in the written intent is missing, or written in such a manner that it may be misinterpreted or not understood (Figure 5). Even an intent that was not used during the development of the prototype was understood well. The system enables the commander to first check the written intent before communicating it to the lower commanders during the briefing. This might avoid confusion during the briefing and loss of face when making mistakes. The visualization on the map may also help to prevent mistakes (Figure 6).

The translating of the intent to a geo-visualization (Figure 6) in particular is regarded as valuable as such overviews now have to be drawn manually. As the system is able to draw these automatically by retrieving relevant information from underlying systems, the planning process can be accelerated.

The system may also be used during the training of commanders for company level four and higher to gain experience in clear intent formulation.

4.1. Requirements of the executable goal function

The first challenge we want to discuss is that it is hard for humans to translate any intent to a definable function. For example, the commander may indicate that the enemy should not be allowed in the area south of bridge ALPHA. For the commander’s subordinates, this information may be clear as they share the same mental reference framework as the commander. However, for a computable definition, we need to remove this reference framework entirely. Does this area span all the way to the south pole? Does it circle the earth for all longitude positions? If the river is not perfectly straight, does it include the area on the other side of the river that is geographically speaking south of bridge alpha? Does it include airspace? If not defined properly, the AI may find plans that perform well in terms of goal function, but bad in terms of what the commander wants to achieve. In a hide and seek game, e.g., the AI may find a solution to simply keep running away infinitely so to never be found. ¹⁴ Therefore, a requirement is that the function clearly defines areas, timespans, unit indications, and all other aspects, so that no interpretation freedom remains. A suitable user interface may help the commander to perform this step.

The second challenge is to become aware of implicit intents. ⁸ For a military commander, the intent not to suffer casualties may be so obvious that it is not included in the goal function. When it is not included, it gives the AI the freedom to test various kamikaze COAs and may prefer this type of COAs if they even marginally increase the measure of effectiveness. Therefore, a requirement is that these implicit intents are made explicit and added to the goal function as well. When experimenting with the system, we believe that many of the implicit intents in military decision-making are standard between missions and can be reused (e.g., less casualties is better). The implicit intents that are mission-specific are also a challenge in human-to-human communication. To find these, we believe that an iterative approach works best. An AI may learn a well-performing COA that violates an implicit intent, after which the commander adds this intent to the goal function for the next iteration.

Another challenge is that the AI may come across bugs or unintended effects in the simulator that by coincident benefits the goal function. A famous example is the agents playing hide and seek, and the hider found a specific sequence of steps which launches them upward, out of the play area. ¹⁴ A complex simulator of military simulations will unavoidably contain several of these exploits. It is a continuous effort to remove such exploits so that an AI learns desired behavior. This may be seen as a requirement to the simulator rather than a requirement to the goal function itself.

A practical requirement for the executable intent is that it can be applied to the representation of the mission in the chosen simulator. Each simulator choses its own granularity of each mission aspect. ¹³ For example, the terrain database being used or the unit abstraction level. ²⁷ A simulator agnostic goal function enables the exchange of simulators as long as for each simulator a custom translation is created on how this generic goal function is applied in the specific simulation environment. This requires that the goal function uses generally accepted concepts, such as the longitude and latitude or standardized time indications.

4.2. An exchangeable goal function format

In this section, we propose a format that enables us to exchange a goal function with other systems, which specifically addresses the last requirement of the previous section. The format was partially inspired by, ²⁸ and is similar to the optional TaskersIntent of a Coalition Battle Management Language (C-BML) order. ²⁹ The main difference is that our format has to be so precise that the function becomes computable.

We regard the goal function as a weighted sum of components. Each component has a class. In our prototype, we have implemented three classes: Unit health, units eliminated, and territory reached. One or more of the classes are assigned to each Verb frame of the formalized intent (see Table 3). More classes may be added later to reflect more diverse goals of the commander. Each of these classes may be negated and has a unit indication. This makes the following example goals possible: the opponent should be eliminated, Blue should lose as little causalities as possible, Unit A should be at a certain location, and the opponent should not be at a certain location. It is possible to indicate what territory is concerned for the territory reached class. To each of these components, timing information is added to indicate that a goal should be achieved before or after some timestamp, or that it is better to achieve it earlier than later. As currently timing information is hard to extract from the text (see Table 4), the components fall back to default values. An example of such a weighted goal function is shown in Table 9.

OPEN IN VIEWER

Table 9.

An example goal function in json format.

[ { "intentClass": "unit eliminated", "weight": 1, "unitIndication": "Red", "negation": "False", "timeIndication": { "intentClass": "linear time interval", "center": "0", "delta": "600" } }, { "intentClass": "unit health", "weight": 2, "unitIndication": "Blue", "negation": "False", "timeIndication": { "intentClass": "always on time" } }, { "intentClass": "territory reached", "weight": 1, "territoryIndication": { "intentClass": "box territory", "x": "0", "y": "27", "lat": "55.73230150664191", "lon": "24.363706624472886", "width": "500", "heigth": "230" }, "unitIndication": "Red", "negation": "True", "timeIndication": { "intentClass": "simple time interval", "min": "0", "max": "600" } }]

In the goal function of Table 9, it is twice as important to not sustain losses than to eliminate the opponent (please note the weights). It is also better to eliminate the opponent early on during the mission, rather than later (please note the timing indication of the first component), while remaining the health is always good (the timing indication of the second component). The third component describes that the opponent should not enter a square-shaped territory, and in case that the opponent enters the territory, then later is better than earlier.

A goal function that is defined by the commander may consist of many components that need careful weighing and parameters to accurately reflect the goal to be achieved. Therefore, we present the goal function to the commander so that final adjustments can be made. In Figure 7, we show how this step is presented to the commander in the developed prototype.

OPEN IN VIEWER

Figure 7.

Setting the weights of the goal function.

The commanders can read a text explanation of the intent item, and in the brackets, it is shown whether this item originates from the formalized intent as automatically extracted from the provided intent, in which case it is an explicit item, or whether it has been added automatically as an implicit intent item. Each item has a weight indicator that allows the commander to weigh the different goals relatively to each other.

We envision that in future versions, much more parameters will be configurable when selecting such an intent item. Each parameter that is shown in Table 7 should be changeable according to the commanders wishes. It requires further research to create a well-working user interface that is (1) easy to learn, (2) provides the needed degrees of freedom, and (3) can be used in high-stress situations, such as during mission planning.

4.3. Finding a course of action based on the goal function

Once the commander is done with the fine-tuning as shown in Figure 7, the optimization system now can search for a COA that results in a situation that maximizes the score of the goal function. This is done by simulating the behavior of units. We envision that the communication between the optimization software and the simulator is done by C-BML, ³⁰ in which one or several of the 5W’s is varied (Who, Why, When, Where, and What). ³¹ Other standards are also possible based on the choice of optimization and simulator.

As an optimization algorithm, we choose a genetic algorithm that learns the most effective locations of an infantry and sniper unit in an urban environment. We only chose to optimize the locations, but many other COA aspects may be varied as well, so that new and surprising COAs can be found. The coordinates that are currently being tested are transmitted to the simulator using C-BML. As a simulator, we chose to use a simple simulator that was specifically made for this research. Although less realistic simulations are performed by this simulator, it was less effort to create compared to using a high-fidelity military simulator, such as VR-forces ²⁷ or the Dutch CST ³² that require realistic input (such as a terrain database) and realistic settings and unit behavior scripts. Although the learned behavior may be less accurate, we believe that the current setup shows that the designed goal function is usable by a simulator-based machine learning approach.

In the scenario presented here, Blue has an infantry and a sniper unit and needs to decide where to place them on the map so that losses are minimized. The opponent should not be allowed into the area south of the bridge. We chose a genetic algorithm to learn suitable positions for battle engagement. This algorithm searches for well-performing combinations of locations for both units.

We choose a heatmap for plotting the results. A heatmap is not suitable to simultaneously show a four-dimensional solution space (two dimensions for the infantry unit, and another two for the sniper unit). We therefore chose to fix one unit on the position that was chosen by the genetic algorithm. The position of the other unit is varied. Figure 8 shows four example heatmaps in which the position of the infantry unit was varied and the position of the sniper unit was fixed.

OPEN IN VIEWER

Figure 8.

Heatmaps of well-performing unit positions. Top-left: Intent to only preserve own forces. Top-right: Intent to only damage enemy forces. Bottom-left: The intent as presented in Table 7. Bottom-right: A balanced intent of not losing casualities, inflicting casualties, and not allowing Red into the area south of the bridge.

We here provide some rationale behind the coloring of the heatmaps. Green areas are more favorable unit positions to achieve the commanders’ intent compared to red areas. Top-left: As the only goal is to survive and not sustain any losses, it is best to avoid the enemy as much as possible. In this case, it is best not to cross the bridge and stick to the sides of the allowed area. Top-right: The only goal is to inflict as much damage as possible and eliminate opponent units. As the enemy spawns on various location on the north of the map, it is best to engage quickly to isolate enemy units. Once the enemy arrives at the bridge, the enemy units are close to one another and engaging them results in quick losses without inflicting much damage. Bottom-left: This map is similar to top-right, as damaging the opponent is the most relevant factor of this intent. It however prefers the areas west and east of the main road. This is because then some opponents can be engaged without too many losses. Bottom-right: In this balanced intent, the preference is to engage the opponent as much north as possible. This is at first sight not intuitive as the objective is to not allow the opponent into the area south of the bridge. A military expert would create an engagement area south of the bridge to take advantage of the small passage corridor (the bridge). In our simulation, however, this lowers the score as the opponent enters the chosen area (although being eliminated shortly after). The reason why the optimization chooses to engage earlier is that the score of the territory function is determined at the first instant when the opponent enters the area in the current implementation. Therefore, to maximize the goal function, the opponent should be engaged in a manner so that no enemy sets foot in the chosen area at all. This shows the importance of a well-defined goal function for obtaining meaningful results.