Escalation and approvals
Where work goes when a Worker cannot or may not finish it.
When a Worker cannot or may not finish a Task, the work moves. It moves along a handoff, up to the Role that decides, into an Approval, or into a delay window.
Five ways work moves
| Situation | Mechanism | Who answers |
|---|---|---|
| The next step belongs to another Role | Delegate along a handoff | That Role's Worker |
| The call is above the Role | Escalate | The Role it escalates to |
| An Action exceeds a Limit or Mandate | Approval | The approving Role |
| A one-way decision | Delay window | Nobody; watchers may step in |
| The law reserves the act | Reserved Act | A credentialed Human |
Handoffs
Each Role declares the Roles it hands off to and the one it escalates to, so routing is data. The roster shows every path.
Delegate passes a Task along a declared handoff and keeps its history. A handoff nobody declared is refused, so work never lands on a Role that does not expect it. A receiver that cannot take the work returns it with a reason.
Escalation
Escalate moves a Task to the Role its current Role escalates to, with the reason attached. Every chain ends at the Founder, who escalates to no one.
A good escalation note says what happened, what the Worker tried and what it needs. The next Worker reads the note first and the history after.
Escalation is for calls above the Role, not for work the Role owns. A Worker facing an empty worklist, a silent peer or a failed attempt still records its next Decision: a bounded hold counts, idling does not.
Approvals
An Approval is a Task to allow or refuse one pending Action that exceeds a Limit or a Mandate. Approve runs the Action; refuse ends it refused with the reason given. An Approval unanswered by its deadline ends the Action canceled.
Each Approval waits in the approver's inbox in startups.studio and shows in Slack, Microsoft Teams and the iPhone app. Answer an approval shows each place and each answer.
The approver can also ask for a change. A comment in the Approval's Thread becomes a change request, and the Worker revises the Action and submits it again.
An Approval goes to a Role, not to a person. By default an Agent holds the Role and answers under its Conduct. A Human answers only above a threshold set per Verb.
Delay windows
A one-way decision, such as a refund, ad spend, a price change or an outbound campaign, waits out a delay window. Its decision class, reversibility times stakes in money, Customers and brand, sets the length: one business hour at medium stakes, one business day at high.
A delay window is not an Approval: when it closes, the Action proceeds. While it runs, the Action shows as a pending item in the inbox and the team stream, never as a Task. Any watcher can pause, redirect or cancel it.
Windows are Settings at any level: Studio, Portfolio or Startup. A child only tightens, so a Studio's one-day window on price changes binds every Startup beneath it.
Guards and the law
Every outbound Message and every money move passes the Guards before its window opens. Code rules run first, then model review, then adversarial review for high stakes.
No Human sits in the critical path except where the law requires one. For a Reserved Act, the Agent prepares the work, and a credentialed Human performs the act and records an Attestation.
Example
A customer of a Services-as-Software payroll firm asks for $490 back. The Customer Lead delegates the Task to the Billing Specialist, whose refund Limit is $100, so the refund opens an Approval for the Finance Lead. The Finance Lead approves under the refund rule in its contract, and the refund waits one business hour before it runs.
Next
- Mandates and limits: where the Limits come from.
- Delay windows: window lengths by decision class.
- Approval and escalate: the reference pages.