{"slug":"architecture/WORK_GRAPH","title":"Work Graph & Work Allocation","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/WORK_GRAPH.mdx","bytes":4434,"description":"How Work is structured, connected, and allocated across humans, AI, agents, and workflows in SpineWorkspace.","updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\nWork 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.\n\nThe fundamental product question is:\n\n> **WHO SHOULD DO WHAT, NOW?**\n\n## Work as Primary Unit\n\nFrom 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.\n\n**Work types:**\n- Tasks (assigned, unassigned, blocked)\n- Decisions (pending, decided, escalated)\n- Approvals (requested, approved, rejected, deferred)\n- Communications (inbound, outbound, pending response)\n- Reviews (code, document, financial, legal)\n- Reconciliations (payment, account, data)\n- Investigations (incident, anomaly, research)\n- Coordinations (meeting, handoff, scheduling)\n\n## Work Graph Structure\n\nWork items form a graph, not a list. Relationships between work items include:\n\n- **Dependencies** — Work B cannot start until Work A completes\n- **Sequencing** — Work should be done in order A → B → C\n- **Grouping** — Work items belong to a larger initiative\n- **Blocking** — Work A is blocked by Work B\n- **Related** — Work A and Work B are contextually connected\n\n```text\nINITIATIVE\n    ├── TASK A (in progress)\n    │       ├── DEPENDENCY: TASK B (completed)\n    │       └── RELATED: DECISION C (pending)\n    ├── TASK D (blocked by TASK A)\n    └── APPROVAL E (waiting for TASK A output)\n```\n\n## Work Allocation\n\nWork allocation determines who should do what. The allocation is based on:\n\n| Factor | Description |\n|--------|-------------|\n| **Capability** | Can this actor perform this work? |\n| **Responsibility** | Is this actor responsible for this type of work? |\n| **Authority** | Does this actor have authority to make this decision? |\n| **Risk** | What is the risk of this actor doing this work? |\n| **Context** | Does this actor have the context to do this well? |\n| **Complexity** | Is this work too complex for this actor? |\n| **Urgency** | How quickly does this work need to be done? |\n| **Availability** | Is this actor available right now? |\n| **Policy** | Does policy allow this allocation? |\n| **Cost** | What is the cost of this allocation? |\n| **Need** | What does the business need right now? |\n\n**Optimization target:** Correct work allocation and verified business outcomes — not maximum automation.\n\n## Self-Organizing Boundaries\n\nWork allocation follows self-organizing boundaries:\n\n| Boundary | Rule |\n|----------|------|\n| **Personal + Reversible** | Twin may auto-allocate (e.g., reschedule a personal meeting) |\n| **Personal + Consequential** | Twin proposes, human decides (e.g., send email to customer) |\n| **Shared + Low-risk** | Twin may auto-allocate with notification (e.g., update shared doc) |\n| **Shared + Consequential** | Governance required (e.g., approve invoice, modify contract) |\n| **Cross-tenant** | Always governance required |\n\n## Work Lifecycle\n\n```text\nCAPTURED → TRIAGED → ALLOCATED → IN_PROGRESS → REVIEW → COMPLETED → RECONCILED\n    ↓          ↓          ↓            ↓           ↓          ↓            ↓\n  Signal    Classify   Assign      Execute     Verify     Finish      Update Spine\n```\n\nEach state transition is recorded in the Spine as a timeline event with provenance.\n\n## Work and Business Context\n\nWork does not exist in isolation. Every work item is connected to:\n\n- **Entities** — the business objects this work concerns\n- **People** — the humans and AI involved\n- **History** — what happened before\n- **Evidence** — what supports decisions\n- **Outcomes** — what happened after\n- **Memory** — what was learned\n\nThis connection is what makes Work contextual rather than mechanical.\n\n## Related\n\n- [Spine Schema](/architecture/SPINE_SCHEMA) — Work data model\n- [Workbench Canonical Model](/architecture/WORKBENCH_CANONICAL_MODEL) — how Work appears to users\n- [Twin](/architecture/TWIN) — how Twin participates in Work allocation\n- [Governance](/architecture/GOVERNANCE) — how Work allocation is governed\n"}