This is not necessarily true. The natural planning model (NPM) applies the Horizons of focus to a specific project, so Purpose and principles can apply to projects.
It looks like this:
Purpose - why do the project at all?
principles - what constraints/rules of engagement to follow?
vision/outcome - what does "done" look like?
Brainstorm - mind sweep on how to get this thing done
Organize - turn that mind sweep into logical components, order, and milestones
Next actions - what do you need to do next to get started?
So I would consider a budget for a project with principles. But it is definitely separate from the outcome.
The NPM is particularly useful in clarifying and planning large and group projects.
Remember, GTD is not rules, just best practices. There isn't a "right way" to plan a project in GTD, but there are tools in GTD to help you plan projects. So don't feel like you have to apply the NPM to every project.
The rule of thumb is - what has your attention? If you need some clarity on the direction of a project, use the NPM to flesh out the purpose and principles. If you know why you're doing the project but aren't sure where to begin, use the lower horizons to generate ideas on how to move toward action.
Fair points, and I stand corrected on the use of the terminology in NPM.
I just popped into the GTD book to double-check whether I was thinking through things correctly, and I ran across this as a short summary in the NPM disucssion:
“Choose one project that is new or stuck or that could simply use some improvement. Think of your purpose. Think of what a successful outcome would look like: where would you be physically, financially, in terms of reputation, or whatever? Brainstorm potential steps. Organize your ideas. Decide on the next actions. Are you any clearer about where you want to go and how to get there?”
I think this summarizes the way I approach projects like this just about perfectly. For the curtain, "outcome" could be "a curtain installed that covers the dirty wall and keeps the sun off my computer". Project-level principles and purposes are baked in at that point, and the brain is almost certainly providing them naturally.
I think that's what I was trying to get at with OP - I find a lot of these things coalesce in practice, especially with projects the size of installing a window curtain. This why you don't inherently do something like NPM top-down for a project. Very particularly, you don't have to do "purpose" and then come up with something different *under* purpose that's "principles", then something different under that that's "vision", then something different under that that's "outcome". Trying to do that for every project - especially small projects - will drive you crazy. And it will lead to forum posts about how GTD makes things take too long.
A good, clearly-defined outcome will almost certainly encompass those things. At the point you have that, the stuff above it is superfluous.
And as
@mcogilvie brought up, this isn't top-down - it's more iterative, so the things you find out in your research (a "next action") might change principles, vision, etc. as the Real World gets a vote sometimes.
As you mentioned, these aren't rules, but rather tools. Per David Allen, "If greater clarity is what you need, shift your thinking up the natural planning scale. ... If more action is what’s needed, you need to move down the model.”
