Below is a summary of the work that I've been doing to understand the totality of the strategies currently supported in ICEE, and information on the strategies discussed in our ExaCt paper that are still not implemented. I would imagine that as we get deeper into the work on conflicts and failures, we will want to add some additional strategies to this list (you'll note that there aren't very many right now that specifically address failures, though some strategies in other categories would like be relevant and useful in the context of a failure as well). Below are the 19 strategies (and accompanying explanation templates) currently included in ICEE. Strategies 1-4 are generic execution-level strategies. Strategies 5-7 were created for Tailor, but also apply to other task learners. Strategies 8-15 were created for LAPDOG, but are more widely applicable, with minor changes (eg, many of them assume learning right now, but that is not intrinsic to the strategy, just to the current wording of the accompanying explanation) Strategies 16-19 were created for PLIANT (preference learning in PTime). The current templates are specific for learning scheduling preferences, but could easily be adapted by parameterize more things and thus be used for explaining any SVM with a linear kernel and intelligently-represented features. 1. Strategy: expose source (requestor) Explanation: I am doing because told me to. 2. Strategy: expose current task hierarchy Explanation: I am trying to do , and is one subtask in the process. 3. Strategy: expose past task hierarchy Explanation: I am trying to do , and I have already completed step , so now I am working on step . 4. Strategy: expose external condition Explanation: I am waiting for to be completed by an external agent. 5. Strategy: expose learned source date Explanation: I learned this procedure for achieving on . 6. Strategy: expose learned source Explanation: I learned a new way of achieving through by . 7. Strategy: expose modification source Explanation: I learned a modification to an existing procedure through an instruction from . NOTE: this strategy is only currently used for Tailor, which is the only existing way to modify procedures, so it is biased towards that method right now. It could be easily generalized. 8. Strategy: provide information on parameterization (constants) Explanation: For this task, I have learned to always use these values: . 9. Strategy: provide information on parameterization (variables) Explanation: For this task, I have learned to ask for user input for these values: . Note: we may want to combine (1) and (2) and always provide both variables and constants at the same time. This approach additionally has the benefit of re-wording (1) to something like "I will not ask for user input for these values: " which is clearer, but only in the context of also saying (2). 10. Strategy: expose inferred relational path Explanation: For this task, I learned that is always found with this relationship: . 11. Strategy: expose learning context Explanation: I have learned to only do this task (or this step) under the following conditions: . Explanation: I have learned to do this task (or this step) under all conditions or contexts. 12. Strategy: expose selection criteria Explanation: For this task, I have learned to select items using this criteria: 13. Strategy: identify multiple uses of same constant or variable Explanation: For this task, I have learned to use in the following ways: Note: we need to review the SPARK-L generated by LAPDOG to see if we are able to identify the usage of a variable in a way that we can present to the user. I would guess that this will be difficult, particularly early on. 14. Strategy: expose looping behavior Explanation: For this task, I repeat these same steps multiple times: B Explanation: For this task, while is true, I repeat these same steps multiple times: B Note: If B is long, or if it has a complex structure (eg, conditionals, or multiple binding commands intermixed with actions) this explanation will be unwieldy (not a concern with LAPDOG right now, though). 15. Strategy: expose container variable Explanation: For this task, I learned to perform actions for each item in . 16. Strategy: explain origin of preferences Explanation: This schedule closely follows the preferences you told me when we started. Note: This is used when the meta-information in the SVM shows high reliance on the initially entered preferences (one of the highly-useful features of the SVM). 17. Strategy: Reveal proximity to past data along particular dimensions Explanation: This schedule is similar to other schedules that you have chosen in the past, and I have observed your preference for . Note: The are the feature dimensions that line up particularly well with the nearest preferred data points. 18. Strategy: Reveal proximity to past learned data, with respect to SVM margin Explanation: This schedule seems to be strongly preferred, based on your past selections, and I have observed that you have a preference for . Note: This strategy is useful when the the margin is higher than average. The last clause of the explanation can be left out if no feature contributes highly to the margin or stand out as such. 19. Strategy: Reveal that the SVM is attempting to explore the feature space. Explanation: This schedule does not closely match your preferences, but listing it here will help me to understand more about your preferences, so that I can do better in the future. Below are other strategies that we discuss in the ExaCt explanation categorization paper, but that are not yet implemented in ICEE. I've divided them roughly into categories to show the main reason why they are not included in the current system. Strategies Not Necessary in Current Interface: (These would all be fairly easy to add, but probably aren't a high priority.) - name the current task - list (or summarize) recently completed tasks - list current top-level tasks - return an answer from predefined status value (eg, "in process") - report information on timeline of current execution - expose differences between important points on a timeline Precondition & Termination Condition Strategies: (We are not currently capturing these conditions through the Wrapper.) - identify termination conditions not yet met - expose meta-information on preconditions - expose dependencies between preconditions - provide details relative to progress towards termination conditions - expose failed precondition - identify transitive precondition relationships Strategies Not Yet Supported in SPARK: (These weren't supported the last time I checked....) - highlight stalled goals - report expected and current duration - list uncompleted subtasks - provide time estimate for start of a future task - provide time estimate for completion of a task - [several hypothetical "explain this future plan" strategies] - state necessary conditions to avoid a particular state - provide estimates for task durations - expose subtasks that took longer/shorter than their expected duration Strategies Related to Other Future Work: - report failure modes & possible workarounds - report and explain a condition that caused an execution branch