Collaboration
Member rights & permissions
Every project member has rights to read and, depending on their role, create, update, and delete the project's work. Rights come from two layers: a foundation role, and optional scoped overrides.
CRUD is shorthand for the four rights: Create, Read, Update, Delete.
1. Foundation roles
Each member has one role, which sets their default rights everywhere in the project:
| Role | Default rights over work |
|---|---|
| Owner | Full C R U D — everything. Can't be locked out by overrides. |
| Admin | Full C R U D across all loops, plus managing members & settings. |
| Manager | Full C R U D on the work in loops. |
| Member | Read only. |
Read-only means no Sandai. A read-only member (and anyone with no write rights at a scope) can browse and read, but can't use the AI coach there — the same as a beta-waitlisted user.
Moving a loop through its phases
Two controls move a loop along the LEARN path: Advance (forward to the next phase) and Step back (back to the previous phase). Stepping back never touches your work — every artefact, experiment, and learning stays exactly where it is; only the loop's current phase changes.
Every phase can be stepped back except two:
- Look & Listen — the first phase, so there's nothing behind it.
- A Next or Not? decision that's already been made — the call is locked in. A loop's Next or Not? can be reopened only while it's still undecided; once you Pivot, Persevere, or Kill, the loop is concluded. Since open items always carry forward into the fresh loop that a Pivot/Persevere starts, the way to recover from a mistaken decision is to move forward into that new loop and recreate what you need there.
Who can advance or step back depends on role:
| Role | Advance | Step back |
|---|---|---|
| Owner | Yes | Any phase (Elaborate, Adapt, Run, and an undecided Next or Not?) |
| Admin | Yes | Elaborate, Adapt, Run, and an undecided Next or Not? |
| Manager | Yes | Elaborate, Adapt, Run only — not Next or Not? |
| Member | No | No |
Reopening a Next or Not? is the weightiest step-back, so it's reserved to Owners and Admins (the same people who can end a project). A member elevated on a scope can create and edit work there, but advancing and stepping back stay with the role.
For many teams the roles alone are enough. Overrides are there when you need finer control.
2. Scoped overrides (sub-roles)
An override grants a specific set of CRUD rights to one member at one scope:
- Project — applies across the whole project.
- Loop — applies to one loop.
- Loop phase — applies to a single phase within one loop (e.g. Adapt & Agree of Loop 2).
An override is the complete set of rights at that scope — it can raise a member above their role or lower them below it.
The golden rule: most specific wins
When Sandbox checks a right, it uses the most specific override that applies, then falls back outward:
loop-phase override ▸ loop override ▸ project override ▸ foundation role
The first one that exists decides. (The Owner is the exception — always full rights.)
3. Worked examples
Elevate a member on one loop. Jordan is a Member (read-only by default). You give Jordan a Loop override on Loop 2 with Read, Create, Update. Result: Jordan can read everywhere, and create/edit anything in Loop 2 — but still read-only on Loop 1 and every other loop.
Layer a phase exception on top. Same Jordan, now also given a Loop phase override on Loop 2 · Adapt & Agree with Read, Create, Update, Delete. Result: in Loop 2 Jordan can create/edit in every phase, and additionally delete within Adapt & Agree — because the phase override is more specific than the loop override.
So Jordan effectively holds three sets of rights:
- Project: View (from the Member role)
- Loop 2: View, Create, Update (loop override)
- Loop 2 · Adapt & Agree: View, Create, Update, Delete (phase override — the ultimate rule there)
Restrict a powerful role. Sam is an Admin (full CRUD by default). You give Sam a Loop override on Loop 3 with Read only. Result: Sam keeps full rights everywhere except Loop 3, where they're read-only.
4. Assigning rights
Open a project's Members → Permissions (Admin or Owner only). Pick the member, choose the scope (project, a loop, or a loop-phase), tick the rights, and save. Existing overrides are listed there and can be cleared at any time. Every change is recorded in the Project Audit Log.
Tips:
- Leaving every box unticked blocks the member entirely at that scope (a deliberate lockout) — usually you'll at least tick Read.
- To undo an override, Remove it; the member falls back to the next, less specific level.