{"slug":"architecture/SPINEWORKSPACE_INFORMATION_ARCHITECTURE","title":"SpineWorkspace Information Architecture","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/SPINEWORKSPACE_INFORMATION_ARCHITECTURE.mdx","bytes":20043,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** CANONICAL · COMPREHENSIVE v2.0\n**Owner:** IntegrateWise Platform\n**Scope:** Complete Information Architecture including Domain Topology, Sidebar Structure, Work Projections, Platform Services, and Technical Implementation\n**Last Updated:** 2026-08-21\n\n---\n\n## 1. Executive Summary — Who We Are\n\nIntegrateWise is the **persona-shaped operating system** that sits between third-party AI assistants and human systems of record. We convert distribution traffic into tenant truth, then operate a Twin on that truth.\n\n**Core Doctrine:**\n- Distribution is ingress — every AI assistant marketplace is a tenant-acquisition channel\n- Truth you own — the Spine is canonical; AI tools are projections\n- AI you rent — the LLM provider is plumbable (Cloudflare AI Gateway); no vendor lock\n- Approval in between — every write that crosses a system boundary passes through the Governance Engine\n- One capability, every surface — the same cap_id resolves identically across all interfaces\n- Continuity over asking — the Spine is the source of context; the Twin never re-asks\n- Persona barrier — tenant_spine_config.industry × department defines the visible universe\n- Hard gates are non-negotiable — Soft-sync defaulting, 5-minute first-data-load, promotion-queue human approval\n\n---\n\n## 2. Subdomain Topology\n\nSpineWorkspace is **one application** with subdomain-based routing that resolves department context.\n\n```\nspineworkspace.com\n│\n├── www.spineworkspace.com             → Public marketing\n├── auth.spineworkspace.com            → One Access (Authentication & Identity)\n├── platform.spineworkspace.com        → Platform control plane\n│\n├── founder.spineworkspace.com         → Founder workspace\n├── sales.spineworkspace.com           → Sales workspace\n├── cs.spineworkspace.com              → Customer Success workspace\n├── marketing.spineworkspace.com       → Marketing workspace\n├── finance.spineworkspace.com         → Finance workspace\n├── operations.spineworkspace.com      → Operations workspace\n├── product.spineworkspace.com         → Product workspace\n├── engineering.spineworkspace.com     → Engineering workspace\n├── account-success.spineworkspace.com  → Account Success\n├── technical-account-success.spineworkspace.com → Technical Account Success\n├── business-intelligence.spineworkspace.com → Business Intelligence\n├── campaigns.spineworkspace.com       → Campaigns workspace\n├── knowledge-management.spineworkspace.com → Knowledge Management\n├── revops.spineworkspace.com          → Revenue Operations\n├── support.spineworkspace.com         → Support workspace\n├── brandstore.spineworkspace.com      → Brand Store\n├── book-of-records.spineworkspace.com → Book of Records\n├── ops.spineworkspace.com             → Ops workspace\n│\n└── future projections...\n```\n\n### Routing Contract\n\nThe subdomain resolves to a **department identifier**. Combined with the authenticated user's role and the tenant's industry, this selects the Work projections rendered in the sidebar and main content area.\n\n**Key Principle:** Every department subdomain loads the **same application shell**. Only the Work section differs. `www`, `auth`, and `platform` are distinct surfaces with their own shells. Department subdomains share one shell.\n\n### Resolution Formula\n\n```\nsubdomain → department\nsession   → role\ntenant    → industry\npolicy    → workspace configuration\n\nprojection = f(role, department, industry, workspace_policy)\n```\n\nEach projection contains enough operational depth for a user to perform their **complete job** in the agentic era.\n\n```\nspineworkspace.com\n│\n├── www.spineworkspace.com             Public marketing\n├── auth.spineworkspace.com            One Access (Descope)\n├── platform.spineworkspace.com        Platform control plane\n│\n├── founder.spineworkspace.com         Founder workspace\n├── sales.spineworkspace.com           Sales workspace\n├── cs.spineworkspace.com              Customer Success workspace\n├── marketing.spineworkspace.com       Marketing workspace\n├── finance.spineworkspace.com         Finance workspace\n├── operations.spineworkspace.com      Operations workspace\n├── product.spineworkspace.com         Product workspace\n├── engineering.spineworkspace.com     Engineering workspace\n├── account-success.spineworkspace.com          Account Success\n├── technical-account-success.spineworkspace.com Technical Account Success\n├── business-intelligence.spineworkspace.com    Business Intelligence\n├── campaigns.spineworkspace.com       Campaigns workspace\n├── knowledge-management.spineworkspace.com     Knowledge Management\n├── revops.spineworkspace.com          Revenue Operations\n├── support.spineworkspace.com         Support workspace\n├── brandstore.spineworkspace.com      Brand Store\n├── book-of-records.spineworkspace.com Book of Records\n├── ops.spineworkspace.com             Ops workspace\n│\n└── future projections...\n```\n\n### Routing contract\n\nThe subdomain resolves to a department identifier. The department identifier,\ncombined with the authenticated user's role and the tenant's industry, selects\nthe Work projections rendered in the sidebar and main content area.\n\nEvery department subdomain loads the same application shell. Only the Work\nsection differs. `www`, `auth`, and `platform` are distinct surfaces with their\nown shells.\n\n---\n\n## 3. Sidebar Structure\n\nThe sidebar is consistent across all department subdomains. It has three\ntop-level zones: **Common**, **Work**, and **Platform**. Common and Platform\nare identical on every subdomain. Work changes per subdomain.\n\n```\n┌─────────────────────────────┐\n│  COMMON                     │\n│  ├── Home                   │\n│  ├── My Work                │\n│  ├── Inbox                  │\n│  ├── Tasks                  │\n│  ├── My Queue               │\n│  ├── Approvals              │\n│  ├── Notifications          │\n│  ├── Recent Work            │\n│  ├── Favorites              │\n│  ├── Communications         │\n│  │   ├── Activity Feed      │\n│  │   ├── Email              │\n│  │   ├── Calendar           │\n│  │   ├── Meetings           │\n│  │   ├── Chat               │\n│  │   └── Calls              │\n│  ├── Documents              │\n│  │   └── Shared             │\n│  ├── Personal               │\n│  │   ├── Notes              │\n│  │   ├── Knowledge Base     │\n│  │   └── Brainstorming      │\n│  └── Activity               │\n├─────────────────────────────┤\n│  WORK                       │\n│  ├── View 1                 │  ← Department-specific\n│  ├── View 2                 │     projections\n│  ├── ...                    │\n│  └── View N                 │\n├─────────────────────────────┤\n│  PLATFORM                   │\n│  ├── Integration Manager    │\n│  ├── Connector Marketplace  │\n│  ├── Activation Hub         │\n│  ├── Capability Manager     │\n│  ├── MCP Pool               │\n│  ├── AI Models              │\n│  ├── Knowledge              │\n│  ├── Memory & Continuity    │\n│  ├── Automation             │\n│  ├── Pipelines              │\n│  ├── Governance             │\n│  ├── Observability          │\n│  └── Administration         │\n│      ├── Organizations      │\n│      ├── Users              │\n│      ├── Roles              │\n│      ├── Permissions        │\n│      ├── Audit              │\n│      ├── Billing            │\n│      ├── Deployments        │\n│      ├── API Keys           │\n│      ├── Security           │\n│      ├── Admin              │\n│      └── Paywall            │\n└─────────────────────────────┘\n```\n\n---\n\n## 4. Common Sidebar Sections\n\n### Home\n\nPersonal operational dashboard. Cross-domain aggregation independent of\nthe current department projection.\n\n- Personal KPIs and priority ranking\n- Pending approvals\n- AI recommendations and quick actions\n- Workspace continuity entry\n- Personal Twin context\n- Cross-projection navigation\n- Recent activity\n\n### My Work\n\nPersonal execution surface.\n\n- Assigned work and delegated work\n- Waiting on others / waiting for me\n- Tasks, goals, deliverables, follow-ups\n- Approvals and SLA commitments\n- Calendar-linked work\n- Twin-assisted execution\n\n### Inbox\n\nUnified operational inbox. Aggregated from email, chat, CRM, tickets,\ncomments, mentions, notifications, AI-generated follow-ups, connector events,\nworkflow events, and approval requests.\n\n- Priority scoring and deduplication\n- Threading and AI summaries\n- Suggested actions\n\n### Tasks\n\nUniversal task execution. Manual tasks, workflow tasks, agent-generated tasks,\nconnector-generated tasks, scheduled tasks, recurring tasks, approvals,\ndependencies, SLA tracking, and context-aware execution.\n\n### My Queue\n\nDynamic execution queue generated from the priority engine, OODA, signals,\ndeadlines, dependencies, AI prioritization, role, current context, business\nimpact, and attention management.\n\n### Approvals\n\nHuman-in-the-loop governance. Publishing, budget, connector, AI, write-back,\ncustomer, deployment, security, and policy approvals. Escalation workflows\nwith full audit trail.\n\n### Notifications\n\nWorkspace event stream from connectors, pipelines, agents, skills, workflows,\ngovernance, security, platform, workspace, Twin, and human collaboration.\nIntelligent grouping and prioritization.\n\n### Recent Work\n\nContinuity surface. Recently viewed entities, edited records, conversations,\nworkflows, approvals, Twin sessions, canvas work, documents, and context.\nResume previous work.\n\n### Favorites\n\nPinned operational assets. Views, dashboards, accounts, campaigns, customers,\nreports, skills, agents, workflows, documents, canvases, and pipelines.\n\n### Communications\n\nUnified communication layer.\n\n| Section       | Purpose                                                                                                                                                                                                           |\n| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Activity Feed | Operational timeline combining CRM, emails, meetings, chats, deployments, customer interactions, agent activity, workflow execution, connector events, and platform events into one chronological Spine timeline. |\n| Email         | Multi-provider inbox with AI summaries, draft generation, smart replies, CRM linking, entity linking, Twin memory, knowledge retrieval, and workflow initiation.                                                  |\n| Calendar      | Multi-provider scheduling with AI scheduling, meeting preparation, agenda generation, follow-up generation, linked entities, and linked workflows.                                                                |\n| Meetings      | Meeting operating system: preparation, briefing, live assistance, recording, transcript, action extraction, decisions, follow-ups, memory promotion, and workflow creation.                                       |\n| Chat          | Unified conversation across Slack, Teams, Discord, internal chat, MCP messaging, and AI conversations with context retrieval, entity linking, workspace memory, and suggested actions.                            |\n| Calls         | Voice communication with call preparation, live notes, transcript, CRM linking, entity extraction, tasks, decisions, follow-ups, and memory updates.                                                              |\n\n### Documents\n\nCollaborative document workspace across Google Docs, Office, Notion, Coda,\nPDFs, and internal documents. Semantic indexing, context retrieval, version\nawareness, AI understanding, and knowledge promotion.\n\n### Personal\n\nPersonal knowledge and thinking space.\n\n| Section        | Purpose                                                                                                                                                                                                      |\n| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Notes          | Personal operational memory with quick capture, linked entities, AI organization, tags, knowledge promotion, Twin context, and search.                                                                       |\n| Knowledge Base | Workspace knowledge graph: canonical knowledge, policies, documentation, procedures, product knowledge, customer knowledge, organizational knowledge, semantic search, RAG context, and source traceability. |\n| Brainstorming  | Collaborative ideation: whiteboards, structured thinking, AI ideation, Twin collaboration, decision capture, research, concept evolution, and memory promotion.                                              |\n\n### Activity\n\nPersonal operational timeline. Work history, AI activity, decisions, context\nswitches, workflow participation, learning, memory evolution, and workspace\ninteractions.\n\n---\n\n## 5. Work Section\n\nThe Work section is the only section that changes per subdomain. It is built\nfrom:\n\n- Spine projections\n- Views\n- Canvas\n- Tool capabilities\n- Twin execution through OODA invocations\n- Skills\n- Agents\n- Workflows\n- Pipelines\n- Backend/frontend mappings\n- Operational databases\n- Context gathering\n- Entity360\n- Continuity memory\n\nEach projection contains enough operational depth for a user to perform\ntheir complete job in the agentic era.\n\n### Work section components\n\n```\nViews               Spine-projected operational views for the domain\nCanvas              Spatial working surface for the domain\nSkills              Domain-specific skills available to the user\nAgents              Domain-specific agents (Twin, Triage, Co-worker)\nWorkflows           Domain-specific automated workflows\nTwin                Domain-aware Twin context and execution\nOperational Objects Domain entities projected from the Spine\n```\n\n### Routing contract\n\nWork projections are resolved by:\n\n```\nsubdomain → department\nsession   → role\ntenant    → industry\npolicy    → workspace configuration\n\nprojection = f(role, department, industry, workspace_policy)\n```\n\nThe views rendered in the Work section are sufficient for any person working\nin that domain. They are not a subset of a larger tool — they are the\ncomplete operational surface for that department.\n\n---\n\n## 6. Platform Section\n\nShared platform capability layer provided by `apps/platform`. Every subdomain\nrenders the same Platform section. Administration is permission-aware and\nexposes only the capabilities the current user is authorized to manage.\n\n### Integration Manager\n\nConnector lifecycle: OAuth, credentials, sync, health, scopes, events,\npolicies, write-back, and diagnostics.\n\n### Connector Marketplace\n\nConnector discovery: providers, templates, MCP connectors, native connectors,\ncommunity connectors, installation, configuration, ratings, and documentation.\n\n### Activation Hub\n\nWorkspace onboarding: identity, workspace, connectors, capabilities, initial\nsync, Spine hydration, memory bootstrap, verification, and readiness.\n\n### Capability Manager\n\nCapability fabric mapping skills, tools, connectors, APIs, agents, workflows,\npermissions, and policies.\n\n### MCP Pool\n\nUnified MCP runtime: tool registry, MCP discovery, invocation, authentication,\nsessions, context, security, and monitoring.\n\n### AI Models\n\nModel management: providers, routing, policies, costs, benchmarks, prompt\nversions, safety, evaluation, and observability.\n\n### Knowledge\n\nKnowledge infrastructure: indexing, semantic search, embeddings, documents,\ncitations, knowledge graph, retrieval, and context assembly.\n\n### Memory & Continuity\n\nContinuity infrastructure: personal memory, workspace memory, organizational\nmemory, Twin memory, timeline, decisions, context, recall, and promotion.\n\n### Automation\n\nAutomation runtime: triggers, schedules, events, conditions, retries,\ndead-letter queues, idempotency, human approvals, and monitoring.\n\n### Pipelines\n\nOperational data pipelines: load, normalize, map, validate, enrich,\nsynchronize, index, publish, and observe.\n\n### Governance\n\nOperational governance: policies, approvals, compliance, risk, audit, change\ncontrol, AI governance, and connector governance.\n\n### Observability\n\nPlatform intelligence: logs, metrics, traces, health, costs, AI usage,\nconnector status, pipeline status, workflow execution, and user experience.\n\n### Administration\n\nWorkspace administration layer. Permission-aware — exposes only the\nadministrative capabilities the current user is authorized to manage.\n\n| Section       | Scope                                               |\n| ------------- | --------------------------------------------------- |\n| Organizations | Workspace and tenant management                     |\n| Users         | Members, invitations, sessions                      |\n| Roles         | Role definitions and assignments                    |\n| Permissions   | Resource-level access control                       |\n| Audit         | Immutable audit trail and compliance records        |\n| Billing       | Plans, usage, invoices, payment methods             |\n| Deployments   | Release management and deployment history           |\n| API Keys      | API key lifecycle and scoping                       |\n| Security      | Security policies, SSO, MFA, threat detection       |\n| Admin         | Platform-level administration                       |\n| Paywall       | Feature access control and subscription enforcement |\n\n---\n\n## 7. Architectural Principles\n\n1. SpineWorkspace is one application. Subdomain routing resolves department\n   context — it does not deploy separate applications.\n\n2. The Common sidebar and Platform section are identical across all department\n   subdomains.\n\n3. Intelligence (Skills, Agents, Workflows, Twin, OODA) is embedded inside\n   each domain projection, not isolated in a separate product area.\n\n4. The Work section renders projections sufficient for a complete job in the\n   agentic era — not a subset of a larger tool.\n\n5. The sidebar has three zones: Common (universal operations), Work\n   (department-specific projections), and Platform (shared infrastructure).\n\n6. `www`, `auth`, and `platform` are distinct surfaces with their own shells.\n   Department subdomains share one shell.\n\n7. Administration is permission-aware. The sidebar renders only the sections\n   the authenticated user is authorized to access.\n\n---\n\n## 8. Invariants\n\n1. Every department subdomain loads the same application shell.\n2. The Work section is the only section that differs per subdomain.\n3. Work projections are resolved by Role × Department × Industry × Policy.\n4. Platform, auth, connectors, marketplace, MCP, and integration manager are\n   shared across all subdomains.\n5. The sidebar structure is frozen. New sections require architecture review.\n"}