{'fraction_non_alphanumeric': 0.033771552363711904, 'fraction_numerical': 0.006499094874914681, 'mean_word_length': 4.342952275249723, 'pattern_counts': {'":': 0, '<': 26, '<?xml version=': 0, '>': 29, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Optimal To-Do List Gamification for Long Term Planning

Most people struggle with prioritizing work. While inexact heuristics have been developed over time, there is still no tractable principled algorithm for deciding which of the many possible tasks one should tackle in any given day, month, week, or year. Additionally, some people suffer from cognitive biases such as the present bias, leading to prioritization of their immediate experience over long-term consequences which manifests itself as procrastination and inefficient task prioritization. Our method utilizes optimal gamification to help people overcome these problems by incentivizing each task by a number of points that convey how valuable it is in the long-run. We extend the previous version of our optimal gamification method with added services for helping people decide which tasks should and should not be done when there is not enough time to do everything. To improve the efficiency and scalability of the to-do list solver, we designed a hierarchical procedure that tackles the problem from the top-level goals to fine-grained tasks. We test the accuracy of the incentivised to-do list by comparing the performance of the strategy with the points computed exactly using Value Iteration for a variety of case studies. These case studies were specifically designed to cover the corner cases to get an accurate judge of performance. Our method yielded the same performance as the exact method for all case studies. To demonstrate its functionality, we released an API that makes it easy to deploy our method in Web and app services. We assessed the scalability of our method by applying it to to-do lists with increasingly larger numbers of goals, sub-goals per goal, hierarchically nested levels of subgoals. We found that the method provided through our API is able to tackle fairly large to-do lists having a 576 tasks. This indicates that our method is suitable for real-world applications.


Introduction
Procrastination and prioritization are challenges that many people face in their daily lives [11] since setting the right priorities and working diligently requires a lot of mental effort and selfdiscipline. Procrastination is a consequence of people's tendency choose smaller immediate rewards over larger later rewards [11]. This propensity decreases people's productivity, which is defined as the amount of value that a person generates by completing a series of tasks within a fixed amount of time. While several decision support systems have been developed to support human decision-making in specific domains [1,3,4,9,10], only [12] provided a method for helping people decide what to work on on a daily basis. [12] developed a method to approximate optimal to-do list gamification [8] for long to-do lists. Optimal to-do-list gamification incentivizes tasks so as to align the tasks' short-term rewards with their longterm consequences.
Here, we extend our previous work [12] which laid the foundation to scalable to-do list gamification. [12] exploited the hierarchical structure of to-do list composed of goals and tasks, by using a 2-level hierarchical decomposition of a discrete time semi-Markov decision process (SMDP; [5]) and various inductive biases to trim the search space. Moreover, the method mitigated the exponentially-increasing computation cost with respect to the number of tasks in the to-do list. The method incentivizes tasks taking into account the task's deadline, the value the user associates for the completion of the corresponding goal, and the estimated time for completion of the task. The main limitation of the approach was its assumption that all tasks can be completed on time. This led to improper incentivisation when this assumption was violated. Additionally, the previous method was unable to handle to-do lists in which a series of tasks were required to be completed in a specific order. In real life, such cases are common wherein a task requires a specific sequence of actions to be completed. Additionally, people often set unrealistic goals or have goals which are realistic in the beginning but become unrealistic with the passage of time.
In this report, we present an algorithmic solution which extends the work of [12] so as to overcome these limitations and is able to handle more complex planning problems. Our new method supports goal systems with many hierarchically nested levels of subgoals. It allows the user to indicate that some sub-goals are essential to the completion of the corresponding superordinate goals and assign different levels of importance to different goals and tasks. Furthermore, it can handle tasks that are intrinsically valuable to the user regardless of their contribution to achieving a larger goal. To compute the incentives for such to-do list, our new method breaks down the to-do list into smaller SMDPs (called mini-SMDPs) comprised of goals and sub-goals, which are then solved using the 2-level hierarchical abstraction for the mini-SMDP. The same method is applied recursively, as the values of the sub-goals are propagated downwards. The main benefit of the added parameters is that the assignment of optimal points take into account more human-like considerations and are more in line with a user's intentions. It also allows for dependencies between tasks imposed by users in order to form sequences of tasks that have to be executed in a particular order by creating a chain of sub-goals, with higher-priority tasks kept lower in the chain, all marked essential for completing its immediate superior sub-goal.
Furthermore, we packaged this algorithm in an application programming interface (API) that takes in a to-do list and outputs a gamified list of tasks.
This text is divided into the following sections: In Section 2, we describe the formal definition of the problem as a discrete-time SMDP. In Section 3, the algorithm is explained with Section 3.1 describing how the mini-SMDP are solved and Section 3.2 describes how the value of the higher level mini-SMDP is transferred to the lower-level mini-SMDP. In Section 4, we provide a case study to show the the assignment of pseudo rewards and illustrate its functionality by comparing the performance of our proposed algorithm with an exact solution using Value Iteration [2]. We systematically show how our proposed algorithm has no difference in performance as the exact solution. Additionally, Section 4 also evaluates the speed and reliability of the API. Section 5 introduces the API we have developed. Lastly, in Section 6 we outline directions for future work.

Problem Formulation
The goal of to-do list gamification is to maximize the user's long-term productivity by proposing daily task lists where each task is incentivized by a certain number of points. These points transform the short term rewards to reflect the long term rewards and consequences overcoming human's present bias [11]. Users compose hierarchical to-do lists comprised of three types of items: goals, sub-goals and tasks. We define a task as a sub-goal that cannot be further  Figure 1: Graphical example of a hierarchical to-do-list.
decomposed. Simply put, a task is the smallest non-divisible unit of work. Solving a SMDP generates the optimal plan to complete a list of user-specified tasks. The solution of the large SMDP is approximately computed by solving each level of the hierarchical to-do list as a mini-SMDP. Each mini-SMDP consists of 1 goal and multiple sub-goals. In each mini-SMDP, the sub-goal is treated as a task, and as such, would be referred as a task from now on. We define a root of a to-do list as an imaginary node, whose sub-goals are top-most goals as seen in Figure 1. Goals consist of a deadline, a value estimate, and a list of sub-goals. Each sub-goal contains a time estimate to complete the sub-goal, a Boolean value to indicate if the sub-goal is essential to complete its corresponding goal, its importance to complete its immediate goal, and intrinsic reward, which is the reward obtained on completing a sub-goal, independent to the completion of its goal. A sub-goal is deemed as essential if the completion of the sub-goal is necessary for the completion of the goal. In other words, a goal cannot be completed without completing all of its essential sub-goals. As such, an essential sub-goal is marked with a high importance factor, and a non-essential sub-goal should be marked with a low importance factor.
In addition, users specify their desired workload in hours for a typical day (typical day's working hours) and for the day at hand (today's working hours). The outputted gamified daily schedule should contain all tasks that users indicated they wanted to work on today, as well as additional tasks towards their goals, up to the desired daily workload.

Modelling the to-do-list as a discrete-time SMDP
The state space S consists of all possible combinations of completed and uncompleted tasks. Since a task can either be completed or uncompleted, each s ∈ S is a binary vector of length n + 1, where n corresponds to the total number of tasks in the SMDP and the slack-off task. The slack-off task represents when an user decides to no longer do any more productive work. If the i-th element of any binary vector s ∈ S is 1, the task associated with the element is completed, and 0 otherwise. Similarly, the action space A refers to the selection of a task and hence a ∈ A is of the same size, n + 1.
Considering G top-most goals, each goal having D sub-goal levels and each sub-goal having B sub-sub goals, the to-do list would have a total of G · B D tasks. Without breaking the to-do list into multiple mini-SMDPs, the state space would be of size 2 (G·B D +1) . By breaking down into mini-SMDPs, we would need to solve G · D SMDPs with a state space 2 B+1 . Hence, the decomposition of the to-do list into mini-SMDPs shrink the size of the state space and the number of computations go down from 2 (G·B D +1) to B · D · 2 B+1 .

Transition time F
In a SMDP setting, the transition-time function, F (τ |st, a) is the probability that the time at which the agent has to make the next decision occurs in exactly τ time units, as a consequence of executing action a in state s at time t. We chose a transition-time function that can model the cognitive bias known as the planning fallacy, in which people underestimate the time required to complete a task. Kahneman and Tversky [6] describe this bias as such: "Scientists and writers, for example, are notoriously prone to underestimate the time required to complete a project, even when they have considerable experience of past failures to live up to planned schedules... It frequently occurs even when underestimation of duration or cost is actually penalized." Since the SMDPs are modelled with discrete time steps and people have unreliable time estimates, we model the number of time units required for action completion to follow a zero-truncated Poisson probability distribution 2 with adjusted mean value and variance. We formally define the transition-time function as wherek = c pf · k, k is the discrete amount of time units required to complete action a in state s at time t, and c pf ∈ R>0 is a planning-fallacy constant that adjusts the distribution parameter.
In lack of knowledge about the exact value of the planning-fallacy constant (c pf ), we follow King and Wilson [7] and we initially set its value to 1.39. Obtaining better estimates for this value based on real-world data is left for future work.

Transition dynamics T
The transition dynamics from a current state s at time t to a next state s after executing an action a is deterministic in completion, but stochastic in duration. In other words, the presented algorithm assumes that users will complete a task once they they start but may require more time than the time estimated for completion of the task. Under these assumptions, In other words, the transition probability T (st, a, s t+τ ) is completely dependent on the probability of completing an action in exactly τ time units, which can be formally written as where τ ∼ F (τ |st, a) is the transition-time function that determines the time needed to complete a chosen action a in state s at time t, and s is the state that follows as a consequence of executing action a in state s. Formally, if an action a is represented by the i-th bit of the binary state vector s, the binary vector of the next state s can be written as s = ei ∨ s, where ei is a one-hot vector with a value of 1 only at its i-th position, and ∨ represents the "or" operation of two binary vectors. A special case of the transition dynamics occurs after reaching the terminal state in which all real tasks have been completed or if the slack-off action is selected. There, the process transits to a goal-achieving state s † after instantaneously executing the action a † in 0 time steps, that is T (1, a † , s † ) = Pr(s † |1, a † ) = 1.

Reward function
We define the reward function r(st, a, s t+τ ) from a current state s at time t to the next state s at time t + τ after performing action a ∈ A that takes τ time units for execution to be if the slack off action was chosen −λ (g) τ −1 k=0 γ k +γ τ −1 · rextrinsic(st, a, s t+τ ) · Π(βg) +rintrinsic(a) if any other action was chosen if goal is complete 0 if goal hasn't been completed where a+, represents slack-off action, γ ∈ (0, 1] is a discount factor, R(g) indicates the value of a goal g ∈ G. λ (g) ∈ R>0 models the value that reflects the cost of a person's time and mental effort to work on goal g. I done (s t+τ ) refers to the list of importance values of the subset of completed tasks in state s t+τ . R(g) returns the goal value if executing the next task-level action a leads to completion of goal g. We define Π(βg) to be the penalty function for a goal g. The value of the penalty function discounts the goal reward proportionally to the time by which deadlines associated with that goal are missed and it can be formally written as Π(βg) = (1 + βg) −1 . Here βg = n i ψ · ∆ti is a weighted sum of penalties for tasks whose deadlines were ψ ∈ R>0 is the penalty rate (per unit time) and ∆ti is the number of time units by which the deadline was missed.
According to the definition, an immediate negative reward and a small positive reward is obtained for completing each task. Conversely, an immediate positive reward is obtained after the goal is completed or a slack-off action has been chosen for execution. A goal is said to be completed if all essential sub-goals are completed.

Optimal policy
As described in Section 3.2, each to-do list is broken down into mini-SMDPs in a hierarchical manner, treating each layer as a goal to propagate and compute the value of each individual task. Once all of the 2-layer mini-SMDPs have been solved, their tasks and the corresponding point values are collated into a single gamified to-do list. The (approximately) optimal policy can then be defined as always choosing the task with largest number of points from the list of uncompleted tasks.

Method
An SMDP consists of one goal and multiple sub-goals. As mentioned in Section 2, while solving the SMDP, we consider each sub-goal as a task with no sub-tasks.

Solving mini-SMDP
Given a mini-SMDP with B sub-tasks and starting time as t = to, the stating state st o is represented as a vector of size B + 1. The mini-SMDP is computed by first checking the tasks completed, marking the vector 1 if the corresponding task is completed. The last index of the vector represents if the slack-off action has been previously selected, indicating that the state is now in state s † .
From the starting state, the method computes the expected reward for all the possible sequences of tasks. This is implemented using the wrapper function solve(Algorithm 1) and recursively calling solveNext(Algorithm 2) which utilizes getExpectedReward(Algorithm 3). The method solveNext(Algorithm 2) shows the recursive calls to all possible sequences of tasks. After initializing the Q-values for a given state and time, it iterates over all the possible actions in the given state. If the optimal sequence following an action is not computed before and if the action is not a slack-off action, the method computes the expected reward for following the given action and then the optimal policy before updating the Q-value for a given state and the expected reward of doing a task.
The method getExpectedReward(Algorithm 3) finds the expected reward for a given action. It shows how the SMDP is solved, taking into account that each task is completed in an unequal amount of time. The expected reward for completing the task is computed by iterating over time estimates using the transition function F . The expected task reward is calculated by taking the weighted average of the reward obtained by completing a task for each time estimate. It takes into account the penalty of missing the deadline (if missed) and the discounted cumulative cost for performing the task an the immediate reward from the reward function r(st, a, s t ). Additionally, the reward for following the optimal policy is computed for each time estimate to also compute the expected total reward used Used for updating the Q-value.

Passing of the value function
To understand how the value is propagated down the SMDP, we utilize an example to-do list shown in Figure 1. It consists of 2 goals, which having 2 sub-goals. Each sub-goal has 3 tasks. The SMDP is broken down into 7 mini-SMDPs as shown below: A dummy "Root" node is created to facilitate solving of the mini-SMDP. The root goal value is the sum of values of the goals assigned by the user and denotes the total number of productivity value in the to-do list. The importance of each goal is given as the ratio between the value assigned to the goal and the sum of values of all goals.
In the 1 st mini-SMDP, all goals are represented as tasks and marked as non-essential. The intrinsic reward of a goal is computed recursively by taking the sum of the intrinsic reward of all its sub-goals.

Algorithm 1 Solving the mini-SMDP
Input: s to , t o Output: P, Q Returning the expected reward & policy from the given state The optimal action to do in current state P[s to ][t o ] = a end procedure Algorithm 2 Recursive function to compute expected reward for given state and time. Input: s t , t Output: P, Q Returning the expected reward and policy from the given state procedure solveNext(s t , t) Initialize dictionaries for Q-function for given [a] += expTaskReward end if end for end procedure Algorithm 3 Computing the expected reward of doing action a in state s in time t Input: a, s t , t, t max Output: expTaskReward, expTotalReward procedure getExpectedReward((s t , t, a, t max ) After solving the 1 st mini-SMDP, the value of the sub-goals (Goal A, Goal B), denoted by R(SG k ) will be passed down to the 2 nd and 3 rd mini-SMDPs as follows is the return of the optimal policy of the 1 st mini-SMDP. τSG k is the time estimate to complete all essential tasks of the sub-goal SG k .
Similarly, after solving the 2 nd mini-SMDP, the value of SG A1 will be passed down to the 4 th mini-SMDP and value of SG A2 to 5 th mini-SMDP. Likewise, the value of SG B1 and SG B2 will be passed down to the 6 th and 7 th mini-SMDP, respectively. The flow of solving mini-SMDPs is depicted in Figure 2

Results
In order to ensure the accuracy of the computed optimal rewards, we first generate a case study and discuss the algorithm's output. Specifically, in Section 4.1, we present the optimal sequence of tasks suggested by our proposed algorithm.
Furthermore, in Section 4.2, we compare the performance of the proposed method with an exact method to compute the optimal points for a number of case studies. In Section 4.3, we show the limits of the proposed algorithm which satisfies the 30 seconds time limit imposed by the Heroku service.

A case study of optimal to-do list gamification
In the following test case, we designed a realistic example with 3 goals. Goal A is the goal with the closest deadline, which is expected to be completed only if all its tasks are prioritized first. Goal B, is the next goal which has a more flexible deadline and can be completed even after Goal A has been completed. Goal C is a goal which has a high value but it is impossible to be completed within its deadline. The detailed description of the to-do list is given below. For each goal, a Value is assigned which represents the value associated for completion of a goal, similarly, there is a Deadline which indicates how many time-units the user has to complete the goal. Each sub-goal has an Intrinsic Reward which denotes the reward derived of completing the sub-goal, independent of the corresponding goal. Ess is a Boolean value which is True is the sub-goal is deemed essential to complete the corresponding goal. Additionally, Imp denotes how important the sub-goal is relative to the other sub-goals. Finally, Time indicates the estimated time to complete a sub-goal. The optimal sequence of tasks is found by selecting tasks in a myopic greedy manner, in which the task with the highest points is selected first and is completed exactly in the estimated time. The optimal sequence of tasks in the to-do list is to first select all the tasks to achieve Goal A. Since all tasks of Goal A are essential, all tasks of Goal A are first selected. Afterwhich, the tasks to achieve Goal B were selected. Following which, only the tasks needed to accomplish Goal C remain. At this stage, the optimal action to perform would be to slack-off. The slackoff reward is 10.11 which has more points than the any task in Goal C, with the highest points belonging to Task C11, with 7.0 points. The selection to slack-off makes sense and can be explained by looking into the sub-goals of Goal C. Goal C consists of 2 essential sub-goals, of which sub-goal SG C2, is not possible to be completed realistically before the deadline, hence, performing any tasks of Goal C would not yield to the completion of Goal C and should not be completed.
The printout below shows the gamified to-do list that would be shown to the user for the specifc case study, where the user selects the task with the highest points and performs it in its estimated time. In each printout, Tasks Completed:, lists the completed tasks. Following which, the list of uncompleted tasks are listed in descending order of points, where PRS denote the amount of points computed for the corresponding task. Finally, Net PR Sum: gives the sum of points, rounded to the nearest integer, of all uncompleted tasks.

Comparison with exact solution
As shown in Section 4.1, we assume that the user always selects a task with the highest points in the incentivised to-do list until the points for the the task with the highest points is less than the slack-off reward. This strategy is called the myopic greedy strategy. The performance of the myopic greedy strategy on to-do lists incentivized by the points computed by our proposed algorithm is compared with its performance on the same to-do lists when they are incentivized by the exact point values calculated using Value Iteration [2]. The exact method can be understood as applying Algorithm 2 and Algorithm 3 in a flattened SMDP where the action space and state consists of actions which correspond to the completion of every task in the to-do list. The performance metric selected is the actual aggregated reward. The actual reward consists of the reward for completing a task (intrinsic reward) and the reward for completing a goal (value associated to goal). In case the deadline of a task or goal is missed, the value associated to the completion of the task or goal is not included. We define a loss ratio (lr) metric to compare the performance of the proposed algorithm with the exact solution as follows: where Rexact and R algorithm are the returns that our model of a myopic worker achieves when the to-do list is incentivized by the points computed with the exact method and our new approximate method, respectively. In Figure 3, the loss ratio has been plotted for 28 hand-crafted case studies. These case studies are designed to cover most of the scenarios possible to study the algorithm's performance. The 28 case studies are described in detail in Appendix A1. Figure 3 depicts the loss-ratio of the 28 case studies. A loss-ratio of 0 indicates that the performance of the sequence of tasks followed by using the myopic greedy strategy of the optimal gamified points computed by our proposed algorithm and the exact solution is the same. All of the 28 case studies yield a 0 loss-ratio which indicates that the calculation of the gamified points using our proposal yields the exact same performance as using the optimal gamified points. 1 3 5 7 9 11 13 15 17 19 21 23 25

Scalability of algorithm
While there is no theoretical limit for the size of the to-do list for which the proposed algorithm can solve, there is a practical limit set by the services used to run the API. The API is hosted on a Heroku server which has a practical 30 seconds time limit for the API request to be active. We compared the time required for solving a to-do list in its initial state with varying number of goals, maximum depth and the branching factor of the to-do list. The maximum depth of the to-do list is defined as the lowest level a task can be abstractized. The branching factor is the number of sub-goals a goal can be divided into. For example, the maximum depth of the to-do list illustrated in Figure 1 is 3 with a branching factor of 3. The tasks generated in the scalability assessment are all essential, require an estimated time of 1 time unit to be completed, have an intrinsic reward of 1 and and have equal importance to other tasks. While Figure 4 shows that the time required scales linearly to the increase in the number of goals, Figure 5 and Figure 6 show that the time required grows exponentially to the increase in branching factor and maximum depth. Even with such constraints, Figure 7 shows that a to-do list with a depth of 3 and branching factor of 4 is easily solvable by our proposed algorithm. Such a to-do list has a total of 576 tasks, which is more than big enough for most real-life examples. This shows that our proposed algorithm is practically useful.

API documentation
The API that we have developed can serve as a back-end to any to-do list gamification application. It is available online at https://github.com/RationalityEnhancement/todo listAPI/tree/multi smdp points. A demonstration of the API in action can be seen at https://saksham36.github.io/todolistAPI-demoWebsite/.
The communication between the gamification application and the API occurs in the following manner: 1. The gamification application sends a POST request with a specific URL to the API hosted on Heroku, which provides information about the to-do list in JSON format. Details on the format expected as input are provided in Section 5.1.

2.
After the POST request is received, the API parses the provided to-do-list information, computes task incentives, proposes a daily schedule of incentivized tasks, and sends this information back to the gamification application in JSON format. Details on the output that the API returns are provided in Section 5.2 Additionally, the API requires a MongoDB database in order to be able to store the information generated by the API. For details on each of these items, please refer to the README.md file of the repository.

API inputs
The API input consists of a POST request which consists of a Header and Body. The details of each are described in Section 5.1.1 and Section 5.1.2 respectively.
• <server> : DNS or IP address of the server.
• <compulsoryParameters> : Parameters that are independent of the incentivizing method.
• <additionalParameters> : Parameters that are related to the incentivizing method.
• <functionName> : The functionality that the API should provide.

Body
Additionally, the request must contain a body in JSON format with the following information: • currentIntentionsList : List of tasks that have already been scheduled. Each item in this list represents a scheduled task and it has to contain the following information: c : Goal code/number.
id : Unique identification code of the scheduled task.
d : Whether the scheduled task has been completed or not.
nvm : Whether the scheduled task has been marked to be completed at some other time. t : Title of the scheduled task.
vd : Value of the scheduled task.
• projects : Tree of goals and their respective tasks. Each item (goal or task) is composed of the following information: id : Unique identification code of the item.
nm : Title of the item.
lm : Time stamp of item's last modification.
cp : Time stamp of item's completion.
ch : Sub-items of the current item.
• timezoneOffsetMinutes : Time difference in minutes between user's time zone and UTC.
• today hours : Number of hours that a user would like to work on the current day (today).
• typical hours : Number of hours that a user would like to work on a typical day. m • userkey : Unique identification code of the user.
• updated : Time stamp of the last modification of the items in the projects tree.
Each to-do-list item (i.e. goal or task) title follows patterns that encode all the necessary information. The following list describes these patterns in detail: • #CG<N> <goal name> defines a goal name, where <N> is the number of the goal and <goal name> is the actual goal name specified by the user.
• ∼∼<time estimate> <time unit> defines a time estimate for a task, where <time estimate> min ∈ N corresponds to the number of minutes or <time estimate> h ∈ R >0 corresponds to the amount of hours.
• DUE:<YYYY-MM-DD> <HH:mm> defines a deadline, where <YYYY-MM-DD> defines a date according to the ISO format and <HH:mm> defines a 24-hours day time. If <HH:mm> is not provided, then 23:59 is taken as a default day-time value.
• IMPORTANCE: <importance> defines the importance for completing the task/subgoal for the completion its super-ordinate goal, where <importance> ∈ Z ≥0 .
• Intrinsic Value: <intrinsic value> defines the value for completion of the task/sub-goal is independent of its super-ordinate goal, where <intrinsic value ∈ Z ≥0 .
• Essential:: <essential> is a boolean value which is true if the task/sub-goal is essential for the completion of the task independent of its super-ordinate goal, • #HOURS TYPICAL ==<hours> defines the total number of hours per day, i.e. the amount of hours ∈ (0, 24] that a user wants to work on a typical day.
• #HOURS TODAY ==<hours> defines the total number of hours for today, i.e. the amount of hours ∈ (0, 24] that a user wants to work today.
• Scheduling tags that users can accompany to their tasks: -#daily represents a task that is repetitive on a daily basis.
-#future represents a task that has to be scheduled at some point in the future, but not at the moment. -#today represents a task that has to be scheduled today.
-#<weekday> represents a task that has to be scheduled on a specific weekday (where weekday is a day from Monday to Sunday). If this task is repetitive on a weekly basis, a plural suffix is appended to the same tag, i.e. #<weekday>s .
-#weekdays represents a repetitive task that has to be scheduled on each working day (from Monday to Friday). -#weekends represents a repetitive task that has to be scheduled during weekends (Saturday and Sunday). -#YYYY-MM-DD represents a task that has to be scheduled on a specific day according to the ISO standard (year-month-day).

API outputs
After generating incentives for each task in a to-do-list, the API selects a subset of them and it proposes an incentivized daily schedule as output. The output is a list of dictionaries in JSON format and it contains the following information for each task in the list: • id : Unique identification code of the task.
• nm : Human-readable name of the task.
• lm : Time stamp of task's last modification.
• est : Time estimate of the task.
• parentId : Unique identification code of the goal which the task belongs to.
• pcp : Whether the parent node (i.e. goal) has been completed.
• val : Generated incentive for the task.

Future Work
We consider multiple potential ways to improve the API in order to make its functionality even closer to real-world demands. Usability enhancements will include supporting tasks that contribute to multiple goals simultaneously. Additionally, decreasing the time complexity for generating solutions for larger to-do lists is of the highest priority. One possible future improvement would be to produce fast responses after making minor changes in the input information even if the changes may modify the solution. Additionally, work on getting better time estimates fot the planning-fallacy constant would enable for more precise incentivization.

A1 Case studies for comparison with exact solution
The following lists the 28 case studies used in Section 4.2. For every case study, each goal is assigned a Value which represents the value associated for completion of a goal, similarly, there is a Deadline which indicates how many time-units the user has to complete the goal. Each sub-goal has an Intrinsic Reward which denotes the reward derived of completing the sub-goal, independent of the corresponding goal. Ess is a Boolean value which is True is the sub-goal is deemed essential to complete the corresponding goal. Additionally, Imp denotes how important the sub-goal is relative to the other sub-goals. Finally, Time indicates the estimated time to complete a sub-goal.