Choose the right operating scope

Guild Stack uses four nouns to keep scope and evidence clear:

workspace -> project -> optional initiative -> run

The project is the default unit of work. A run is one bounded execution that leaves evidence. An initiative is optional coordination for a goal that needs multiple runs. A workspace relates projects without merging their local state.

Scope · ownership

map / active

Project inputs become run evidence

W · Workspace

cross-project wiki child relationships query projects

P · Project

default work unit spec · team · plan approved inputs

I · Optional

attach by choice coordinate runs close gate

R · Run

reference inputs tasks · handoffs · review evidence packet

Choose the smallest useful scope

If the work is…	Use	Why
One bounded change in one repository	A project run	The project owns the approved spec, team, and plan; the run references those inputs and records execution evidence.
A goal with dependencies across several runs	An initiative	Progress and close gates survive individual sessions.
A coordinated change across related repositories	A workspace plus project-local runs	Federation shares relationships and cross-cutting knowledge while each project keeps ownership.
A durable fact about one project	Project wiki	The fact stays next to the project that owns it.
A durable fact that applies to several projects	Workspace wiki	The workspace provides the conflict-winning cross-project truth.

Do not create an initiative for every task. The extra ledger is valuable only when the goal needs durable work items, dependency gates, or progress across sessions.

State ownership

Guild Stack state is file-backed so scope remains inspectable after chat disappears.

Level	Owns	Does not own
Workspace	Child relationships, cross-project knowledge, shared coordination facts	Copies of project-local wiki or run state
Project	Local configuration, wiki, skills, agents, approved specs, teams, plans, initiatives, and runs	Another project’s private state
Initiative	Goal, work items, dependencies, progress, evidence links, and close decision	The implementation artifacts themselves
Run	References to approved project inputs, context, task state, handoffs, review, verification, trace, and provenance	Project-scoped spec, team, and plan artifacts; unbounded future work

The boundary prevents a common failure: running from the wrong directory and silently writing project state into the workspace, or workspace state into a child repository. Use absolute roots when automation crosses repositories.

A run is the evidence unit

A run is not a chat transcript. It is the durable packet that answers:

1. What outcome was requested?
2. Which constraints and success criteria were approved?
3. Which approved project team and plan did the run reference?
4. What changed?
5. What tests and review challenged the result?
6. What evidence proves completion?
7. Which followups remain, and where do they live?

That packet is what allows another person or host to resume, audit, or replay the work.

Initiatives coordinate; they do not replace runs

An initiative links several bounded runs to a durable goal. Each run still owns its execution evidence. The initiative owns progress across those runs and cannot close until its work items, verification, and documentation gates are satisfied.

Use an initiative when at least one of these is true:

• The goal spans multiple sessions or repositories.
• Work has explicit dependencies or ordered gates.
• Progress must be measurable independently of a chat session.
• Completion requires several forms of evidence or a rollout sequence.

Workspace federation is query, not copy

A workspace may discover child projects, understand their relationships, and query their knowledge. It does not replicate child wiki pages into a central store. Project-local truth stays local; cross-cutting truth is promoted through an explicit human gate.

This makes the model predictable:

• Read a project at its project root.
• Write project state at its project root.
• Put cross-project decisions at the workspace root.
• Link runs to initiatives; do not bury initiative progress in run prose.

See also

• Workspaces & Monorepo Federation for discovery, precedence, and promotion.
• Initiatives for durable multi-run goals and close gates.
• How Guild Stack Works for the six-phase run lifecycle.
• Quality & Operations for general run verification and the separate release-readiness decision.