Like the RM, the pipeline view abstracts from actual system implementations, too. That is, in a real system, the flow of information not only depends on the logical task structure but also on the particular mechanisms employed for generation. As generation entail many combinatoric issues, most existing IMMPSs rely on a generate-and-test approach, at least for solving some of the generation subtasks. The basic idea is to have a mechanism which allows the withdrawl of earlier decisions (e.g., a choice among alternative candidates) in case the proceeding computation does not lead to satisfying results, or any result at all. For example, a system may have generated a graphic which, at the end, does not fit properly into the overall presentation layout. To fix the problem, the system may withdraw the layout design, the graphics design, or may even decide to use text for presenting the information rather than using graphics at all.
To precisely characterize the flow of information in a concrete system, one
has to look at:
(a) decisions which are subject to backtracking,
(b) the architectural organization of the components performing
the decision making,
(c) the backtracking mechanism(s) itself as this can be done in a more
intelligent way, rather than exhaustively enumerating
combinations (cf. [15, 16]).