One might question this hierarchical organization in instances where failures are due to interacting goals alone. Why not just store all cases on a single level first indexing each case by all of its goals, then by the conditions relevant to all of these goals? The answer lies in the need to censor cases when failure conditions are satisfied. This type of error will be found when retrieving multiple cases. As an example, consider that our new problem contains three goals, g1, g2 and g3. Suppose further that the goal g2 negatively interacts with both g1 and g3. If a case is retrieved from the library which achieves both g1 and g2, then one goal, g3, is left open. However, if a case is then retrieved which solves g3 alone, it will fail because of the presence of g2. This type of retrieval error is handled by prioritizing cases. A repairing case is stored as a subclass of the case that failed. Failing cases are annotated with the failure reason which directs the retriever to the case that avoids the failure.
Prioritizing cases on the basis of negatively interacting goals alone is not sufficient to capture all of the retrieval failures that may be encountered. If cases are retrieved on the basis of a partial match of the relevant initial state conditions, then retrieval errors may occur because of unmatched conditions . For example, just as a failure might occur in our logistics transportation example if there is an extra package off the plane's route, a similar failure will occur if a package is moved off the plane's route. The strategy that is adopted to deal with both types of failure information is to annotate the case with the failure reason (whether it is an extra goal or an unmatched initial state condition) and use the failure reasons to prioritize cases. The EBL techniques that we have employed in the construction of failure explanations may be used for both types of failures.
DERSNLP+EBL's method of storing multi-goal cases only when goals are negatively interacting limits the size of the case library. Other aspects of DERSNLP+EBL's storage strategy also serve to lower library size. The planner always uses its current library in solving new problems. New derivations are stored only when there is no applicable case, or when the retrieved cases fail. This strategy avoids the storage of duplicate cases, but may not be entirely effective since the soundness of failure explanations is not guaranteed. If failure explanations are not sound, pointers to repairing cases may eventually lead to a duplicate case, causing the library to continue to grow indefinitely. However, this is easily checked by putting a depth limit on the number of repairing cases in the discrimination net. Also, failures which are due to interacting goals will not result in unchecked growth of the library since the number of interacting goals is limited by the maximum problem size.