First, you will need to record what a task is in service to, its project or parent, but not for the reason other systems let you. In a retrieval-based app, location is the lookup key. You file a task so you can find it later. File a task in the wrong place and it’s functionally lost forever, so placement is do-or-die and can lead to a lot of frustration. With the new system you’re building now, location does something different. A task sits under a parent to help understand how important the task is, and that inherited impact is only one ingredient in the final blend. Which means close-enough is good-enough. Drop a task under roughly the right parent, or a sibling project, and its calculated prioritization score lands close to correct, near enough that it still surfaces at about the same time. Misplacement costs you a small nudge in the ranking, not a task forever lost in a sea of folders. There’s no perfect folder to find. “Select paint color” might belong to a bathroom remodel project. “Follow up with Sarah” belongs to the project for your kid’s birthday.

The method we’re building groups tasks up to two levels deep. Every task gets a project, the thing it’s part of. Each project, in turn, can belong to a domain, a broad sphere of your life that several projects sit inside. My own domains are Work, Personal, and Side Gig, but those are just mine. You might use School, or Household, or none at all. The key thing: you never group a task directly in domain. You group the project within its domain, and every task in that project inherits it. If you have genuinely separate spheres that should carry different weight, domains earn their place. If everything you do is really just “your projects,” skip the domain layer entirely. The project is required; domain is optional; that’s the whole structure. The value in the grouping is also that it helps narrow the decision making. If you use domains, you don’t have to ask yourself if your vacation project is more or less important than the project at work since they don’t exist in the same space.

Two levels is a deliberate ceiling. You could nest forever, projects inside projects inside projects, and in fact some software do exactly that and that is great when the application does the ranking. But when running the process by hand, depth is a maintenance nightmare. Two grouping levels capture the overwhelming majority of the ranking value with the least amount of effort.

Also, a quick side note. While I have been calling them projects, and will continue to, they really are one of two kinds of buckets. A project is finite. It has a finish line. “Remodel the bathroom” ends; the day the last task under it is done, the project is over and can leave your list. On the other hand, some may be a portfolio which is standing. It never finishes; it’s a bucket that holds tasks of a kind and keeps living even when it’s empty, waiting for the next one. “Home chores” is a portfolio, you’ll never be done with chores around the home, but you’ll always want a place to put the next leaky faucet. The distinction matters because it tells you what “done” means: a project gets retired when it’s complete; a portfolio just persists.

One portfolio worth creating is an “odds and ends” bucket for the small stuff that doesn’t fit neatly under any project you have. “Return the library books,” “fix the wobbly chair”, depending on your setup, these might not belong to any project you’re tracking, and inventing one for each would be more overhead than it’s worth. Drop them in “odds and ends” and they still get ranked and surfaced like everything else, just without the ceremony. It’s a portfolio, not a project, because you’ll never be “done” with life’s miscellaneous tasks, there’s always another one coming. If you use domains, create one odds-and-ends portfolio per domain, a “Personal” catch-all, a “Work” catch-all, so the loose tasks still inherit roughly the right weight. If you don’t use domains, a single odds-and-ends portfolio does the job.

Grouping your tasks earns its place by doing three jobs.

First, it lets you filter. Because every task carries a project, and every project a domain, with most digital systems, including apps and the companion spreadsheet you can download in 4.3, you can hide or show whole swaths of tasks at will. Don’t want to see anything in the Work domain on a Saturday? Grouping is what makes that possible. (More on this in Part 5)

Second, in the system we are building, it gives a task inherited weight. The grouping itself has importance, and that importance flows down to the tasks inside it. If “remodel the bathroom” matters more to you than “organize the garage,” then all else equal, a task from the remodel outranks a task from the garage, not because you ranked those two tasks against each other, but because they sit in projects you’ve prioritized differently. The domain does the same thing one level up: a Work project can carry more baseline weight than a Personal one, if that’s how your life actually works. You rank the groupings once, and every task inside inherits the result. TaskBeacon calls this a task’s parent impact.

Third, and this is the one that really saves you, grouping shrinks the question you have to answer when you rank a task. It narrows the decision making. If you use domains, you don’t have to ask yourself if your vacation project is more or less important than the project at work since they don’t exist in the same space. Which brings us to the second ranking facet.