Work Graph & Work Allocation
How Work is structured, connected, and allocated across humans, AI, agents, and workflows in SpineWorkspace.
Work is the primary unit of SpineWorkspace. Every piece of business Work must be capable of being allocated among Human, Twin, Coworker, Domain Agent, Specialist Agent, Workflow, System, or Human + AI.
The fundamental product question is:
WHO SHOULD DO WHAT, NOW?
Work as Primary Unit
From the canonical ontology, Work represents any business activity that requires attention, decision, or execution. Work is not limited to tasks — it includes decisions, communications, reviews, approvals, reconciliations, and any other business activity.
Work types:
- Tasks (assigned, unassigned, blocked)
- Decisions (pending, decided, escalated)
- Approvals (requested, approved, rejected, deferred)
- Communications (inbound, outbound, pending response)
- Reviews (code, document, financial, legal)
- Reconciliations (payment, account, data)
- Investigations (incident, anomaly, research)
- Coordinations (meeting, handoff, scheduling)
Work Graph Structure
Work items form a graph, not a list. Relationships between work items include:
- Dependencies — Work B cannot start until Work A completes
- Sequencing — Work should be done in order A → B → C
- Grouping — Work items belong to a larger initiative
- Blocking — Work A is blocked by Work B
- Related — Work A and Work B are contextually connected
INITIATIVE
├── TASK A (in progress)
│ ├── DEPENDENCY: TASK B (completed)
│ └── RELATED: DECISION C (pending)
├── TASK D (blocked by TASK A)
└── APPROVAL E (waiting for TASK A output)
Work Allocation
Work allocation determines who should do what. The allocation is based on:
| Factor | Description |
|---|---|
| Capability | Can this actor perform this work? |
| Responsibility | Is this actor responsible for this type of work? |
| Authority | Does this actor have authority to make this decision? |
| Risk | What is the risk of this actor doing this work? |
| Context | Does this actor have the context to do this well? |
| Complexity | Is this work too complex for this actor? |
| Urgency | How quickly does this work need to be done? |
| Availability | Is this actor available right now? |
| Policy | Does policy allow this allocation? |
| Cost | What is the cost of this allocation? |
| Need | What does the business need right now? |
Optimization target: Correct work allocation and verified business outcomes — not maximum automation.
Self-Organizing Boundaries
Work allocation follows self-organizing boundaries:
| Boundary | Rule |
|---|---|
| Personal + Reversible | Twin may auto-allocate (e.g., reschedule a personal meeting) |
| Personal + Consequential | Twin proposes, human decides (e.g., send email to customer) |
| Shared + Low-risk | Twin may auto-allocate with notification (e.g., update shared doc) |
| Shared + Consequential | Governance required (e.g., approve invoice, modify contract) |
| Cross-tenant | Always governance required |
Work Lifecycle
CAPTURED → TRIAGED → ALLOCATED → IN_PROGRESS → REVIEW → COMPLETED → RECONCILED
↓ ↓ ↓ ↓ ↓ ↓ ↓
Signal Classify Assign Execute Verify Finish Update Spine
Each state transition is recorded in the Spine as a timeline event with provenance.
Work and Business Context
Work does not exist in isolation. Every work item is connected to:
- Entities — the business objects this work concerns
- People — the humans and AI involved
- History — what happened before
- Evidence — what supports decisions
- Outcomes — what happened after
- Memory — what was learned
This connection is what makes Work contextual rather than mechanical.
Related
- Spine Schema — Work data model
- Workbench Canonical Model — how Work appears to users
- Twin — how Twin participates in Work allocation
- Governance — how Work allocation is governed