Scoping with Non-Goals

Eidos gives exactly one section this status. It’s worth understanding why, because the section is also the easiest one to leave empty.

Why non-goals do the work

A list of what something does is unbounded. There’s always another behavior you could add, and nothing in the list tells you where to stop. Two people can read the same set of acceptance criteria and disagree about whether a feature is in scope, because the criteria say nothing about the boundary.

A list of what something won’t do is a decision. It has an author, a date, and a diff. It can be pointed at in a review. It answers the question that actually costs money six months later: “wait, doesn’t it handle X?”

Consider the example spec’s non-goal:

## Out of Scope

- Cross-account resume. A shared TV is one device, not one person.

That single line does three things no behavior list can. It prevents a plausible feature request from being treated as a bug. It records the reasoning, so the next person can tell whether the reasoning still holds. And it ends an argument before it happens, in writing, with an owner attached.

Write it second

The instinct is to write non-goals last, once the blueprint is otherwise complete. That’s backwards, and it produces empty sections.

Write it immediately after the opening section:

Intent — why this exists, and who has the problem.
Out of Scope — what it deliberately won’t do.
Everything else.

The reason is that non-goals are hardest to see once you’ve written the behaviors. By then you’ve been thinking in terms of what the thing does, and the boundary has gone invisible. Write it while the shape of the problem is still in view.

What belongs in it

Adjacent features you deliberately dropped, with the reason.
Cases you’ve decided not to handle — a class of user, a device, a locale.
Things a reasonable reader would assume are included. These are the valuable ones.
Boundaries with other blueprints, ideally as a link: “Ranking is Search Results’s problem, not this one.”

What doesn’t

“Not in v1.” That’s a schedule, not a scope decision — and it’s work tracking, which rots. If it’s genuinely out, say so and why. If it’s genuinely later, it belongs in a Roadmap top-level doc.

“Nice to have.” Either it’s promised or it isn’t. Non-goals are for the isn’t.

Things nobody would ever assume. A list of a hundred non-goals reads like nervousness and hides the three that matter.

Still not a hard gate

The convention ends with a qualification that matters: still not a hard gate.

A blueprint with an empty non-goals section is surfaced, flagged first among the missing sections, and offered — not refused. That’s portability over prescription applying to the section the standard cares most about. Eidos notices; it doesn’t block your commit.

Which is the right design. A validator that refuses files gets bypassed, and a bypassed validator flags nothing.

Where a lighter flavor keeps it

Look at what the smallest flavor in the software seed retains:

`spec.micro` keeps	`spec.micro` drops
Intent	Implementation Notes
Assumptions	The AC sub-categories
Open Questions	Dependencies
Behaviors & Acceptance Criteria	Testing
Out of Scope	Constraints & Decisions

Testing and Dependencies can wait until the unit firms up. Scope cannot — so micro carries Out of Scope at its very smallest. When you design your own light flavor, keep the same rule: the non-goals section is never the one you trim.

When it’s someone’s job to say no

Non-goals are where the Framework Owner role stops being organisational and starts being load-bearing. Adding a behavior is a decision anyone can advocate for; removing one from scope requires authority.

A root with no clear owner will accumulate behaviors and lose non-goals, because nobody feels entitled to write the second kind. That’s the failure mode to watch for, and it shows up in the diff before it shows up in the product.

Shaping Your Framework
Roles & the Actor — who gets to decide.