Governance Rules
These are the invariant rules that govern how requests are routed, reviewed, and approved before execution begins.
Rule 1: Funnel determines routing
When a request enters the system, it routes to the correct governance layer based on the funnel it came from. This routing is set at intake submission and does not change.
Operator-owned funnel → Task goes to operator governance
Network-managed funnel → Task goes to admin governanceRouting origin is not assignment. A task routed to an operator-owned governance queue has not been assigned until an explicit assignment action occurs.
Rule 2: Create Job is the governance boundary
The Create Job action is the explicit boundary between governance and execution. It is a deliberate, one-way action and cannot happen automatically.
Task (governance) → [Create Job] → Job (execution)- Before Create Job: work is in review; the operator’s desk shows nothing; no execution can happen.
- After Create Job: work is queued; the operator’s desk shows the job; execution can begin.
This boundary exists to prevent work from entering execution without deliberate approval and assignment.
Rule 3: Access state gates execution
Every operator has an access state that the admin layer sets. Access state and authentication are separate concepts — being logged in does not mean full access.
| State | Meaning |
|---|---|
active | Full access to workspace and desk |
limited | Restricted access — some features unavailable |
suspended | Blocked from protected routes |
pending_activation | Approved but not yet activated |
pending_review | Application exists, no entitlement yet |
A suspended or limited operator cannot proceed to execution regardless of authentication state.
Rule 4: Operator ownership is server-enforced
A task created from operator A’s funnel belongs to operator A. Operator B cannot approve, assign, claim, or execute it. This is enforced at the server level, not the UI level.
Rule 5: Governance does not produce execution truth
Records and trust signals come from execution. The governance layer controls whether and by whom work can be done — it does not produce the execution truth itself.
Governance zone: Request → Intake → Task → [Create Job]
Execution zone: Job → ServiceEvent → Record → ⭐ SignalThese zones are separated by the Create Job action.
Guardrails
- Preserve routing ≠ assignment.
- Preserve governance zone ≠ execution zone.
- Preserve access state ≠ authentication.
- Preserve explicit Create Job handoff where the handoff is required.
- Do not allow automatic job creation from task approval.