{"slug":"platform/CANONICAL_MODEL","title":"IntegrateWise — Final Canonical Model","section":"platform","sectionLabel":"Platform","status":"unclassified","type":"document","path":"platform/CANONICAL_MODEL.mdx","bytes":10472,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status: SUPERSEDED PLATFORM SYNTHESIS.** This file does not supersede the\n> frozen architecture. Any conflicting product, Twin, schema, storage or\n> execution claims are historical. Current authority starts at\n> [`../architecture/ARCHITECTURE_LOCK.md`](../architecture/ARCHITECTURE_LOCK.md).\n\nOriginal status: CANONICAL — Supersedes all prior decks, specs, and architectural documents.\nOwner: IntegrateWise Platform\nLast Verified: 2026-07-25\nUX Reference: Workbench should be similar to UI Bakery style\n\n---\n\n## 1. Final definition\n\n> **IntegrateWise is operational continuity infrastructure that connects an organisation's tools, AI systems, data and work through one governed Spine Network, then projects the right entities, context, memory and capabilities into a role-aware User Workbench.**\n\nThe user experiences:\n\n```\nONE CONNECTED ECOSYSTEM\n        +\nONE USER WORKBENCH\n        +\nONE TWIN\n```\n\nThe platform underneath maintains:\n\n```\nSPINE\nMEMORY\nPROJECTION\nGOVERNANCE\nCAPABILITIES\nEXECUTION\nCONTINUITY\n```\n\n---\n\n## 2. The complete model\n\n```\n                          EXTERNAL ECOSYSTEM\n\n     SaaS Tools · Databases · Files · MCP · AI Providers · Internal APIs\n                                       │\n                                       ▼\n                          ONE AUTH-TO-ECOSYSTEM\n                                       │\n                                       ▼\n                          INTEGRATION MANAGER\n\n       API Connectors · MCP · AI Connectors · API Wrappers · Webhooks\n                                       │\n                                       ▼\n                                  GATEWAY\n\n                  Ingress · TenantGate · Authentication\n                    Scope · Routing · Trace Context\n                                       │\n                                       ▼\n                             LOADER RUNTIME\n\n    ┌─────────────────┬─────────────────┬─────────────────┬─────────────────┐\n    │                 │                 │                 │                 │\n    ▼                 ▼                 ▼                 ▼                 ▼\n\n FLOW A            FLOW B            FLOW C            FLOW D          INGESTION\n Structured        Unstructured      AI Context        Platform        Queues\n Operational       Conversational    Cognitive         Binding         Per Flow\n```\n\n---\n\n## 3. Flow A — Structured operational data\n\nFlow A owns deterministic operational records:\n\n```\nEntities · Tuples · Fields · Relationships · Metrics · Events · Statuses · Ownership · Lifecycle state\n```\n\nTypical sources:\n\n```\nCRM · Support · Billing · Finance · Projects · Tasks · Product · HR · ITSM · Sales · Marketing · Engineering\n```\n\nFlow A is the primary structured substrate projected into Workbench tables, entity views, boards, queues and timelines.\n\n---\n\n## 4. Flow B — Unstructured context\n\nFlow B owns communication, documents and semantic context:\n\n```\nConversations · Threads · Messages · Documents · Attachments · Transcripts · Chunks · Embeddings · Entity links · Knowledge references\n```\n\nFlow B enriches Flow A:\n\n```\nAccount entity\n+\nSupport conversation\n+\nEmail history\n+\nQBR document\n+\nCall transcript\n=\nAccount continuity\n```\n\n---\n\n## 5. Flow C — AI and cognitive continuity\n\nFlow C owns AI-originated and AI-mediated material:\n\n```\nTwin sessions · External AI chats · Model outputs · Plans · Proposals · Tool calls · Generated artefacts · Candidate memory/knowledge/decisions · Agent outcomes\n```\n\nFlow C follows:\n\n```\nAI context → Brainstorming/session layer → Triage → Candidate → Evidence → Governance → Promote or reject\n```\n\n**Flow C cannot directly mutate operational truth.**\n\n---\n\n## 6. Flow D — Platform binding\n\nFlow D is the stable platform-binding plane:\n\n```\nIdentity · Tenant · Workspace · Membership · Role · Department · Industry · Permissions · Configuration · Connections · Credential references · Capabilities · Policies · Entitlements · Runtime bindings\n```\n\nFlow D binds Flow A, B and C to the correct trust, user, workspace and policy context.\n\n---\n\n## 7. Gateway\n\n```\nIngress · TenantGate · Authentication · Scope · Routing · Trace Context\n```\n\n---\n\n## 8. Normalizer and Triage (separate by design)\n\n### Deterministic Normalizer\n\n```\nAnalyze → Classify → Filter → Refine → Extract → Validate → Sanity Check → Resolve identity → Sectorize\n```\n\n### Triage Runtime and Promotion\n\n```\nClassify AI context → Extract candidate memory/knowledge → Attach evidence → Score confidence → Route review → Promote/reject\n```\n\n### Platform Binding Validation\n\n```\nIdentity · Tenant · Workspace · Role · Department · Industry · Permissions · Configuration\n```\n\n---\n\n## 9. Core Spine — Stable Schema\n\n### Operational Truth\n\n```\nEntities · Tuples · Relationships · Events · Metrics · Lifecycle State · Commitments · Decisions\n```\n\n### Knowledge & Evidence\n\n```\nDocuments · Chunks · Embeddings · Source Links · Intelligence Evidence · Semantic Context · Provenance · Retrieval References\n```\n\n### Memory & Continuity\n\n```\nUser Memory · Work Memory · Org Memory · Entity Memory · Decision Memory · Outcome Memory · Continuity State · Agent Memory\n```\n\n---\n\n## 10. Stable Core, Adaptive Projection\n\n> **The Core Spine schema remains stable. The user-facing schema varies through projection.**\n\n```\nStable Core Spine\n+\nProjection Metadata\n+\nActive User Context\n+\nPolicy\n=\nAdaptive User Workbench\n```\n\n### Projection dimensions\n\n```\nRole × Department × Industry × Connector Category × Active Context × User and Tenant Policy × Available Capabilities × Data Freshness\n```\n\n---\n\n## 11. Adaptive User Workbench\n\n```\nTables · Entity Views · Pages · Boards · Queues · Timelines · Calendars · Documents · Approvals · Operational Canvases · Contextual Capabilities\n```\n\n### UX Rule: Workbench should be similar to UI Bakery style\n\n```\nNormal state = Workbench-led\nUser clicks Ask / Assign / Proposal / Signal = Twin detail opens contextually\nUser clicks Chat AI = Conversational interface opens\nUser exits = Workbench returns to primary focus\n```\n\nTwin is a contextual next-panel, drawer or overlay attached to the active entity/task/decision/signal/document/queue/proposal/approval.\n\n### Chat AI — Flow C Entry Point\n\nThe Chat AI is a complete conversational interface that:\n\n1. **Maps directly to the Spine** — reads and writes through governed paths\n2. **Brainstorming layer** — free-form ideation, research, planning\n3. **Triage the Twin** — candidate memory, knowledge, and decisions flow from Chat AI through Triage into the Spine\n4. **Evidence-backed** — every AI output shows its sources and confidence\n5. **Dual-mode**:\n   - **Exploration mode** — brainstorm, research, ask questions\n   - **Action mode** — propose tasks, create entities, generate plans\n\nThe Chat AI is NOT a replacement for the Twin. They serve different purposes:\n\n```\nChat AI = Exploratory intelligence (Flow C entry point)\nTwin = Contextual intelligence (per-entity activation)\n```\n\nChat AI triage path:\n\n```\nChat AI conversation\n→ Candidate memory/knowledge/decisions\n→ Triage Runtime\n→ Evidence attached\n→ Governance review\n→ Promote to Spine or reject\n```\n\nThe user can move seamlessly between Chat AI and Twin:\n\n- Chat AI generates a proposal → Twin surfaces it in context\n- Twin identifies a gap → User opens Chat AI to explore\n- Chat AI creates a task → Twin shows it in the entity detail\n\n---\n\n## 12. Twin\n\n```\nObserve · Orient · Reason · Explain · Plan · Propose · Delegate · Monitor\n```\n\nThe Twin must not occupy a permanently open sidebar by default.\n\n---\n\n## 13. Capability Fabric\n\n```\nTool-to-Tool · Memory Fetch · MCP · Agent-to-Agent · Local · API · Workflow · Browser · Human Task\n```\n\n---\n\n## 14. Governance\n\n```\nPolicy · Authority · Evidence · Risk · Scope → Allow · Deny · Require Approval\n```\n\n---\n\n## 15. Hermes (Execution Coordinator)\n\n```\nBind approved plan · Select activated route · Coordinate · Retry · Monitor · Collect evidence · Reconcile\n```\n\n---\n\n## 16. Execution Providers\n\n```\nAPI · MCP · Agent · Browser · Human · Workflow\n```\n\n---\n\n## 17. Provider Outcome\n\n```\nNative acknowledgement · ID · Status · Evidence · Error · Result payload\n```\n\n---\n\n## 18. Sync and Reconciliation\n\n```\nRe-ingest · Normalize · Compare · Verify · Resolve conflict · Close loop\n```\n\n---\n\n## 19. Final continuity loop\n\n```\nCONNECT → AUTHENTICATE → INGEST → LOAD → NORMALIZE / TRIAGE → GOVERNED WRITE → SPINE → PROJECT → WORK → ASK / ASSIGN → PROPOSE → GOVERN → EXECUTE → ACKNOWLEDGE → RE-INGEST → VERIFY → RECONCILE → REHYDRATE → CONTINUE\n```\n\n---\n\n## 20. Final freeze statement\n\n> **IntegrateWise uses One Auth and the Integration Manager to connect the external ecosystem, Gateway and Loader Runtime to route information through Flow A, Flow B, Flow C and Flow D, deterministic Normalization and governed Triage to write into one stable Core Spine, and the Projection Engine to compose an Adaptive User Workbench based on role, department, industry, connector category, active context and policy. The Twin appears contextually to reason and propose; Capability Fabric resolves execution, Governance controls authority, Hermes coordinates the approved work, and Sync and Reconciliation verify the provider outcome before the Spine rehydrates the Workbench.**\n\n---\n\n## 21. What is no longer canonical\n\n- 16 named agents as the primary product architecture\n- 21 Hubs as separate applications\n- Atlas Spine as a separate older model\n- Different physical schemas per role or connector\n- AI directly writing truth\n- Automatic execution based only on model confidence\n- OpenWebUI as the Twin runtime\n- Nango as the identity of the whole Integration Manager\n- Dashboards as the Workbench\n- Static departmental applications\n- Direct database access from Workbench components\n- Direct execution from Twin\n- Connector installation permanently adding arbitrary columns\n- AI chat transcripts directly becoming organisational memory\n\nAgents, hubs, providers and infrastructure remain implementation options underneath the stable canon.\n"}