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
                 │
                 ├─ Will there be multiple parallel Flows for this goal?
                 │    ├─ Yes → Create a new Project + first Flow
                 │    └─ No  → Create a new standalone Flow in Area

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 Project inside an Area you already have?

"Learn Spanish" is not a new Area. It's probably a Project 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 Project 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 Project.

---

Placing into Projects

Use a Project when multiple Flows share the same goal. The Project is the grouping, not the work itself.

When placing an Action:

1. Is there already a Project for this goal?
2. If yes, does the Action belong to an existing Flow inside that Project?
3. If the Flow doesn't exist yet, create it.

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."

Creating a new Project: Only when you have (or expect) multiple Flows under a common goal. Don't create Projects preemptively "just in case." Let them emerge when the second Flow appears.

Creating a new Area: Only when there's genuinely a new domain of ongoing responsibility. Most apparent "new Areas" are actually Projects 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 a Project → Flow → Area chain. It's correctly placed for what it is.

Over-structuring is a real failure mode: creating Projects for single Flows, creating Flows for single Actions, 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.