# Our scoping tool refuses in 4 of the 7 states it can be in, and that ratio is not a tuning choice

> Source: <https://dev.to/boris_binyaminov_c5e9cec9/our-scoping-tool-refuses-in-4-of-the-7-states-it-can-be-in-and-that-ratio-is-not-a-tuning-choice-5hf8>
> Published: 2026-09-16 10:31:47+00:00

What should I build first is the most answerable-looking question in the whole process, which is why every tool answers it on the spot. Ask a chatbot and you get a feature list in twenty seconds. The list will be reasonable. It will also be a plan for building the wrong thing efficiently, if nobody has established that anyone wants the thing.

So our scoping analysis checks a precondition before it will produce anything, and in most of the states you can be in, it refuses.

The gate is not a judgement call. It reads the most recent verdict the idea already carries and maps it, and because the map covers every value the verdict enum can take plus the case where there is no verdict at all, the set of states is finite and countable: 7 of them, of which 4 refuse and 3 open.

That ratio is not a tuning choice. It is where the map's fall-through lands, and the fall-through was pointed at refusal deliberately — anything the gate does not positively recognise as validated is treated as unvalidated, so a verdict nobody has taught it about fails closed rather than quietly unlocking a build plan.

Notice which states are in the refused set. Not just the killed idea: the idea nobody has evaluated at all, which is the state every idea is in on the day you have it, and the held one, where the evidence was inconclusive. Inconclusive is not a soft yes.

What the refusal does is the part I would argue for hardest. It does NOT produce a smaller scope, a lean version, or a scope with a warning on top. The scope comes back empty with a paragraph explaining why. A tool that hedges has produced the scope, and you will build from it, because the scope is the concrete artefact and the caveat is a sentence.

When the gate does open, 6 fields are mandatory — and that list was derived rather than transcribed: each was blanked in turn and fed to the invariant that guards real output. Two of them are the ones nobody asks a chatbot for.

A condition for quitting. A scope with no stated point at which you abandon it is not a plan, it is a wish with tickets — and the useful property of that condition is that it has to be written before you are emotionally invested, which is exactly now.

And an explicit not-building list. The features you are cutting are the ones you will otherwise re-add in week three, one reasonable decision at a time. Naming them converts a hundred future arguments with yourself into one decision you already made.

The honest edge of that second guarantee, since we publish the derivation: the contract asks for more than one non-goal and the invariant only refuses an EMPTY list, so a scope with exactly one non-goal passes. The intent is stricter than the enforcement, and a page claiming a guarantee should say precisely where it stops.

Two rules the parser enforces before any invariant runs. Every must-have feature has to name the job it serves — a feature with an empty job does not parse at all, confirmed by handing the parser exactly that. It earns the strictness because name the job is the question a feature list cannot survive: features that exist because a competitor has them have nothing to write there. And the build window is bounded, with accepted values running from 1 to 4 weeks. There is no option for a scope that takes a quarter, because a first version you cannot finish inside 4 weeks is the product, and you have gone back to building on faith.

It also does not re-decide the idea: the projection is neutral, decision unknown, score a placeholder 50. A tool that let a scoping pass raise an idea's score would be laundering enthusiasm into evidence.

The gate table and both field lists: [https://whittleos.com/guides/what-to-build-first-mvp-scope](https://whittleos.com/guides/what-to-build-first-mvp-scope)
