The critique step is an analysis of why the verification failed, in other words why the method is not an appropriate method. In our propose-critique-modify method we verify and criticise complete methods. The result of the step is the identification of one of the six components that is held responsible for the failure of the verification step. Notice that we do not yet identify a possible repair action that must be taken to fix this component. That is the purpose of the modify step. The blame-assignment is done based on domain specific knowledge (i.e. diagnosis knowledge). Unfortunately, we do have only limimted concrete examples of such knowledge. Another open issue is what to do if there are multiple possible components that can be responsible for the verification failure.
An example would be a violation of the goal ``maximum number of diagnoses is one''. The system might contain the knowledge that the existence of too many solution can be blamed on the selection criterion. A possible subsequent repair action in the modify step would then be to use a definition for the Selection component that filters more explanations.
We need a critique step, because the verification (especially the simulation-verification) is very expensive (because of performing diagnosis). Such a critique step enables us to control the search instead of generating arbitrary methods and testing these methods until we find a correct one. This is our main motivation for using a propose-critique-modify method. Normally the large search space is the main motivation to use PCM methods. In our case this holds too, but even more important is the motivation of the expensive simulation-verify step. Therefore controlling (reducing) the search space is necessary.