{"slug":"internal/architecture/communications-bridge","title":"SpineWorkspace — Communications Over the Bridge","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"document","path":"internal/architecture/communications-bridge.md","bytes":7989,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n\n\n# SpineWorkspace — Communications Over the Bridge\n\n**Status:** CANONICAL TARGET \n**Product:** SpineWorkspace \n**Platform:** IntegrateWise \n**Primary purpose:** Governed communication and contextual work continuity across humans, Twin, agents and external systems \n**Foundation:** Business Context Spine (THE semantic foundation)\n\n## 1. Definition\n\n> **The Bridge is the governed communication substrate through which work-related messages, context references, decisions, approvals, requests, agent handoffs and execution signals move between the human Workbench, Twin, agents and connected systems while retaining identity, Work, provenance and authority context.**\n\nThe Bridge is not:\n\n- a fourth memory store;\n- a canonical database;\n- a replacement for Slack/email/Teams;\n- an authority bypass;\n- an unrestricted agent bus.\n\n## The Tier-0 Principle\n\n> **Business Context is the semantic foundation of SpineWorkspace.** The Bridge communicates Business Context. Without Business Context, the Bridge has nothing to communicate.\n\n## 2. Bridge topology\n\n```text\n BUSINESS CONTEXT SPINE\n (THE Semantic Foundation)\n │\n BUSINESS CONTEXT\n │\n ┌─────────┴─────────┐\n │ │\n HUMAN WORKBENCH AI WORKBENCH\n │ │\n └─────────┬─────────┘\n │\n COMMUNICATION BRIDGE\n │\n ┌───────────────────┼───────────────────┐\n │ │ │\n HUMAN AGENTS SYSTEMS\n │ │ │\n Slack / Email ACP / Agent APIs / Webhooks\n Chat / Meetings Handoffs Workflows / MCP\n │ │ │\n └───────────────────┼───────────────────┘\n │\n Work / Context\n │\n ▼\n BUSINESS CONTEXT SPINE\n```\n\n## 3. Bridge message envelope\n\nEvery governed Bridge message should carry or resolve to:\n\n```text\nTenant\nPrincipal\nSender\nRecipient\nWork ID\nTask ID where applicable\nCommunication Type\nPurpose\nContext Reference\nCapability Reference where applicable\nAuthority Context\nSource Channel\nCorrelation ID\nCausation ID\nTimestamp\nProvenance\nSensitivity\nStatus\n```\n\n## 4. Channel taxonomy\n\n```text\nHuman Channels\n├── Workbench Chat\n├── Slack\n├── Email\n├── Teams\n├── Meetings\n└── Calls\n\nAgent Channels\n├── ACP\n├── Work Handoff\n├── Context Reference\n├── Agent Result\n└── Escalation\n\nSystem Channels\n├── API\n├── Webhook\n├── Event Bus\n├── Workflow Event\n├── MCP\n└── Connector Event\n```\n\nThe Bridge standardizes the semantic work context without replacing the underlying transport.\n\n## 5. Communication is attached to Work\n\nA message is not isolated from business context.\n\n```text\nCommunication\n ↓\nWork\n ↓\nEntity / Customer / Account / Project\n ↓\nContext\n ↓\nDecision / Assignment / Outcome\n```\n\nExample:\n\n```text\nSlack\n ↓\nManager approves discount\n ↓\nCommunication Event\n ↓\nWork ID\n ↓\nApproval Event\n ↓\nGovernance\n ↓\nCapability Execution\n```\n\n## 6. Human-to-Twin communication\n\n```text\nHuman\n ↓\nWorkbench / Chat\n ↓\nBridge\n ↓\nTwin\n ↓\nContext Assembly\n ↓\nResponse / Proposal / Action\n```\n\nThe Twin receives user intent plus the relevant Work/Context reference.\n\n## 7. Twin-to-agent communication\n\n```text\nTwin\n ↓\nWork Allocation\n ↓\nACP\n ↓\nDomain Agent\n ↓\nScoped Context\n ↓\nAgent Work\n ↓\nResult + Evidence\n ↓\nACP\n ↓\nTwin\n```\n\nThe agent does not become the owner of the Work.\n\n## 8. Human-to-human communication\n\nThe user may consult a manager or teammate through Slack, email, chat or meetings.\n\n```text\nUser\n ↓\nBridge\n ↓\nExternal Communication Channel\n ↓\nResponse\n ↓\nBridge\n ↓\nWork / Decision / Evidence\n ↓\nTwin\n```\n\nThe Work remains continuous even when the human leaves SpineWorkspace to communicate in another channel.\n\n## 9. Context sharing\n\nThe Bridge carries a **reference to governed context**, not arbitrary raw organizational memory.\n\n```text\nContext Reference\n├── Work\n├── Purpose\n├── Relevant Entities\n├── Current State\n├── Allowed Evidence\n├── Authority Scope\n├── Freshness\n└── Expiry\n```\n\nContext is assembled from Spine and filtered before being handed to an external participant.\n\n## 10. ACP vs MCP\n\n```text\nMCP\nAI ↔ Tool / Resource / Capability\n\nACP\nAgent ↔ Agent / Agent ↔ Twin\nthrough Work and Context handoff\n```\n\nMCP does not establish organizational authority.\n\nACP does not establish organizational authority.\n\nGovernance establishes whether consequential actions are permitted.\n\n## 11. Communication-derived evidence\n\nCommunication may become:\n\n```text\nMessage\n ↓\nEvidence\n ↓\nContext\n ↓\nDecision / Interpretation\n ↓\nTriage\n ↓\nCandidate\n ↓\nGoverned Promotion\n ↓\nOrganizational Memory\n```\n\nRaw messages are not automatically Organizational Memory.\n\n## 12. Approval through the Bridge\n\nAn approval received through Slack or another connected channel must be converted to a verified approval event:\n\n```text\nChannel Response\n ↓\nAuthenticated Principal\n ↓\nTenant Check\n ↓\nWork ID\n ↓\nCandidate / Action Version\n ↓\nPolicy Check\n ↓\nImmutable Approval Event\n ↓\nGoverned Execution / Promotion\n```\n\nA Slack reaction alone is never a canonical authority bypass.\n\n## 13. Execution through the Bridge\n\n```text\nHuman / Twin Intent\n ↓\nBridge / Work Context\n ↓\nCapability\n ↓\nGovernance\n ↓\nExecution Fabric\n ↓\nAPI / MCP / Workflow / Tool\n ↓\nSource System\n```\n\n## 14. Return path\n\n```text\nSource System\n ↓\nWebhook / Event / Polling / API\n ↓\nConnector\n ↓\nLoader\n ↓\nNormalizer\n ↓\nBusiness Context\n ↓\nReconciliation\n ↓\nSpine\n```\n\nThis guarantees that outbound execution and inbound state remain part of one continuity thread.\n\n## 15. Knowledge evolution through the Bridge\n\n```text\nCommunication\n +\nExecution Outcome\n ↓\nEvidence\n ↓\nContext\n ↓\nInterpretation\n ↓\nTriage\n ↓\nGovernance\n ↓\nOrganizational Memory\n ↓\nFuture Context\n```\n\nThis is how communications and executed work can enrich organizational knowledge without allowing raw communications or agent output to become truth automatically.\n\n## 16. Bridge reliability\n\nRequired properties:\n\n- authenticated delivery;\n- tenant isolation;\n- correlation;\n- causation;\n- idempotency;\n- deduplication;\n- replay control;\n- provenance;\n- delivery status;\n- audit;\n- expiry where applicable;\n- ambiguity handling;\n- reconciliation for consequential effects.\n\nAn ambiguous outbound result must be reconciled before retrying.\n\n## 17. Bridge laws\n\n1. Bridge communication is not canonical truth.\n2. Bridge context is scoped to Work and purpose.\n3. Bridge messages retain source provenance.\n4. External channels cannot bypass governance.\n5. Agent communication does not grant authority.\n6. Approved consequential actions traverse Execution Fabric.\n7. Source-system results re-enter through ingestion and reconciliation.\n8. Communication-derived knowledge enters Organizational Memory only through governed promotion.\n9. The Bridge preserves Work continuity across applications and agents.\n"}