In the current implementation, the dialogue manager has access to the components shown in figure 7.
First, there is the dialogue history. The dialogue history is a blackboard consisting of four different levels. Each level can be organized, independently of the others, as a linear list, a tree or a stack each of which hold possibly underspecified typed feature structures. The four layers correspond to orthographic, syntactic and semantic representations as well as representations of the objects (``the world'') the utterances refer to.
It should also be noted that the dialogue manager has access to all levels of representation at any time. As a consequence, the processing steps are not required to be in a certain predetermined order (such as parsing followed by semantic construction followed by database access followed by clarification questions or some feedback generation). Instead, conditions posed on the representations may trigger any kind of action at any time in the process, which greatly increases the flexibility of the dialogue processing.
Figure 6: The four different levels of representation. At all times, the dialogue manager
has access to all four levels and may pass any information on to other processing modules
without being restricted by a static flow of information
Second, there are two stacks holding feature structures representing the user's and the system's intentions, respectively. The dialogue manager updates the model of the user's intentions with all instantiations of task models that are compatible with the information in the current dialogue history. The need to organize the intentional model hierarchically stems from the fact that before the user can give all the information necessary for the system to accomplish a goal (e.g. hotel reservation) the user might need the system to accomplish a sub-goal first (e.g. give complementary information on the hotel). The intentional model of the system typically holds a copy of the intentional model of the user. However, since the user's and the system's models are separated, it is possible to further restrict the intentions of the system by additional conditions so that the system would not need to do everything the user asks it to do. Hereby triggered incompatibilities between the system's and the user's intentions can also be used as conditions for additional recovery strategies.
Clearly distinguished from the intentional models is a representation of the current communicative
goal. While the user's intention might be to perform a hotel reservation, the current communicative
goal might be to specify the arrival date (which in turn might trigger subdialogues on its own,
e.g. the user accidently referring to the 30 
of February).
The dialogue manager has access to the feature structures held in the different components. The dialogue manager is programmed by a set of if-then-else clauses described below.
: The overall architecture of the system. The users intention is to make a hotel reservation.
The system opens a subdialogue in order to inquire the arrival date. The communicative goal of the
user is temporarily replaced by the goal the generated by the system-initiated subdialogue. However,
the intentions of user and system remain unchanged as the hotel reservation could not yet take place.
Only the semantic layer of the four-layered blackboard is shown.
The representations shown are simplifications of the representations actually used in the system.
The system architecture is client/server based, enhanced by an additional message passing scheme. The speech recognizer JANUS has been integrated in the system. The output of the speech recognizer is analyzed by the Phoenix Semantic Parser [Ward1994]. The resulting semantic parse tree is converted into a typed feature structure representing the semantics of the utterance. The semantic representation is added to the history which, in turn, triggers the dialogue processing described below.
