Admin Operator Separation
Admin and operator roles operate in different parts of the system. They do not share authority and do not overlap in the same lifecycle stage.
What admin controls
Admin governs the network:
- Operator approval and activation — who is allowed to use the system
- Access state — whether an operator is active, limited, or suspended
- Network-level tasks — reviewing and assigning requests that come through network-managed funnels
- Surface management — which services and surfaces are available and to whom
- Invitations and onboarding — controlling who enters the system
- System health — monitoring queues, exceptions, and stuck work
Admin acts before execution begins. Admin does not execute service work.
Where admin acts in the lifecycle
Request → Intake → [Task: admin reviews] → Create JobAdmin is involved at the Task stage for network-managed requests and explicitly creates the Job when the task is approved and assigned. Admin can view records and signals after execution but does not produce them.
What operator controls
Operators govern their own work:
- Their own incoming requests — reviewing tasks from their own funnel
- Assigning work within their account — approving and assigning their own tasks
- Executing jobs — claiming queued jobs and doing the actual work
- Capturing evidence — photos, notes, completion details
- Completing service events — marking work done and producing records
Operators act from the Job stage onward. For operator-owned funnels, they also govern the Task stage for their own incoming requests.
Where operators act in the lifecycle
Job → [ServiceEvent: operator executes] → Record → ⭐ SignalSide-by-side comparison
| Admin | Operator | |
|---|---|---|
| Approves operators | Yes | No |
| Sets access state | Yes | No |
| Reviews network tasks | Yes | No |
| Reviews own requests | No | Yes (own funnel) |
| Creates jobs | Yes (for network tasks) | Yes (for own tasks) |
| Executes jobs | No | Yes |
| Captures evidence | No | Yes |
| Produces records | No | Yes (via execution) |
| Sees trust signals | Yes (advisory) | Yes (own signals, advisory) |
The key rule
An operator cannot act on another operator’s tasks or jobs. Ownership is enforced at the server level. A task created from operator A’s funnel belongs to operator A. Operator B cannot approve, assign, or execute it.
An admin does not execute service work. Admin governs who can work and under what conditions. The actual work — the ServiceEvent, the evidence, the completion — is always done by an operator.
Who can see what
Both admin and operators can see trust signals, but only in an advisory capacity. Neither can create or modify a trust signal — it is always system-emitted.
Admin can see all operators’ signals across the network. An operator sees their own signals in their Desk.
Guardrails
- Preserve the distinction between planned, partial, and live.
- Avoid marketing language.
- Keep IDs, namespaces, and lifecycle terms precise.
- Admin governs; operators execute. These zones do not collapse.