ACPT Mixed Initiative Planning Framework

Austin Tate - 14-Jun-96 with minor changes on 20-Dec-96 - Version 3

This document was written when it was proposed that ISX's ACPT tool should act as the systems integration Framework for IFD-5, as it had done for IFD-4. The concepts here will work equally well in other systems integration frameworks in which explicit ACP process management is undertaken in some sort of system controller module or agent.

ACPT Mixed Initiative Planning Framework - Outline

In order to support the flexible integration and use of a range of planning tools and user-driven editors within the Air Campaign Planning Tool (ACPT), a framework for Mixed Initiative Planning (MIP) centred on the use of an agenda or to-do list is to be introduced. The version of ACPT which supports IFD-4 had an initial agenda capability built into it, and this is to be extended in IFD-5 ready for a possible demonstration of MIP in IFD-6.

ACPT contains an agenda in its Control Panel which is used to help the user maintain a perspective on the planning process and to get support for carrying out that process. Items on the agenda have a regular but easily extendible format which allows for ACPT to know when their triggering applicability conditions are met. A user can manually pick one (or more in later potential extensions) triggered items off the agenda and have ACPT pass these with appropriate parameters to a tool or user interface/editor which is registered as being a capability which can handle that agenda item. System tools or the user may (if registered to do so) post additional items to the agenda to allow the planning process to be continued with the same or other tools or users involved.

The MIP Framework is intended to support a very simple implementation of the concepts of ACP Process Workflow Support. But it is designed so that extension along a number of dimensions of sophistication is possible, depending on the technology demonstration options which present themselves within ARPI.

The MIP Framework will link into and draw on work being conducted by three clusters within ARPI: Collaborative Planning Cluster (for the ACP Tool Capability Models); Modelling Cluster (for the ACP Process Model and ACP Process Verbs); and the Plan Ontology Cluster (for the ACP Plans and ACP Process Products terminology).

Planning Process and Plan Products - Terminology used in the Framework

Military commanders and personnel engage in the Air Campaign Planning (ACP) "Process" in which command, planning and control activities take place. This "Planning Process" leads to the production of a number of intermediate and final "Process Products". These process products are mostly documents or orders, but in general could be any artifacts related to the products of the planning process. These planning products have a number of "Features" one of which is the content of the ACP plans themselves.

There can also be other features, and these are important in describing the way in which products are created, modified or used during the planning process.

Example Process Product Features for ACP

The terminology used for the military action related ACP Plans themselves is confined to the contents of Process Products. This the subject of the ACP Plans Model being developed by the ARPI Plan Ontology Construction Group (POCG Cluster) [Hoebel, Valente, Q396].

Although the planning process involves activities and their coordination, these are described in terms of the activities which take place in the planning process itself (such as plan, change, review) rather than containing activities that relate to military effects (such as destroy, seek-out). The planning process activities can be described using a set of "process verbs" indicating the actions performed at that level. A separate paper has been produced on the ISAT project giving an initial list of process verbs for the ACP Process [Drabble and Lydiard, Q296].

A description of the ACP Process Products and their Features has been created on work under WP2 of the ISAT Subcontract at AIAI [Drabble, Lydiard, Tate, Q396].

