Deep Green (DG)

Program Manager: Dr. Todd Hughes (AEO)

Approach:

Effective battlespace representations for Deep Green must enable practical and tractable reasoning by software agents. In particular, the generation of a state-space representation from current operational data is particularly challenging. Deep Green must be able to use data and information fusion to dynamically create and update representations of the current battle space. Deep Green will then use these representations to predict the "trajectory" of the operation and inform the commander of impending decision points, parts of the plan that need additional options generated, and parts of the plan that are no longer feasible.

Deep Green will involve the use of software agents to analyze the current operation against the plan and to look far ahead in time for the commander to create possible courses of action. These "execution monitors" must be capable of reasoning over the state space to evaluate the actions of the various participants, evaluate the utility and likelihood of actions, and prune the state space representation where possible. Most of this kind of agent technology has proven effective in constrained problem spaces, but must be hardened and scaled to support a real battlespace.

Finally learning algorithms must be developed and enhanced to allow Deep Green to become a better predictor over time. Technologies such as linguistic geometry and episodic memory must be employed to create robust learning algorithms suited for battlefield use. Many of these technologies must be extended to encompass the intractable nature of the modern battlefield as they have been demonstrated in more "well behaved" domains. The domain for Deep Blue, the game of chess, for instance, is well known, the interactions are unambiguously defined, the consequences of any single action are deterministic, etc.

The basic system architecture is comprised of the Commander's Associate (with three sub-components, the Sketch to Plan, Automated Options Generation, and the Sketch to Decide), SimPath, and Crystal Ball, as shown in the figure below.

Sketch to Plan: The Commander's Associate has two major sub-components, Sketch to Plan and Sketch to Decide. Commander's Associate will automatically convert the commander's hand-drawn sketch with accompanying speech of his intent into a Course of Action (COA) at the brigade level. The Commander's Associate must facilitate option generation, "what-if" drills, and rapid decision making. In addition, the Commander's Associate will present information to the commander in a way that aids in battlefield visualization and cognition.

Commander's Associate: This component provides the commander the ability to generate quickly qualitative, coarse-grained COA sketches that the computer can interpret. Sketch to Plan will be multi-modal (both sketching and speech) and interactive. The computer will watch the sketch being drawn and listen for key words that indicate sequence, time, intent, etc. as the commander is creating the sketch. Sketch to Plan will induce both a plan and the commander's intent from the sketch and speech. The Sketch to Plan component must be imbued with enough domain knowledge that it knows what it doesn't know and can ask the user a small set of clarifying questions until it understands the sketch and can use it to initialize a combat model. Finally, the dialog generator helps Sketch to Plan understand the commander's option by formulating clarifying questions when necessary.

Automated Option Generation: The focus of Deep Green is on tools to help the commander (and staff) generate options quickly. Leaders from the field generally do not want machine-generated courses of action. Nevertheless, under Deep Green, we intend to sponsor a small set of modest efforts to generate options automatically. The long-term vision of Deep Green is for options to be generated by both the commander and the computer. This highlights the need for Sketch to Plan to induce the commander's intent from the free-hand sketches. Any options generated by the computer should feasibly meet the commander's intent.

Sketch to Decide: When the commander is asked for a decision, Sketch to Decide will allow him/her to explore the future space to gain an appreciation for the ramifications of a choice. Sketch to Decide is designed to allow the user to "see the future," but this capability must be developed with care to prevent confusing the decision space. The abstract nature of the state and the uncertainty of predictions, locations of units, etc. must be portrayed intuitively. At any "frame" in the Sketch to Decide graph, the user can perform Sketch to Plan actions, allowing the commander to conduct "what-if" drills wherever he wants in the future space. By presenting decisions early and allowing the commander to explore the future space, Sketch to Decide supports adaptive execution, allowing the commander to make decisions when they are needed, rather than committing too early.

SimPath: SimPath is the simulation component of Deep Green. It is used to generate the possible futures that result from a set of plans (one plan for each side/force in the operation). Besides being very fast, SimPath is designed to generate a broad set of possible futures. These futures should be feasible, even if not expected by human users. Over time, SimPath should learn to be a better predictor of possible futures, based on presented options. SimPath identifies branch points, predicts the range of possible outcomes, predicts the likelihood of each outcome, and then continues to simulate along each path/trajectory. This will require an innovative hybrid of qualitative and quantitative technologies.

Crystal Ball: During pre-operations planning, Crystal Ball receives options from Sketch to Plan for all sides and forces. Crystal ball assembles the permutations of plans and sends them to SimPath to generate the possible futures that result from each permutation. SimPath returns sub-graphs of possible futures and branch points to Crystal Ball with annotations as to SimPath's a priori estimate of the likelihood of these options. Another function of Crystal Ball is to merge these sub-graphs so the futures that are qualitatively the same (regardless of which permutation of options generated them) are combined. Once the operation is underway, Crystal Ball will get information about the ongoing operation from the battle command systems. Crystal Ball uses this information about the current operation to update the likelihood estimates of the many possible futures. Having done that, Crystal Ball can compare the likelihood, utility, and flexibility and estimate which futures are likely to occur that have little value or flexibility. Crystal Ball will use this estimate to nominate to the commander futures at which he/she should focus some planning effort to build additional options/branches. If the commander reaches a future for which no options have been developed, he/she has been surprised and the enemy is now operating inside his/her decision cycle. Crystal Ball will also use this information and additional heuristics to nominate futures for pruning from the graph and to identify decision points to send to Sketch to Decide. Pruning, however, will not be based purely on likelihood, but also on attributes such as risk to the operation.