Build scope is the most consequential control in the product. It decides how far one request is allowed to reach.
It is chosen per task, in the composer, at the moment you send. Your last choice sticks for the next task. It is never a directory-wide setting — the same workspace should be able to ask a quick question and commission a full build.
The three scopes
Only this — just your request
Answers what you asked and stops. No organisation-model stages, no connected work, no reconciliation with anything else.
A cap applies to how many artefacts one task may produce, so you get the answer rather than a project around it.
Use it for: a question with a knowable answer. Checking a number. A first look at something.
Connected — your request plus the work it triggers
Answers the request, then follows the work it implies. Ask about competitor positioning and you also get the pricing and channel consequences, because those are connected.
This is the scope most real work wants.
Use it for: anything where the implications matter as much as the answer.
Entire system — the whole organisation model, every run
Runs the same stages as Connected. The difference is not which stages run but how much each is made to produce: Connected follows the work your request actually triggers, while Entire system materialises every stage of the organisation model whether the request touched it or not.
It is the slowest and most expensive option, and it is the right one less often than people expect.
Use it for: a genuine reset. Quarterly planning. After a strategy change.
For the exact stage-by-stage matrix, see what runs at each build scope.
Choosing
If a task returned more than you wanted, you were probably on a wider scope than you needed. If it returned something thin and disconnected, the reverse.
Cost
Wider scope means more work, which means more credits. See Usage and credits.
Next
- Build scope — the concept
- Choice variables and variants