A common underlying model of activity may be used for both the planning process and the ACP plans themselves. In particular, the process products are modelled as resources which are created, modified and used within the process. Authority relationships and other conditions are also able to be modelled and may be used in an extension of the basic mechanism if that is wanted eventually. This is the subject of the POCG KRSL-Plans ontology [Tate, Q295], the Process Interchange Format [PIF Group, Q296], the wider-scope Enterprise Ontology [Uschold, Q395] and the more recent OMWG and JTF ATD Core Plan Representation [Pease, Carrico, Q496.

Finally, all terminology used in each model will be available and defined in the ACP Domain Lexicon being built on the ACP Sensus Ontology [Swartout, Q396].

ACPT Agenda Entries

The following is proposed as the framework for presenting actions that can be taken in the ACP Process, the support that can be offered via ACPT, and thus the legitimate terminology for the ACPT agenda.

    source agent                      always known
    destination agent                 may or may not be specified
    verb                              ACP Process Verb
    noun phrase(s)                    Process Products
    [ qualifier(s) ]                  Features of Process Products
    [ trigger(s) ]                    Features of Process Products,
                                      [ inter-agenda item ordering ]
                                      [ inter-agent authorities ]
where [ ] indicates the component is optional

The source and destination agents are agents (people or systems) which can play a certain role within the ACP Process.


The triggers represent the applicability conditions which must be satisfied before the agenda entry is allowed to be handled by an agent which has a suitable capability.

Triggers are often on features of the planning products which flow in the ACP Process (such as the availability of a specific document at a given level of release or given level of refinement of its contents).

Triggers may also relate to ordering constraints between agenda entries. I.e., some later agenda entries may only be performed once earlier agenda entries have been handled. It is possible to avoid the need for inter-agenda ordering triggers if the process products' features are designed such they support all process step ordering requirements. A number of commercial workflow systems make the assumption that document or process product flow itself is sufficient as a basis for triggers.

One way to fill triggers is via "inter-agent authorities". In a well regulated environment, the process products themselves contain all necessary inter-agent authority information, and thus this extension is not needed.

Agent Capabilities and Registration

Each agent (person by role, or system tool) known to the ACPT agenda mechanism must be described in a way which identifies that agent as a potential destination for any given agenda entry. This is done by having a "register" of agent capabilities.

This can be very simple at first, just containing a set of process verbs which an agent can handle, perhaps augmented by some simple constraints on the noun phrase(s) and qualifier(s) that can be handled.

However, more sophisticated extensions are possible for a greater level of intelligent workflow and mixed initiative support in future.

These could include:

  1. sub-activities that make up an overall activity
  2. orderings between these sub-activities
  3. objects or variables that are used in the description
  4. resources utilized during the activities
  5. world state conditions or requirements for the activity
  6. any authorities needed for the activity
  7. any other relevant information or issues that must be address for the activity
In particular, it is possible to "bridge a gap" between an agenda item and installed planning capabilities by using descriptions of ways to "plan for planning" (i.e., generating a workflow plan involving the ACP process activities themselves). There is a proposal to demonstrate such a workflow planning capability within or alongside IFD-5 using O-Plan if suitable hooks are available [Tate, Drabble, Q396].

ACPT Agenda Mechanism Registry

Agenda Entry Registry - used to register the grammar allowed for the pattern in agenda entries (verb/noun phrases/qualifiers).

ACPT Tool/Agent Registry - used to describe a planning tool, user editor, or ACPT component which can be used to address the issues on the agenda. It is registered in terms of:

  1. the agenda entries it can process: verb/non phrases spec./qualifier spec.

  2. the agenda entries it is allowed to post: destination agent spec./verb (spec.?)/noun phrases spec./qualifier spec.

    Including the specification of the destination agent which a tool/agent is allowed to post agenda entries for will allow control over the workflow process. For example, some tools may post entries for other systems, but only "trusted" tools or levels of agent may post directly for the user as a destination (so we do not get "delegation upwards").

    "??" will be allowed if no identified destination agent is known. This would indicate that ACPT should find a suitable destination agent, perhaps with the user selecting amongst any options available.

  3. other information - such as which features of the process products are created, modified or used may be used in more sophisticated variants of this in future to allow for concurrent access to and and selected modification (under suitable authorisation) of process products.

Agenda Audit Trails

It is possible to keep a record of the planning process, agents involved, and their results or performance by recording those agenda entries passed to each agent, the order or time at which this was done, and other relevant information. ACPT already provides a suitable hook for this in its Control Panel.

Process Library - Initial Agent Content - Initial Planning Process Description

A means to select an initial workflow process plan to be used should be provided. This could be a simple mechanism of selecting from a "process handbook or library" which provides processes described in advance. Extensions could allow for the selection to be guided by knowledge of the mission or tasking involved, the type of team or even the individual preferences of the commanders making the selection.

The initial selection would be loaded as a set of agenda items in the required form, and with suitable triggers, into the agenda during the initialization of the agenda/workflow support system.

Adding to the Agenda via External Events

Events triggered by some change of tasking or change in the situation could be entered onto the agenda in a form that allows for concurrent handling alongside existing agenda entries.

Requirements for Support in ACPT

Agenda mechanism within ACPT Control Panel: using the base in IFD-4, but regularizing the terminology and format of agenda items to be "verb" orientated using the structure proposed above. Assuming at first a user driven activation of tools from agenda entries, but allowing for automated activation of tools for which such activation has been allowed by the user. It could be advantageous to have all planning tool activation be off the agenda (even if initiatied by the user), rather than providing separate buttons in the ACPT Control Panel as in IFD-4. This could begin to regularize planning process workflow, and improve the opportunities for user guidance, and status reporting.

Triggering mechanism: to be able to monitor a set of agreed features of process products (as attributes of objects representing those products), and to use these to indicate when agenda items waiting for those triggers are satisfied. The user interface may "grey out" non-triggered agenda items or present these in some suitable way.

Planning Tool Registry: a mechanism to register planning tools or user editors by recording the agenda items which they can process, and perhaps other information in extensions to the basic mechanism.

Agenda Entry Registry:t may be advantageous to have an explicit way to register the legal agenda entries in the form of a grammar. This would allow more active workflow management and inter-tool checks.

Common Tool/Agent Call Interface: a way to allow a planning tool or a user editor or interface to be called by passing it one (or more in extended variants) agenda entry and relevant parameters (mostly in terms of process products such as documents in the ACPT Plan Server).

Internal Format of Agenda Entries in ACPT

The fields of an agenda entry within ACPT could contain:
  1. id: something to uniquely identify the agenda entry
  2. source agent: to identify the person, or system which posted the agenda entry.
  3. destination agent/capability: a description of the agent, person or capability that should take the action. This could be underspecified and may not (yet) be specified at all. At the other extreme it could be a single nominated person, agent or system that should deal with the agenda entry.
  4. action: a verb - the action ACPT or the user is expected to take (e.g., review, note, correct, expand, do, and so on). The domain ontology should give us this vocabulary and Doug Holmes ACPT scenario document appendix has a good initial list.
  5. parameters: a set (possibly empty) or parameters for the action, including noun phrases and qualifiers identified with ACP process products and features.
  6. information: a field in which additional information can be posted or held. This can be used by intelligent agenda analysers or by agents/capabilities to hold information after initial study of the agenda entry, but before processing begins properly.
  7. triggers: a predicate indicating when the agenda entry can be processed by a suitable agent/capability. Normally referring to process product information needed, inter-agenda entry orderings, etc.
  8. priority or preference information: to allow for heuristic scheduling of agenda entry processing by agents/capabilities.
Not all of these need be displayed to the user. Simple linear lists of the agenda entries are not usually helpful except for system testing.

Demonstrating True Mixed Initiative Planning

To demonstrate Mixed Initiative Planning fully, we should allow for cases where the user is driving the process, where the system is driving the process and the most likely situation, where the user and system have understood roles and where both are performing tasks expected of them while cooperating to ensure the process products are produced as desired.

The Mixed Initiative Planning and Agenda Framework presented provides the underpinning to support all these models. It can be used very simply, or is capable of expansion to a rich "Intelligent Workflow Planning and Execution Support" framework. Expressed needs in the JFACC programme and in the DARPA Collective Action Tools Community to allow for reasoning about time schedules and resource levels in the planning staff could be supported. Delegated authority to people performing given planning roles and systems or tools which can carry out given roles is possible.

ISAT AIAI WP3 O-Plan in the MIP Framework under IFDs

Here is a suggestion of how O-Plan could link into IFDs and help in a demonstration of the Mixed Initiative Planning Framework proposed for ACPT under IFD-5 and IFD-6.

  1. off the ACPT control panel section that has the 5 activities buttons and the agenda, assume that there is a "How do I Do This?" button this may be present for each agenda entry that is not already expressed in primitive capabilities, or may be a separate button that operates on a "highlighted" set of agenda entries.

    O-Plan, acting as an ACP workflow planner, would be called on the indicated agenda entries and would be handed the current workflow "plan" (the current set of agenda entries) and "state" (the present values of the features of the process products in the ACPT "plan features server") via the ACPT controller. It would return additions to the agenda, normally in terms of a replacement set of agenda entries for the one(s) it was passed. This basic demonstration could open the possibility of reasoning about planning resources and time scales in the planning process itself.

    It could be advantageous to be able to return "compound agenda entries" (inter-agenda item orderings) at the ACPT workflow level (these are just partially ordered workflow activities to O-Plan). But this will depend on this being a feature known to the workflow core of ACPT.

    It may be possible to include O-Plan in IFD-5 or working alongside it as a demonstration in this role.

  2. the second use of O-Plan would be as a planning tool, in the same fashion as SIPE and EXPECT are called today in IFD-4. In future they could be activated by "applying" them as a nominated agent or destination for an agenda entry, or could be applied on a number of highlighted agenda entries for which they provided the appropriate capability.

    O-Plan could be included within IFD-6 in this role. [O-Plan project deliverable A-0 - the ACP domain demonstration story board - proposed ACP planning capabilities which may be suitable for an IFD-6 demonstration].