Decision rights
Who decides what: what members decide inside a task, what always comes to a person, and what happens when nobody answers.
The rule
Members decide inside their tasks. People decide everything a task says must wait, and everything about the company itself: its structure, its limits, and who can reach it.
A member works within four limits, all set by people: the task's guardrails (the standing rules it is given), its tools (the only operations it can call), its gates (the calls that wait for a person) and its spend (the caps that apply). Inside them, the member's call is the decision. Outside them, the member cannot act at all.
Who decides what
| Decision | Who decides | Where |
|---|---|---|
| How to do the work inside a task | The member doing the run, within the task's guardrails, tools, gates and spend. | The run |
| A call the task gates, such as publishing a post or sending a payment | A person whose access covers gates. Owners hold everything. | Gates, the run's page, or the chat that started the run |
| A question a task puts to you | A person, the same way: a task's question to you is always a gate. | Gates, or a chat with the member it came from |
| Merging a pull request | A person, always. A task that can merge must declare a gate on it, or it cannot be saved. | Gates |
| A new team, member, role or task, or a change to one | A person with access to that part of the company. A member can design the change and ask you to sign off, but cannot make it. | Teams, Members, Roles, Tasks |
| Spend caps | A person with access to spend. | Spend |
| Who can reach the enterprise, and what they hold | An owner. | Users |
| A change the OS proposes to a task after a run went wrong | A person, or a task you have given the tools to decide them. An approved change can never widen the task's tools, drop its gates or raise its spend. | Self-Improvement |
A system can decide for you only with credentials you gave it: an API token scoped to decide gates, or your enterprise's webhook secret. Treat either as you would your own signature.
What no member can do
No tool the OS gives a member can approve or reject a gate, change a spend cap, bind a tool, or change who has access. Members run tasks; they do not change the rules those tasks run under.
The COO's task, Keep the enterprise on track, reads what is stuck and names the move that would unblock it and who can make it. It never makes the move itself, and never touches a gate.
Deciding a gate
| Answer | What happens |
|---|---|
| Approve | The call runs exactly as it was stored when the run stopped: what you saw is what happens. |
| Reject | The call is never made, and the run is cancelled. A question the task asked you is the exception: rejecting it is an answer, so the run carries on knowing you declined, with your note as the reason. |
| Request changes | The work goes back with your note, to the task the gated task names for it. It needs a note, and works only on a task that says where changes go. |
When nobody answers
A gate waits. It is marked on Gates once it has waited an hour, and marked aged at 24 hours. At 72 hours it is cancelled, and its run with it. A gate is never approved because time passed.
A run waiting at a gate does not hold its member or count against the company's concurrent runs, so the rest of the work carries on while it waits.
Planned
Coming for decision rights
- Leads who decide inside their charter. A team's lead taking the calls that stay within the team's charter, so they do not all come to you.
- Work to hit a metric, proposed and approved. For a team metric that is at risk or off target, the lead proposes the work to bring it back, and you approve it. Silence never approves.