favor of the weekday activities. In the following we consider how to account for this effect: the effect of feasibility constraints upon learning preferences.

Recall that we assume that we can directly observe a user's behavior, for example by building upon the work in *plan recognition*. In this section we additionally assume that we have access to the set of feasible alternatives to the observed behavior - for example by assuming access to the planning problem the user faced and building upon the work in *automated planning* [12].6 For our purposes it is not a large sacrifice to exclude any number of feasible alternatives that have never been chosen by the user (in some other situation), in particular we are not concerned about the potentially enormous number of feasible alternatives (because we can restrict our attention to a subset on the order of the number of observed plans).7 So, in this section, the input to the learning problem becomes:
Input. The i th observation, (φi, Fi) ∈ Φ, consists of a set of feasible possibilities, Fi, along with the chosen solution: φi ∈ Fi.

In the rest of the section we consider how to exploit this additional training information (and how to appropriately define the new learning task). The main idea is to rescale the input (i.e., attach weights to the observed plans φi) so that rare situations are not penalized with respect to common situations. We approach this from the perspective that preferences should be transitively closed, and as a sideeffect we might end up with disjoint sets of incomparable plans. Subsequently we apply the base learner to each, rescaled, component of comparable plans to obtain a set of pHTNs capturing user preferences. Note that the result of the system can now be 'unknown' in response to 'is A preferred to B?', in the case that A and B are not simultaneously parsable by any of the learned pHTNs. This additional capability somewhat complicates evaluation (as the base system can only answer 'yes' or 'no' to such queries).