{"slug":"platform/workbench","title":"Workbench Master Plan","section":"platform","sectionLabel":"Platform","status":"unclassified","type":"document","path":"platform/workbench.mdx","bytes":18333,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> The trilogy: Projection Doctrine + Builder Doctrine + Tool Absorption Doctrine, executed in sequence.\n\n---\n\n## The Three Doctrines\n\n| Doctrine                   | File                                         | Governs                                    |\n| -------------------------- | -------------------------------------------- | ------------------------------------------ |\n| **Workbench & Projection** | `docs/tech/workbench-projection-doctrine.md` | How relevance is computed and rendered     |\n| **Workbench Builder**      | `docs/tech/workbench-builder-doctrine.md`    | How the surface must be built              |\n| **Tool Absorption**        | `docs/tech/tool-absorption-doctrine.md`      | How external capabilities are internalized |\n\n---\n\n## Workbench Surface Boundary Decision\n\n| Workbench      | Canonical Surface                                                                                    | Open WebUI Role     | Boundary Rule                                                                                                                                          |\n| -------------- | ---------------------------------------------------------------------------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| User Workbench | Projection-native customer/product shell                                                             | No shell role       | The customer-facing workbench remains the IntegrateWise product shell. It may launch or hand off context into Twin, but is not replaced by Open WebUI. |\n| Twin Workbench | Open WebUI primary Twin surface                                                                      | Direct runtime      | Open WebUI is the primary cognition surface for Twin: chat, models, prompts, knowledge, tools, automations, and memory.                                |\n| Governance     | Embedded at every layer — approval queue and HITL review surface inline in the Operational Workbench | Governance-adjacent | Approval panels appear inline, not in a separate shell.                                                                                                |\n\nCanonical styling rule:\n\n- Twin / Open WebUI runtime surfaces use Forest + Paper.\n- Midnight Executive remains investor-deck language only.\n\n---\n\n## Execution Sequence\n\n### Phase 1: Stabilize Projection Architecture\n\n**Goal:** The Projection Engine is the foundation. It must be solid before any surface work continues.\n\n| Task                                                                              | File / Location                                                            | Status    |\n| --------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | --------- |\n| `useProjection()` hook reads all spine config tables                              | `lib/projection/use-projection.ts`                                         | ✅ Built  |\n| Module resolver computes work/org/personal views                                  | `lib/projection/module-resolver.ts`                                        | ✅ Built  |\n| Field policy enforcement                                                          | `lib/projection/field-policy.ts`                                           | ✅ Built  |\n| Module guard in ContentRouter                                                     | `lib/projection/module-guard.ts` + `content-router.tsx`                    | ✅ Wired  |\n| Role passthrough AppShell → WorkspaceShell → ContentRouter                        | `AppShell.tsx` → `workspace-shell-new.tsx` → `animated-content-router.tsx` | ✅ Wired  |\n| **RBAC role name fix** — DB enum `practitioner`/`readonly` → FE `member`/`viewer` | Migration or mapping layer                                                 | 🔄 Needed |\n| **ProjectedModules passthrough** — `useProjection()` → sidebar navigation filter  | `workspace-shell-new.tsx` nav generation                                   | 🔄 Needed |\n\n**Tool Absorption (Phase 1):**\n\n- **PostgreSQL** — truth layer fully utilized via direct Spine DB RPC reads\n- **Infisical** — secrets governance remains backend-only; no surface change yet\n\n---\n\n### Phase 2: Make Navigation Projection-Native\n\n**Goal:** The sidebar and navigation must be driven by projection, not hardcoded maps.\n\n| Task                                                             | File / Location                                | Status                                                    |\n| ---------------------------------------------------------------- | ---------------------------------------------- | --------------------------------------------------------- |\n| Dynamic module resolver replaces static `DOMAIN_CONTENT_MAP`     | `content-router.tsx`                           | ✅ Guard + `module-resolver.ts` dynamic resolution active |\n| Sidebar nav filters by `tenant_products` × `role` × `department` | `workspace-shell-new.tsx` via `nav-builder.ts` | ✅ `buildNavFromProjection()` drives sidebar              |\n| Navigation respects `depth_matrix`                               | `nav-builder.ts`                               | ✅ Cross-dept modules grouped with depth badges           |\n| Product entitlement gates navigation items                       | `module-guard.ts` + `nav-builder.ts`           | ✅ `canAccessModule()` gates every sidebar item           |\n| Three doors enforced: My Department / My Organization / My Self  | Tabs in workbench + nav sections               | ✅ Built                                                  |\n\n**Tool Absorption (Phase 2):**\n\n- **BookStack** — doctrine browser link in Org View (integrated reference stage) ✅\n\n---\n\n### Phase 3: Build SDAI-Native Operational Surfaces\n\n**Goal:** The Workbench must make the Schema-Driven AI Integration pipeline visible and operable.\n\n| Task                                                                                                    | Primitive                       | Backend Need                               |\n| ------------------------------------------------------------------------------------------------------- | ------------------------------- | ------------------------------------------ |\n| **Ingestion Panel** — real-time source connector status                                                 | Health Ring + Timeline Stream   | `sync_jobs` polling endpoint               |\n| **Source Connector Tiles** — per-tool status (Salesforce, HubSpot, Gmail, Slack, ChatGPT, Claude, Kimi) | Entity Card variant             | Connector status API                       |\n| **Schema Extraction Badge** — shows which template/schema was fetched                                   | Metric Tile                     | `spine_schema_registry` per-entity         |\n| **Normalization Progress** — 8-stage pipeline visualization                                             | Progress bars + Timeline Stream | Per-entity pipeline state                  |\n| **Curation Queue** — AI-proposed entities awaiting human judgment                                       | Governance Panel                | `continuity_objects` with `proposed` state |\n| **Schema Mapping Preview** — tool field → spine field mapping                                           | Operational Canvas              | Schema mapping API                         |\n\n**New Components to Build:**\n\n- `components/workbench/panels/ingestion-panel.tsx`\n- `components/workbench/panels/connector-tile.tsx`\n- `components/workbench/panels/curation-card.tsx`\n\n**Tool Absorption (Phase 3):**\n\n- Spine DB conversational_memory — continuity timelines visible in Timeline Stream\n- **Agent Zero** — execution cards in Action Tiles (native-assisted stage)\n\n---\n\n### Phase 4: Surface Ingestion + Curation + Write-Back Visibly\n\n**Goal:** Close the loop. User sees raw input → AI curation → approval → write-back → confirmation.\n\n| Task                                                                             | Primitive                   | Backend Need                        |\n| -------------------------------------------------------------------------------- | --------------------------- | ----------------------------------- |\n| **Raw Input Preview** — show scrambled source data (email thread, doc, AI convo) | Operational Canvas          | Source content fetch API            |\n| **AI Curation Card** — curated entity proposal with confidence                   | Insight Block + Entity Card | `continuity_objects` content        |\n| **Schema Mapping Approval** — approve field mappings before entity creation      | Governance Panel            | Schema mapping + approval API       |\n| **Write-Back Proposal** — \"Update Salesforce stage? [Confirm]\"                   | Action Tile                 | `connector.execute` with preview    |\n| **Write-Back Confirmation** — timeline showing write-back success/failure        | Timeline Stream             | `workflow_executions` + `audit_log` |\n| **Sync Conflict Detection** — alert when source tool has diverged                | Insight Block               | `pipeline_quarantine` + diff API    |\n| **Empty Dashboard Killer** — ingestion always produces candidates                | All primitives              | Continuous ingestion cron           |\n\n**New Components to Build:**\n\n- `components/workbench/panels/curation-card.tsx`\n- `components/workbench/panels/writeback-monitor.tsx`\n- `components/workbench/panels/sync-conflict-alert.tsx`\n\n**Tool Absorption (Phase 4):**\n\n- **n8n** — workflow trace in Timeline Stream, execution in Action Tiles (native-assisted stage)\n- **Open WebUI** — contextual Twin handoff panels linked to entities (Twin-primary, not customer shell)\n\n---\n\n### Phase 5: Absorb High-Value Tool Affordances\n\n**Goal:** Progressive absorption of the strongest capabilities from the external stack.\n\n| Tool                   | Affordance to Absorb                                                    | Workbench Primitive                  | Stage                            |\n| ---------------------- | ----------------------------------------------------------------------- | ------------------------------------ | -------------------------------- |\n| **Affine**             | Block-based operational canvases, freeform drafting                     | Operational Canvas (enhanced)        | Native-assisted                  |\n| **BookStack**          | Hierarchical doctrine navigation, canon browsing                        | Org View canon panels                | Integrated reference             |\n| **Open WebUI**         | Twin entrypoint, entity-linked chat, contextual handoff into Open WebUI | Twin launch surfaces, Insight Blocks | Twin-primary / product-non-shell |\n| **n8n**                | Workflow trace visibility, execution provenance                         | Timeline Stream, Action Tiles        | Native-assisted                  |\n| **Beszel**             | Runtime health cards, system anomalies                                  | Health Ring, Health Canvas           | Integrated reference             |\n| **LiteLLM**            | Model provenance, routing transparency                                  | Governance Panel metadata            | Integrated reference             |\n| **Ollama**             | Local-vs-cloud reasoning visibility                                     | Twin provenance badges               | Integrated reference             |\n| **Agent Zero**         | Visible execution cards, bounded task runs                              | Action Tiles, execution summaries    | Native-assisted                  |\n| **Spine DB memory.\\*** | Continuity timelines, memory-linked entities                            | Timeline Stream, memory attachments  | Native-primary                   |\n\n**New Components to Build:**\n\n- `components/workbench/panels/twin-chat-panel.tsx` (Open WebUI handoff, not shell replacement)\n- `components/workbench/panels/doctrine-browser.tsx` (BookStack absorption)\n- `components/workbench/panels/workflow-trace-panel.tsx` (n8n absorption)\n- `components/workbench/panels/execution-summary-card.tsx` (Agent Zero absorption)\n\n---\n\n### Phase 6: Use v0 for Final Experiential Coherence\n\n**Goal:** v0 is the polish benchmark. Apply its interaction patterns to the rebuilt surface.\n\n| v0 Pattern                                           | v1 Location                          | Action                                                   |\n| ---------------------------------------------------- | ------------------------------------ | -------------------------------------------------------- |\n| Working memory tiles — context + sources + next step | `_deprecated/os-home-view-wired.tsx` | Extract pattern, apply to EntityCard                     |\n| Unified surface — one place, no tab switching        | `workspace-shell-new.tsx`            | Ensure Personal/Work/Org are fluid, not jarring          |\n| Contextual action buttons — `canAct` flag            | `_deprecated/os-home-view-wired.tsx` | Apply to ActionTile                                      |\n| AI memory — \"You discussed pricing on Jan 28\"        | `_deprecated/os-home-view-wired.tsx` | Apply to TimelineStream                                  |\n| Low cognitive switching                              | All views                            | Audit: can user complete task without leaving workbench? |\n| Visible next steps                                   | EntityCard + InsightBlock            | Every card must have \"What next?\"                        |\n\n**Builder Acceptance Test (apply to every view):**\n\n- Can a user understand what matters in under 10 seconds?\n- Can a user act without opening 4 more tabs?\n- Can a user see evidence before approving?\n- Can a user remain inside one contextual surface for a full task cycle?\n\n---\n\n### Phase 7: Expand Departments Through Configuration Only\n\n**Goal:** No bespoke UI for new departments. Only configuration.\n\n| Department       | Config (entityTypes + metrics)                       | Workbench                     |\n| ---------------- | ---------------------------------------------------- | ----------------------------- |\n| Business Ops     | ✅ Built                                             | ✅ `BizOpsWorkbench`          |\n| Customer Success | ✅ Configured                                        | ✅ `CSWorkbench`              |\n| Sales            | `opportunity`, `lead`, `quote`, `sequence`           | `DepartmentWorkbench` wrapper |\n| Marketing        | `campaign`, `lead`, `email`, `social_post`           | `DepartmentWorkbench` wrapper |\n| RevOps           | `pipeline`, `forecast`, `quota`, `cohort`            | `DepartmentWorkbench` wrapper |\n| Finance          | `invoice`, `budget`, `expense`, `report`             | `DepartmentWorkbench` wrapper |\n| Service          | `ticket`, `sla`, `knowledge_article`, `satisfaction` | `DepartmentWorkbench` wrapper |\n| Procurement      | `vendor`, `purchase_order`, `contract`, `renewal`    | `DepartmentWorkbench` wrapper |\n| IT Admin         | `system`, `incident`, `vulnerability`, `certificate` | `DepartmentWorkbench` wrapper |\n| Product/Eng      | `feature`, `bug`, `sprint`, `release`                | `DepartmentWorkbench` wrapper |\n| Student/Teacher  | `student`, `course`, `assignment`, `grade`           | `DepartmentWorkbench` wrapper |\n\n**Each new department requires only:**\n\n1. Entity type list\n2. Metric definitions\n3. Thin wrapper component (20 lines)\n4. Module registry entry\n\nNo custom pages. No custom CSS. No custom data fetching.\n\n---\n\n## Capability Adoption Tracker\n\n| Tool               | Current Stage         | Target Stage                     | Phase                  |\n| ------------------ | --------------------- | -------------------------------- | ---------------------- |\n| PostgreSQL         | Native-primary        | Native-primary                   | 1 (complete)           |\n| Spine DB memory.\\* | Integrated reference  | Native-primary                   | 3-4                    |\n| Open WebUI         | External Twin surface | Twin-primary / product-non-shell | 4-5                    |\n| n8n                | External only         | Native-assisted                  | 4-5                    |\n| Affine             | External only         | Native-assisted                  | 5                      |\n| BookStack          | External only         | Integrated reference             | 2-5                    |\n| Beszel             | External only         | Integrated reference             | 5                      |\n| LiteLLM            | External only         | Integrated reference             | 5                      |\n| Ollama             | External only         | Integrated reference             | 5                      |\n| Agent Zero         | External only         | Native-assisted                  | 4-5                    |\n| Infisical          | External only         | External only                    | Retained as specialist |\n\n---\n\n## Decision Log\n\n| Date       | Decision                                                                                 |\n| ---------- | ---------------------------------------------------------------------------------------- |\n| 2026-05-17 | Three doctrines formalized: Projection, Builder, Tool Absorption                         |\n| 2026-05-17 | 7-phase execution sequence established                                                   |\n| 2026-05-17 | SDAI (Schema-Driven AI Integration) defined as core product pattern                      |\n| 2026-05-17 | v0 remains polish benchmark, v1 remains substrate                                        |\n| 2026-05-17 | Tool absorption is staged, not immediate replacement                                     |\n| 2026-05-17 | Department expansion is configuration-only after Phase 7                                 |\n| 2026-05-21 | Open WebUI reaffirmed as the primary Twin surface, not the customer-facing product shell |\n\n---\n\n_This plan is a living document. Update it when phases complete or architecture shifts._\n"}