Organize

Stage 3: Place each processed Action into the structure.

What organizing means

After you've decided an item is actionable and who handles it, you place it. That's organizing.

Organizing is not the same as processing. Processing decides what something is. Organizing decides where it lives.

The answer to "where does this go?" follows a short decision path.

The decision path

Does this belong to an existing Area?
  ├─ No  → Create an Area first, then continue
  └─ Yes
       │
       ├─ Is this a one-off Action with no sequence?
       │    └─ Yes → Add directly to Area
       │
       └─ No — it's part of a sequence
            │
            ├─ Belongs to an existing Flow?
            │    └─ Yes → Add to that Flow
            │
            └─ No — needs a new Flow
                 │
                 └─ Create a new Flow in the Area
                    (if another Flow already serves the same larger goal,
                     group them with a shared `[[keyword]]` prefix)

Most of the time, the path is short. You have an action. You know it's Career. You know it's part of the job search flow. You add it to the right Flow. Done.

The longer paths appear when the work is genuinely new: a new goal, a new responsibility, a new area of your life.

Placing into Areas

If you don't have an Area that fits, you might need to create one. But first, pause and check: is this actually a new Area of responsibility, or is it a Flow (or cluster of Flows) inside an Area you already have?

"Learn Spanish" is not a new Area. It's probably a Flow inside "Learning" or "Personal Development."

"Freelance work" might be a new Area if you're starting to take on freelance clients — it's an ongoing domain of responsibility that persists. Or it might be a Flow inside "Career" if it's a one-time engagement.

The test: does this ongoing domain of responsibility persist indefinitely, or does it have a finish line? If it persists, it might be an Area. If it ends, it's a Flow (or several Flows grouped under a [[keyword]]).

When multiple parallel Flows serve one larger goal, group them with a [[keyword]] prefix. There's no higher container — just a shared name.

Area: Side Projects
  ├─ Flow: [[App launch]] Build MVP
  └─ Flow: [[App launch]] Launch marketing

When placing an Action:

Is there already a Flow for this goal?
If yes, add to that Flow.
If not, create a new Flow and apply the shared prefix.

Sometimes you'll add a single Action and realize it's actually the start of a new Flow. That's fine — let the structure emerge from actual work, not from pre-planned scaffolding.

Placing into Flows

This is where most Actions land. The Flow has a sequence. You're adding to it.

Adding at the end: The natural place for most new Actions. If you're building out a sequence step by step, each new Action goes at the end as the next step.
Adding in the middle: Sometimes you realize a step is missing between two existing Actions. Insert it. The Flow handles the resequencing automatically.
Breaking an existing Action: If an Action has grown too large for one day, break it at the point it currently lives. Replace it with two or three smaller Actions in sequence.

Creating new structure

Sometimes a processed item doesn't fit anywhere existing. That's normal — especially during a first-time setup or when your life is changing.

Creating a new Flow: Give it a name that describes the outcome, not the activity. "Land new client" is clearer than "client work." "Ship v2 feature" is clearer than "development."
Grouping Flows with a [[keyword]] prefix: Only when a second Flow emerges for the same common goal. Don't pre-group "just in case." The prefix earns its keep only when two Flows actually share a goal.
Creating a new Area: Only when there's genuinely a new domain of ongoing responsibility. Most apparent "new Areas" are actually Flows inside existing Areas.

The minimal structure principle

Use as little structure as the work requires. Not more.

A standalone Action living directly under an Area is not less organized than an Action in an Area → Flow → Action chain. It's correctly placed for what it is.

Over-structuring is a real failure mode: creating Flows for single Actions, adding [[keyword]] prefixes where no grouping exists, nesting things one level deeper than they need to be. This adds organizational overhead without adding clarity — and it makes the system feel heavier than it should.

When in doubt, go simpler. Add structure when you have multiple related things that need grouping. Not before.

Organizing is the quietest stage

Unlike Capture (the urgency of getting things out) and Execute (the satisfaction of getting things done), Organize is unglamorous. It's filing. It's placement. It's maintenance.

But it's what keeps the system coherent. An un-organized system accumulates items with no home, which accumulate into Inbox backlog, which accumulate into anxiety.

The goal is: every item processed has a home. When it has a home, it surfaces at the right time. When it surfaces at the right time, Today is trustworthy. When Today is trustworthy, the whole system works.

Organize ​

What organizing means ​

The decision path ​

Placing into Areas ​

When multiple Flows share a goal ​

Placing into Flows ​

Creating new structure ​

The minimal structure principle ​

Organizing is the quietest stage ​