Mixed Initiative Planning in O-Plan2

The model of Mixed Initiative Planning that can be supported by the O Plan architecture is the mutual constraining of a set of alternative partial plans for some task set This paper describes the opportunities for mixed initiative planning within the O Plan ar chitecture Both the user and the system can work in harmony and neither is seen as at a higher level or in charge as far as the architecture is concerned Ordering and priorities can be applied to impose speci c styles of authority to plan within the system One extreme of user driven plan expansion followed by system lling in of details or the opposite extreme of fully automatic system driven planning with perhaps occasional appeals to an user to take prede ned decisions are possible In more practical use we envisage a mixed initiative form of interaction in which the user and system proceed by mutually constraining the plan using their own areas of strength Appendices describe in more detail the use of the KS USER knowledge source to wrap around the interfaces provided to the user and to ensure integrity of the system the various user roles identi ed within the O Plan design details of the search space explored by O Plan and other relevant information concerning mixed initiative planning within O Plan Mixed Initiative Planning in O Plan Partial Plans as a Set of Constraints An O Plan plan is viewed as containing a set of constraints on the possible plan elaborations that can be entertained Users and system in a mixed initiative way jointly add or relax constraints in the plan as planning proceeds A plan conceptually has three levels implied constraints called the plan agenda plan level entities decided upon plan components at various levels of abstraction detailed constraints for time resources authorities conditions e ects object selections spatial use etc These are associated with the plan level entities Explicit options Courses of Action may exist for plans and may share a lot of common struc ture At any time the system or an user can work on this set of constraints normally being directed by the agenda Plan Agenda and Control The agenda keeps everyone straight about what remains to be considered Inconsistent plans and partially elaborated plans are possible using the agenda to represent such outstanding issues Focus of initiative is determined by decisions on the order in which agenda entries are processed This ordering decision process is separate to the involvement of the user in constructing a plan Mixed initiative is possible The user can delegate to the system by adding suitable agenda entries implied constraints for parts of the work that the system can handle best The system can seek help from the user via the same mechanism Or both can take a look at what they can do with the agenda Critiquing can lead to new agenda entries to work on Plan Modi cation Operators Knowledge Sources plan agenda choose PMO v plan entities do PMO v plan constraints update plan Mixed Initiative Planning in O Plan Users or the system can when sanctioned or authorised work on anything that is outstanding on the agenda They do this through the wrapper of a Plan Modi cation Operator PMO This is like a knowledge source in blackboard systems An user also interacts via a PMO wrapper to ensure that plan integrity is maintained All decision making processing which can alter a plan is done via plan modi cation operators The recording of dependencies and who is responsible for changes to the plan is possible in such PMOs to support later plan changes and constraint relaxation This has been done in some versions of our planners at Edinburgh PMOs called knowledge sources in the O Plan architecture can run on one or more knowledge source platforms Concurrency is possible with multiple platforms Real time capabilities can be assured by having dedicated platforms for a nominated knowledge source One or more platforms can run knowledge sources to provide the planner user interface s Plan Entities and Detailed Constraints The user or the system made alterations to a plan are done at the plan entities layer which expresses most of what can be thought of as the interesting contents of the plan and certainly contains what the users are likely to want to work with Whether user or system decisions lead to a change of the plan entities they are subject to lower level constraint management at a detailed level where critiquing of the changes and inconsistency issues are raised directly with the caller or via the agenda The constraint manager level NEVER takes any decisions so the user and the decision making level of the system can maintain a simple view of what is going on and who is changing what