> ## Documentation Index > Fetch the complete documentation index at: https://docs.integratewise.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workbench Canonical Model # SpineWorkspace Workbench — Canonical Model The dictated target model for the adaptive (Spine) Workbench: one surface where context is assembled and gathered for the user, organized by four canonical sidebar sections, powered by the Spine schema, projected per role/domain, and worked by Human + Twin + Coworker together. Evidence labels follow `_reference_ARCHITECTURE_v3.1.md`: **LAW**, **VERIFIED**, **INTENDED**, **DRIFT**. *** ## 1. The One-Surface Law > The Workbench is ONE surface. There are no layers, modes, or alternate UIs. > L-labels never appear in user-facing UI. **LAW.** Reaffirmed from ARCHITECTURE\_LOCK §V and v3.1 Projection Law. ## 2. Left Sidebar — Four Canonical Sections | # | Section | Contents | Purpose | | - | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- | | 1 | **Today** | Personal/day view — what needs to be taken care of today | Daily orientation; the entry point of the User Path | | 2 | **Communications** | Teams-style messaging: email, chat, calls, meetings, shared documents | Human↔human continuity inside the same surface | | 3 | **Organization Memory** | Organizational calls, decisions, and documentation for the work and the work environment — a Notion-like knowledge workspace over org memory | Shared institutional knowledge; reads governed org memory | | 4 | **Work** | Complete business-context views — role/domain projections of Spine data | The operational surfaces where work is done | ### Current implementation vs model | Section | Status | Where | | ------------------- | ------------------ | ---------------------------------------------------------------------------------------------------------------- | | Today | **VERIFIED** | `home` + `personal` nav groups (`packages/workbench-config/src/generated/navigation.ts`) | | Communications | **VERIFIED** | `communications` group — Email, Calendar, Meetings, Chat, Calls, Documents, Activity | | Organization Memory | **INTENDED — GAP** | Only personal-scope Knowledge Base/Notes exist under `personal`; an org-scoped Memory section does not yet exist | | Work | **VERIFIED** | `my-work` group, re-keyed per role via `resolveWorkNavigationForRole` | ## 3. Spine Schema Generator **INTENDED.** The Spine schema is generated for organizational needs from the **organizational lifecycle of events** — not hand-authored per customer. The generator derives entity types, relationships, event types, and memory scopes from how the organization actually operates. ``` Organizational lifecycle events ↓ SPINE SCHEMA GENERATOR ↓ Canonical schema (entities · relations · events · memory scopes) ↓ Per-role / per-domain PROJECTIONS ``` * Schema generation is a System Path concern. Users never see or configure raw schemas. * Generated schema feeds both the Workbench projections and the AI Operational Sandbox assembly. * Alignment: v3.1 Store ownership (canonical vs operational) and Loader Runtime ingestion. ## 4. Projections — Same Data, Per-Role Views **LAW (Projection Law).** Every user sees the SAME organizational data through their OWN view, scoped by RBAC, role, and domain. * A projection is a view of shared truth — never a new source of truth. * Cross-team and cross-domain collaboration happens by sharing knowledge ON the Spine — not by copying data between teams. * 15 external domain workbenches + 3 internal surfaces already encode this: `packages/workbench-config/src/domain-workbenches.ts` (**VERIFIED**). * AI enables the work on these projections: workflows, agents, intelligence operate against the projection scope, promoting proposals through governance when they must become canonical. ## 5. Twin — The User's Digital Twin **Refinement of v3.1 Twin Law.** * Each user receives exactly ONE Twin, allotted to the domain of the user's role. The Twin does NOT need to cover vast domains — its own user's domain plus that domain's agents and domain workspaces are enough. **INTENDED** * The Twin is the user's digital assistant/agent for their work: it carries out digital and agentic executions end-to-end. * It operates ONLY on sandbox (operational) data — never canonical Spine. **LAW (AI Sandbox Law)** ### Shared Task Assignment Layer **INTENDED — key new contract.** A single task layer spans human and agents: ``` Task assigned ──→ [ SHARED TASK LAYER ] ──→ human OR agent │ Twin orchestrates: takes tasks from the layer, allots subtasks to domain agents, drives them to completion, returns results to the layer ``` * Tasks may be allotted to the user, to agents, or to user+agent jointly. * The Twin is the orchestrator within this layer; it delegates to domain-specific agents. * Every allotment and completion is visible to the user in the Workbench (no hidden execution). * Governed effects still traverse Governance → Execution Fabric. The task layer coordinates; it does not authorize. ### Twin Workbench (Agentic Home) **INTENDED.** The Twin has its own workspace — a home base for agentic work (conceptually like Open WebUI / LangChain): sessions, tool use, agent roster, running executions — all operating on the sandbox copy of context. The Agent Workspace is SEPARATE from the User Workbench; the two stay consistent through the platform loop, not through shared state. ## 6. Coworker — Context Companion Per v3.1 Coworker Law, now made concrete: * Gathers context from the user's screen — active work surface and interaction with the Workbench. **INTENDED** * Feeds assembled context to Twin and pipeline executions. * Handles communications in CONSISTENCY with the Twin — one voice to the outside, two roles inside: Coworker = context + communication; Twin = reasoning + delegation. **INTENDED** * Neither is a second authority. Neither writes canonical truth. ## 7. The Full Drill-Down Loop ``` ORGANIZATIONAL NEEDS (scattered across multiple tools & software) │ ▼ SOURCE TOOLS converge into SPINE FABRIC (contextual layer for business continuity) │ ├──────────────► serves HUMAN → projections → USER WORKBENCH │ └───(sandbox only)──► serves AI → TWIN WORKBENCH (agentic home) │ │ │ shared TASK LAYER │ (human ⇄ agents, Twin orchestrates) ▼ WORK EXECUTED & COMPLETED │ ▼ results WRITE BACK to SOURCE TOOLS via workflows — driven by AI, not manual repetition │ ▼ PLATFORM UNDERNEATH carries everything: auth · packages · MCP connectors · infrastructure pipeline · loop · communication layer · ADK · orchestrator (communication enablers; can talk to other platforms too) ``` Key distinctions: | Distinction | Rule | | --------------------------------- | --------------------------------------------------------------------------------------------- | | Canonical Spine | Humans reach it through projections; **AI NEVER touches it** — sandbox only | | User Workbench vs Agent Workspace | Two separate surfaces, kept consistent by the platform loop | | Task execution | AI-driven write-back into source tools via workflows — humans stop doing monotonous sync work | | Platform | Enabler only. It never becomes a second Workbench (Platform Law) | ## 8. Layer Model 1. **Organization layer** — decides goals and needs. 2. **Cascade layer** — goals/needs transfer to humans by domain, role, responsibility. 3. **Human layer** — works tasks/goals aligned to organizational and business needs. 4. **AI layer (per-user instance)** — ONE Twin per user, scoped to the user's role domain; domain agents + domain workspaces attached; no vast cross-domain coverage required. 5. **Surfaces layer** — User Workbench (projections) separate from Agent Workspace (Twin home). 6. **Platform layer** — pipeline, loop, communication layer, MCP, ADK, orchestrator: communication channels and enablers underneath everything. ## 9. Boundary Laws (restated for this model) * **AI Sandbox Law** — AI reads sandbox, never canonical Spine. * **Governance Law** — confidence never grants authority; consequential mutation passes Governance before Execution Fabric. * **Projection Law** — projections are views, not sources. * **Platform Law** — the substrate enables; it does not become another Workbench. * **Continuity Law** — bounded continuity across people, tools, AI hosts, domains. ## 10. Gap Register — Dictated Model vs Current Code | # | Model element | State | Next step | | -- | -------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | G1 | Organization Memory sidebar section (org-scoped knowledge workspace) | INTENDED — GAP | Promote personal Knowledge Base patterns into an org-memory-backed section reading approved org\_memory only | | G2 | Spine Schema Generator from org lifecycle events | INTENDED | Spec + service boundary in Pipeline plane | | G3 | Shared Task Assignment Layer (human ⇄ agents) | INTENDED | Extend Task Management MCP contracts with assignee-kind (human/agent/joint) + Twin orchestration hooks | | G4 | Twin Workbench as separate agentic home | PARTIAL — Twin runtime exists (`services/iw-agent-runtime`) | Productize session/tool/agent-roster surface | | G5 | One-Twin-per-user scoped to role domain | PARTIAL — Twin binding exists | Enforce 1:1 user:Twin allotment with domain scoping in runtime config | | G6 | Coworker screen-context gathering + unified comms with Twin | INTENDED | New Coworker capability in runtime; comms consistency contract | | G7 | AI-driven write-back of completed work into source tools | PARTIAL — reconciliation loop exists in doctrine | Wire workflow-based writeback into Execution Fabric outcomes |